You’ve decided to create a board to make your team’s work visible: where do the columns on the board come from?
What is your Process?
When teams are faced with this question, their most common reply is a description that mimics the roles individuals play, and how work is handed off from one person to the next:
Naturally, a board design that follows those steps emerges. Very quickly, however, someone notices that although that description seems reasonable, very often work seems to move in strange patterns: going back and forth, or even skipping columns at times. More worrisome, eventually someone will recall those "special cases" where suddenly work requires a different process altogether.
Perhaps we need a different way of looking at the question.
Collaborative Knowledge Discovery, Rather than Hand-offs
The problems stemming from the attempt to model hand-offs can be resolved by taking a different lens, and realizing that software development can be seen as an exercise in knowledge discovery. Alexei Zheglov has written extensively about this process; here's another way of thinking about it:
Imagine that you’re having a conversation with a group of friends as you’re climbing these stairs, with the goal to get to the top to observe the view. The conversation goes back and forth, in random patterns. Perhaps you’re talking about which set of stairs to take next, or commenting on the view so far. At each step you have a better view of the landscape around you, but you keep going, your goal is to get to the top, so you never go backwards.
We can also see development as a “journey”, in which we’re making discoveries, learning new things as we go, and finding the way as we go. We’re always making progress. Different activities may be required each time, maybe in same or different order, and repeating as needed. But learning never goes back.
At each step in the process, different specialists collaborate to reach the next discovery, with one of them being the “dominant” activity at the time, but with all the others also being involved, but possibly in the service of that said "dominant" activity.
When turning this view into aboard, we can choose to see its columns not as the work of individuals, but the moment on the journey where we work collaboratively towards answering questions like those in the following picture:
The “Specification” column in the picture above is not the part where the BAs writes stories, or the “grooming meeting”, but the place where we work collaboratively to answer the question “do we understand the feature?” Similarly, the “High Level Design” column is not there to represent the work of the architect or lead developer, but the collaborative work to answer “Do we know how to build it?” Architectural design, performed by the architect, may be the dominant activity at this point but perhaps as we design we discover that we need more specification, or that we need to implement a quick spike to try something, etc.
At each stage, we move one flight up on the tower: from vague to understood, then from understood to designed, etc. That’s why tickets don’t go back.
How do we discover which knowledge we need to acquire in order to deliver the work
Different Strokes for Different Folks
I pointed out in Part 1 that the mix of work for a team is most likely to be heterogeneous.
As a result, different types of work may require different workflows. We want to make this fact visible on the board, perhaps by having different sections. Resist the temptation to “standardize” columns that require different processing.
How do we process different kinds of work?
Discovering and Visualizing Hierarchical Work Types
With the columns now in place, we can start making some observations about the movement of tickets across the board.
Let’s say that you decide to start an item, and that the first step is to do some sort of “grooming” on it.
The team looks at it and decides that the item needs to be split into smaller chunks.
Then something interesting happens: the individual pieces start moving at their own pace across the board:
However, it often happens that they all need to “accumulate” at some point before they can continue.
What you can recognize here is that you have a series of important points in the workflow: a point where the work splits, and generates smaller items, a reassembly point further down, and a “packet switching” section in between, where the smaller items move at their own pace, following perhaps even different routes, like in a communications packet switching network.
You have discovered that you are dealing with a hierarchy of work items. Some people use "epics" for this, but I think it’s important to go beyond using epics as a “grouping” mechanism and recognize it is a work item on its own (probably the one that is Customer Recognizable), with its own workflow.
Where are all the component parts of a deliverable? What’s the proportion of completeness? What deliverables move together/independently? What’s waiting for what?
Different levels of abstraction follow different workflow, and that can be visualized using separate boards. By doing this, you will most likely discover that, at a higher level of abstraction, the workflow extends well beyond the individual team, and you will start seeing larger, end-to-end services, possibly involving multiple teams, opening the door to modelling external dependencies and shared services. By linking those boards you stand a better chance to really start managing flow end-to-end, managing dependencies and working on coordination issues.
How are various services interconnected?
Another commonly observed patter is that after a "reassembly point", groups of items start moving together through the rest of the workflow: people's attention shifts from individual items, to dealing with batches of items. For example, multiple stories that were tracked individually through development start being considered as a "package" once they move to Business Acceptance Testing, Deployment, etc.
This may be indication that the group of small items has essentially become a new work type, and that you have found a “transformation point” in the workflow.
It may be important to recognize this, as the new work type may have to be managed differently, it may involve different groups, etc. But more importantly, because it allows us to expose the various ways work is treated in batches, which then has implications on flow efficiency and flow: the bigger the batches, the more the chances of delay.
What’s the life-cycle of various deliverables? How are we batching work? What’s the impact to flow efficiency?
Where does Work Wait?
You can usually think of each column on your board as having two sub-columns: “Doing” (meaning, "we’re actively working on an item"), and “Done” (meaning, "we’ve done enough of this activity and we’re ready to transition to the next").
Making these two stages explicit may be illuminating, as way to show where work waits and "piles up".
In some other cases, the workflow can have stages that represent queues. Making this explicit as well can help understanding where work gets stuck, and stops flowing.
How close are we to completion? Where does work stop flowing? Get stuck?
ToDo/In Progress/Done Revisited
So, what about the venerable 3 column, "To Do/In Progress/Done" board design?
This is a board that hides more than in visualizes. The “In Progress” column gives the perhaps false impression of work moving, and hides all the complexity and wait states. That said, this can be a good starting, “transitional” state, and it’s definitely a good start.
An easy way to kick start the conversation towards a more nuanced understanding of the workflow is to ask people to move and place tickets horizontally, according to a rough idea of “completion”, and then start asking questions to clarify what the various stages and wait states are.
What do I need my team to see right now?
This article is part of a series, based on a presentation I delivered at the Toronto Agile Conference 2018. The slides from that talk can be found here.