Daily Flow

Blockers, stale tickets, bottlenecks need to be managed regularly to establish flow. An obvious choice for such a flow management to take place is a Daily Standup. Due to the popularity of Scrum, its approach to conducting Daily Scrums has been adopted by many teams for their Daily Standup even those not using Scrum.

Is this meeting format the best choice for teams aiming at improving their coordination?

Let’s start with a look at the Daily Scrum.

Daily Scrum

The traditional format of the meeting is that each team member gets to speak and is expected to answer the following three questions:

1. What did I accomplish yesterday?
2. What will I commit to, or complete, today?
3. What impediments or obstacles are preventing me from meeting my commitments?

It should be noted that the modern definition of the Daily Scrum does not dictate the above approach (anymore) as you can see in the following excerpt from the official Scrum guide.

“The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.”

Scrum.org.: What is a Daily Scrum

The classic Daily Scrum will not be effective in identifying and removing impediments since only blockers might get mentioned by the team members. The modern definition is better but it’s not actionable. Let’s fill the gap.

Daily Flow Management à la Kanban

Kanban’s focus in the Daily Standup is on flow management and thus on the work and not on the (knowledge) workers: „Manage the work, not the workers.“ So, it won’t come as a surprise that you won’t choose the classic Scrum approach. On the other hand, you cannot and should not discuss every single ticket.

We present approaches that you can choose to employ in parts or even all of them. Common to them is that you use the Kanban board (with hopefully recently updated tickets) and “walk from right to left”. The reason for walking from right to left is that Kanban places more importance on the tickets that have progressed further in the workflow. This is a consequence of the Kanban mantra “Stop starting, start finishing”. Any finished ticket reduces the overall WIP (work in process) and consequently throughput time (see Little´s Law).

You can check the daily progress to ensure that you remain in the flow. To that end, you walk the board from right to left with the focus only on tickets that have changed their status (board column) in the past 24 hours. For each ticket, the team member who last changed the ticket status can say a few words about the ticket. Of special interest are those tickets that moved to a buffer (passive) column where the tickets need to be picked up by someone other than the person who just finished working on them.

To just focus on tickets that progress won’t suffice. Issues that need team attention lie often in the tickets that do not progress.

Exception Management

Before we dive into the details of impediment resolution, we should understand that the Kanban board is only a model of the work we’re doing. We should do our best to keep the status accurate at all times. Nonetheless, when we think we have identified an issue, we should always ensure that the tickets have their correct status. A WIP limit might be shown as broken but in fact is not because we simply forgot to move a ticket.

Kanban is a great thinking tool to identify and remove impediments. But the Kanban board alone does not lead to any action. It takes a daily routine to discuss impediments and to identify the right actions.

The typical types of impediments (or flow disruptions) are:

Blocked tickets

It takes a bit of practice to discuss blockers frequently enough but not so often that it results in fruitless repetition. 2-3 times per week might be sufficient. Make sure you identify an action along with the team member taking the action.

Stale tickets

These are tickets that have not changed their status for some time.

• Tickets in an active column might have been forgotten because the work got set aside due to more pressing issues. Or it might be a sign of multi-tasking by a team member. Either way, one should identify appropriate actions to progress the ticket.
• Tickets in a passive column. If the ticket has a high priority, there might be reasons why nobody is pulling the ticket. If many tickets in that column are stale, the WIP limit might currently be broken or currently have been broken.

The next section describes how to proceed with broken WIP limits.

Broken WIP limits

They need to be attended to since they are potential signs of overload, bottlenecks, broken feedback loops and can result in loss of efficiency, deficiencies in quality and increase in risk. Again, we need to differentiate by the column type where the limit breach occurs.

1. A broken WIP limit in an active column can be the result of many blocked tickets in that column. This would be a clear signal to focus on the blocked tickets.

Individual team members having multiple (unblocked) tickets assigned. If there are tickets that have been pulled but no work has been done on them, they can be moved back to the previous workstation. If someone else has capacity and can easily finish the remaining work or can support in doing so, this option should be taken.

In any case, the focus should be on finishing individual tickets quickly so that we operate again within the WIP limit.

2. If the breach occurs in a passive column this might be a sign of a bottleneck in the next workstation.

A breached limit in „Development Done“ for instance can be a sign of a bottleneck in „Test“. If all testers are currently assigned to non-blocked tickets they cannot pull further work. One should not address the broken WIP limit by simply pushing work into “Test” or pressuring testers to pull tickets into “Test” regardless of the team members’ capacity.