Nowadays Kanban is a well-established Agile development approach and various teams either dabble in it at least once or have adopted it for themselves. I believe Kanban can be a great fit under circumstances where Scrum with its fixed iterations can pose some serious challenges, e.g. working in more of a support or break/fix environment. Like everything else in life, Kanban has its pros and cons and while it excels at flexibility, predictability seems to be more of a challenge than with other approaches.
Some of the basic tenants and techniques of Kanban include
- Visualizing your value stream
- Optimizing throughput via work-in-progress limits
- Measuring and optimizing flow
- Reduction of waste
- Pull-based system
- Explicit policies
- Classes of service
Some of these practices and techniques will need to be established early on in the adoption process, such as visualizing the value stream, while others will come later as the system evolves, e.g. classes of service. Another key prerequisite is that work items flowing through this system should be relatively small (or at least not large) and of similar level of granularity. This ensures items keep moving through the system.
Kanban seems “easier” than Scrum and for good reason since there are fewer “rules”, roles, and ceremonies. But Kanban isn’t trivial. In my experience, it requires more discipline than Scrum for a team to practice Kanban well and get really good at it.
Unfortunately, I’m seeing a lot of this happening: A team isn’t doing all that well with Scrum. They hear about Kanban and think they’ve found the Promised Land. Gladly they drop iterations. The value stream is often not thought about much and remains very simplistic. More often than not, other practices are also thrown overboard: no more planning (ad-hoc or with batches of items), retrospectives, sizing, and task decomposition. (They’re all waste, right?) Maybe the daily stand-up survives. Perhaps as a result of little to no planning and sizing, item size variances creep in and work items become less thought-out and defined. Then items get stuck on the board either based on their large size and/or external dependencies (which often would’ve been resolved previously with Scrum before an item would enter an iteration). If WIP limits exist, they’re either way too large (how does 15 sound for a team of 4?) or mostly ignored. Suffice it to say, classes of service and explicit policies never emerge, measuring is forgotten and items are pushed through the system.
What’s the result of all this? Lack of visibility & transparency, inconsistent and subpar performance, potentially poor quality, almost complete lack of predictability and more often than not stakeholders and business owners who don’t know what the status of their development projects is and when to expect features.
If we compare this end state to real Kanban, I’d argue there’s more resemblance to “anything goes” or the “Wild Wild West” than actual Kanban.
Don’t get me wrong: I like Kanban. Under the right circumstances and with a disciplined team willing to learn a new approach and get good at it, there’s tremendous value to be realized. But let’s not kid ourselves: throwing out iterations and using a board doesn’t make you a Kanban team. That’s what I would call “none-ban”. Adopting real Kanban takes work, discipline and requires evolution and maturation the same way a Scrum team will learn and get better over time.
Since Kanban does require a significant amount of discipline, I’m tempted to suggest that new teams don’t go straight to Kanban, but cut their teeth by building a solid track record and discipline with Scrum first. Then going to Kanban gives them a much better chance to continue with discipline in a less structured environment.
As mentioned in one of my previous posts, “structure” is not a bad thing and the less experienced a team is, the more it might need to become a high-performing team. A Kanban team, just like a Scrum team, needs to start basic and then evolve, which may involve adding additional structure (e.g. classes of service). We should be concerned about removing so much supposed “waste” that the team never makes it out of its Kanban infancy and stagnates way before reaching its full performance potential.
So let’s be clear about what Kanban is and what it isn’t. Otherwise we may end up giving Kanban a bad name despite of all of its potential benefits.
