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”.