The Personal Kanban shows us what is happening, how it is happening, by whom it is happening, and even why it is happening. Here we see a bottleneck between coding and QA. The cause of this is currently unknown. But we have some hypotheses.

There aren’t enough people in QA to handle the load
Something currently in testing is proving problematic
Coding has been unusually hyper productive
There are too many coders
etc.
One or more of these may be correct. We’re not sure which ones.So, we posit that coding has been hyper productive and that this is a temporary issue. We could move some people from coding into testing. So we give that a try.After two days, the board looks like this:Here we see that work has moved along, but that the bottleneck persists. We know that while work has moved along, the root cause has yet to be discovered.At this point, we can employ any number of visualization or problem solving techniques to delve into the root cause. A3, socratic method, 5 whys, positive deviance, or any number of gamestorming methods might help here. When we gather enough information, we can refine our hypothesis and try again.This time, we discover the issue really is that there’s some highly specialized testing necessary. So we bring in an outside consultant to help with that testing. In the meantime, we halt coding and put the coders to work on training. They watch a few hours of training videos by Uncle Bob, they read some books, they have some lean coffees, until the bottleneck is resolved.What we do not do is have the coders do anything that would require testing.Bottlenecks are not the only experiments you can run. If you believe work can happen faster, that a delay is too costly, that something can be more fun - figure out an experiment you can run and how the board can visualize that.Here we have a real live board from a team we work with. They are near a major release of a very large development effort. They felt that having information about the experiences of their early adopters would be helpful, so they created a swim lane specifically to address early adopter issues.These issues were not just bugs with the software, but all tasks relating to rolling out the product to new users. The programmers, testers, and designers are seeing the contracting, implementation, and operations issues and tasks.This experiment was based on the hypothesis that more information would be useful to everyone. There was also a chance that more information would have overloaded the board and hindered development. In this case, the board was used as a process laboratory to test possible good outcomes, as opposed to simply correcting something that was “broken”.

A visual control is anything that allows a group to see their progress, and understand its relative importance. To be sure, a kanban is a visual control, but there are nevertheless some limitations to it. The biggest limitation to a kanban is that it is linear. Work, especially knowledge work, is not always linear.At a recent WriteShop Tonianne and I ran at the World Bank, we set out to run the process with a kanban. It quickly became apparent that the linear flow of the kanban was not going to work with the rapid and recursive iterations of this particular project.This project set out initially to create a document in five days that was made up of several modules. When we started, each module was in a different state of completion. The original assumption was that there would be a workflow that went something like “concept,” “components,” “outline,” “draft,” and “final,” and we’d make a mission-based kanban for each module.What ended up happening was very different. Scientists from around the world sat down on Monday and, fully aware they were not ready to write, instead began to talk. Those discussions redefined what exactly was needed for each module. That was good.What was even better was the evolution – the discussion became a product development discussion. Who was the client? What did they really need? What could this group produce by the deadline?And suddenly we had a spreadsheet model the clients could use for doing the analysis described in the document. That model, in turn, drove an entire, organic, and rapid rethinking of the layout of the entire document. Suddenly we had coherence.Then … it was time to write. We set up a visual control that was deceptively simple. The control has 4 columns: “Module,” “Outline,” “Text,” and “Draft.” This was because we knew that the workflow was not going to be linear. As text was written in the document, it informed what else needed to be in the document. Therefore, some outline would be written, then some text, then the outline augmented, then more text, then some discussion, then more outline, and so on.This means there was no “pull” from outline to text. So we used numbers to mark a 1 to 10 level for “complete” and checked back a couple times a day, crossing out the old numbers and entering new ones.The “Draft” column quickly changed to an “Issues” column. This allowed us to have very detailed stand-up meetings (short 10 to 20 minute discussions) about status twice daily.At each stand-up, the numbers would be entered for each stage. Sometimes they would go down. If you look closely, you can see 8s go to 7s. The group found that amusing, but what was happening was they were learning more and more about what “Complete” in this particular context meant. Clarity for the deliverable was rising on a daily basis, even if the estimation of complete was falling.Some days the “text” ranking would go up, even as the ranking for the same module’s outline fell. People were writing text, discovering new needs, then noting that they weren’t yet incorporated in the outline.The visual control allowed us to build a type of kanban that we might call a “recursive kanban” - a visual control that allowed for the productive loops in knowledge work. Linear kanban has a hard time dealing with productive loops like this.

Work Flow Laboratory: Element #11 of the Kanban

Recursive Kanban – A Visual Control for Rapid Knowledge Work