TBM 36/52: Looking at Example Boards
In this post I am going to try something a bit different.
I am going to:
Share boards inspired by real world teams (I see lots of boards)
Share what I see in the boards
Share links to what people on Twitter see in the boards
Invite you to chime in on the Twitter thread(s)
Why? I think we can learn a lot from how people perceive these things. After one hour, the threads are hopping.
Single Team
Here’s the first board.
What do I (John) notice about this?
The product manager is spread incredibly thin. Are they micro-managing each and every detail? Or are they getting pulled into a million discussions?
The designer is spread thin as well. They are juggling framing bets, doing research, pairing on items in Development and Design, AND monitoring and tweaking things in Limited Release. Poor designer.
It is promising to see developers and designers involved in one-pager framing, but a little concerning that neither developer is involved in Research and Analysis.
The developers are 1:1 with work, so there’s no pairing happening. Why? There is designer/developer pairing which is positive.
There’s a lot of work in progress between Development and Design, Limited Release, and Coordinate Full Release. That is a lot to juggle. The multi-tasking costs alone would be a big drag. 10 things? 5 things? 3 things? That’s a lot of switching.
Overall: Too much work in progress. Overworked PM. Overworked Designer.
Read what other people noticed about this.
Team A vs. Team B
OK. Here are two teams using the same columns.
What do I notice about this?
Team A has 1/4 the amount of work in progress. I would expect them to have much faster flow and focus. Note how they don’t have work in every column. I see this as a good thing. We don’t need to fill every column.
Team A does solution exploration together. Team B delegates solution exploration (and solution selection) to product management and design.
Team A is focused on two modes currently: Solution Exploration, and tending to the item in Beta. These modes feel like a nice compliment to each other—one divergent and one convergent.
Team B’s product manager and designer are all over the place.
I sense that Team B’s product manager has been tasked with putting together a roadmap, hence the four items in Problem Identification and Problem Prioritization. No other team members were involved.
Team B assigns individual projects to individual developers. I wonder why they aren’t pairing? Is it a team of 4, or two teams, one per developer?
Team B is juggling two stages of release in addition to Build.
We can argue about the number of columns here, but I do credit the teams for at least calling the kettle black and making how they work visible.
Overall, Team B has crazy high WIP. Team B is optimizing for starting not finishing. I’m sure they seem VERY BUSY, but I’m not sure all that WIP is helping them.
Read what other people noticed about this.
Slack Queue and “Main Lane”
Last example.
What do I notice about this?
It looks as if everyone is empowered to frame options using 1-pagers.
Instead of creating columns for discovery, design, development, and iteration/optimization, they lump that into one stage. This suggests that it is more fluid and collaborative. Since it is just a single item, there wouldn’t be much guessing as to “where the effort is”.
The product manager seems to own monitoring for feedback after the period of iteration. Are other people not involved at all?
The use of the Slack Time Queue/Lane is very interesting. I’m guessing they occasionally hit a point where there’s down time on what they call the “Main Lane”.
Read what other people noticed about this.
Conclusion
One thing you probably noticed about these boards is that they make a point of visualizing non-coding work. In my experience, teams have far more work in progress than is reflected in the ticketing system.
While it is important to visualize the work, not the workers, it does help to see what people are working on. Obviously, it is only possible to work on one thing at once, but we keep all of those open things in our head somewhere. We often rationalize that we’re “only contributing a bit” to something. Even still, it is in our head.
Action Item: Visualize what is actually happening on your team.
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.
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?