2 Comments

Using lanes has been sort of "deprecated", it's a good idea in principle but an anti-pattern in practice because having things moving at a different speed from the rest of the work invalidates stastistical measures such as cycle times (that's the reason behind the priority lanes, I don't understand what kind of lane that slack time thing is supposed to be, it doesn't look like a priority lane to me).

The client/receiver of the "done" work doesn't really care what you do with your slack time: and filling your slack time with additional work is kinda against flow principles, so I'm a bit puzzled by that lane, I would have so many questions for that team.

Also, lanes and queues are different things: lanes are horizontal, queues are vertical and used to divide one single phase of work into doing / done in order to spot bottleneck. I don't see any queues from the standpoint of kanban practices, I can't see where the bottlenecks are.

In the first three boards I see no work-in-progress limits and in the fourth board my read is that they have 4 activities going on when there should be 2, so we are lacking or ignoring one of the fundamentals of kanban, limiting work in progress (the fact that one teams has more than the other is not useful).

I would stick to way simpler board designs and track four fundamental flow metrics (item aging, throughput, work in progress, cycle time), without those these boards are pretty much useless to me.

Expand full comment

Slack Queue and “Main Lane” is an interesting approach.

Some questions I'm curious to understand:

1. Columns with 'bundled' activities: discovery, design, developement. Do you see challenges with islolating/identifying bottlenecks in the system? As when I interpret the board, it may prove difficult to understand if there's bottlenecks in either disc, design, dev (or all of the above)?

What would you often consider a 'Slack time queue' work item?

Expand full comment