Recently a co-worker and I had a brief discussion about whether we were using Kanban, or simply using a “task board” for visualizing our work.
Kanban is so much more than only a board with columns, stickie notes, and scribbles all over the place. Kanban is a method, or an approach, to incrementally change/improve your process.
This discussion reminded me that David Anderson, and others, came up with a “Depth of Kanban Implementation” diagram to visualize multi-dimensional depths of your Kanban implementation (all based on the 6 core practices of Kanban).
What is our depth of implementation?
I had a gut feeling that our team was using Kanban very effectively. We were intentionally keeping our WIP low. We used Retrospectives and Daily Standups to promote changes to our process. And we explicitly made our work visual, and our policies explicit.
At least, that’s what my ***gut***told me. At the time of that conversation, I had no way of knowing how deep our implementation truly was.
Others in the community have taken Anderson’s original diagram, and built on it. Specifically, Christophe Achouiantz put together a great tool to help evaluate your depth of Kanban. (It is worth noting that Christophe added one more axis to the diagram – Effects.)
With Christophe’s worksheet, it only took me about 10 minutes to quickly evaluate our depth.
Our depth is what?
After visualizing our depth, we noticed that our implementation was lopsided. Our focus was more on visualizing, improving, and feedback loops…and less on policies, and flow.
Limiting WIP was only a two out of four, mainly because of our team makeup. And Explicit Policies was at a staggering two out of twelve! We don’t have many exchanges of hands, our team is small (only 4 devs and 2 designers), and knowledge sharing is not explicit (it is generally ad-hoc during standups or our internal chat-system).
I was surprised to learn that our depth was so lopsided, specifically the explicit policies.
Does this mean we are “doing it wrong”?
After evaluating our depth, we discussed the outliers…namely, explicit policies. We talked about our approach to making policies explicit, and what the deeper implementations would look like on our team.
Ultimately, we decided that making policies more explicit wasn’t something that we would benefit from as much, as compared to making our work visual and keeping our WIP low. Again, we are a small team of 6. The implications of not making policies explicit is minimal and the opportunities to detect problems is very high.
Having a low depth does NOT mean that you are doing it wrong…instead, it indicates an area of possible improvement.
What is next?
In the future, I plan to update our depth diagram and use it as a tool for measuring, learning, and improving. We can use the depth levels to highlight potential areas of improvement. We can also use the depth levels to give us a guide for how to improve.
Do you know your Depth of Kanban?
How do you look for potential areas of improvements in your team’s processes?
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
