If you are thinking about transitioning your team to Agile, more than likely, you already know about Scrum and have at least heard of Kanban. You likely have heard many things about both approaches, but Kanban seems like a better choice. Beware! Before you go further down this path, you may wish to consider the following common misconceptions about Kanban so that you are aware of what Kanban can and cannot do for your team.
Keep reading and see if you have heard of these already!
Misconception #1 – Kanban is easier than Scrum
This is quite likely the most common misunderstanding about Kanban due to its simplicity. Kanban is a flow-based approach with minimal structure which means it requires your team to have a much higher level of discipline to make it work. As compared to Scrum, there are no prescribed events or activities in Kanban – no planning, review, daily meeting, etc. This can create an illusion of simplicity, which seems counterintuitive as your team will most likely need to figure out how to implement this approach without formal guidance.
Misconception #2 – Planning is not important when using Kanban
Most teams that apply Kanban approach choose this method over Scrum because their business domain is highly-unpredictable and nearly impossible to plan their work. Notice I used the term “nearly”; while teams may take a casual approach to application of Kanban, planning is still important and take on a different form. Flow-based planning is vastly different from what you may have experienced in a Sprint Planning event; the team will not aspire towards selecting and committing to work, since work items may not have been identified yet, and will likely be introduced more organically over time. The planning activity in a Kanban team is more focused on defining the criteria for prioritizing work (i.e. Service Level Expectations) so that your team can apply the appropriate level of urgency to the work items/request when they arrive at some point in the near future.
Misconception #3 – Applying a WIP (Work In Progress) Limit is optional
Applying a Kanban approach to managing work without taking advantage of the WIP limit is like buying a Ferrari and only driving it to the grocery store; if you choose to do so, I’m happy for you, but the point is that you would be losing out on possibly the biggest benefit of this model that can revolutionize your team and empower them to out-perform other teams doing similar work!
Establishing a WIP limit is often mysterious because there is no single “textbook way” of doing this, which is one reason that many teams decide to avoid doing this. Most teams that I work with typically start with this formula: Total # of team members MINUS 1. If you have 5 people on the team, set the limit for total number of in-work items to 4 to actively encourage swarming and identification of bottlenecks in your process flow.
To sum up, Kanban was designed to be simple, but it would be risky to assume that simple means easy. The simplicity encourages experimentation and adaptation, which are key to helping your team fine-tune the process and achieve the optimal throughput and quality. It is my hope that this article helped to dispel some of the myths surrounding Kanban and that you found a few nuggets of useful ideas to share with your team today!