10 things to learn about agile, holacracy and remote work

from AgileByExample 2019

“What is it all about?” asked me an elderly lady who entered the cinema where this year’s AgileByExample (ABE) conference was taking place. Initially, she just wanted to go for a movie, but once she saw all the participants she was really curious to find out why all these people gathered in one place. I was looking for words that would replace agile, method, software development, etc.

“Well, it’s an event about how to get better at what we do.” — I said finally. She looked at me surprised — probably because it took me a while to answer a simple question. “It’s wonderful. I didn’t know there are such events taking place.” she said with a smile.

It made me realize that agile is like an umbrella that encompasses many different aspects and areas. And what’s great about it is that it gathers people willing to improve at what they do. People with very different mindsets, experiences, and ideas. That’s why ABE is so inspiring.

Below you will find some of the most interesting ideas I’ve heard during the conference that might be inspiring for you in thinking about how you and your team works.

Dealing with DDD: Disruption Driven Development

Jakub Bażela

There are situations when the development process gets interrupted with constant, usually urgent issues that need to be addressed at the moment. It’s called Disruption Driven Development and it’s not really efficient. Similar to our brain that doesn’t like context switching, software development teams’ productivity drops significantly in such an environment.

Jakub Bażela told us about the methods he tested to tackle this problem that didn’t help: having shorter sprints, dividing the day into development and fixing issues, having dedicated superhero roles that deal with issues. None of these proved successful.

What worked for Jakub Bażela’s teams were eventually three things:

Planning for the 80% capacity of the team, combined with fighting against “being busy” concept. Empowered product owner — the one that is able to really act on the information about the cost of interruptions. Educated stakeholders — showing the real cost of context switching.

User story mapping

Aleksandra Pyta

Aleksandra told a story about a project that was half-way through when it turned out that a client and a team are speaking about quite different products, flows, and features. It happened that the requirements evolved in the meantime and it was super hard for the team to grasp the scope of a project and estimate the work needed to be done. As she summed it up: “The team was heading right into an iceberg”.

What worked for Aleksandra’s team was user story mapping. They used it as a tool and framework for setting up the common ground, finding a common language with the product owner and finally enabling the team to understand the vision and product.

User story mapping has been described in details by Jeff Patton. A user story map is basically a grid of user stories which are laid out under headings that represent the user’s experience moving through a product.

Here is how Aleksandra’s team approached user story mapping and how it eventually saved the project:

A user story map was created in Trello.

It was created first internally by her team.

And later on consulted with a product owner.

Visualized agreements (screenshots with annotations) helped with negotiations and created a decision registry that enabled the team to hold on to something.

Upstream Kanban — what’s in there for Product people?

Radosław Orszewski

Have you ever wondered where do the tasks that appear in the Product Backlog column on your kanban board come from? They certainly don’t drop from the sky. Sometimes defining them requires quite a lot of time, research and deliberate business decisions. That’s why in some of the projects, it makes sense to extend the kanban board to the left and create an upstream/discovery kanban board (vs. downstream/delivery board). That way you can organize the process around task discovery, research and scoping.

Radosław mentioned 3 things that you might want to consider when creating such board:

Set up the right stages that define the work around the tasks that needs to be done: ideas, user interviews, research, cost estimation, etc.

that define the work around the tasks that needs to be done: ideas, user interviews, research, cost estimation, etc. You can agree on minimum and maximum WIP limits on each of the stages.

on each of the stages. You can also have certain CONWIP limits — constant number of tasks that you want to have on the upstream board so that you secure the flow of new tasks to the downstream board.

Remote work(s)

Michał Grześkowiak

As we’re a remote-first company, we love to get inspired by other people working in this model. Michał shared lots of interesting best practices that enable his company to focus on individuals and interactions while working remotely.