A client of ours related an internal conflict at his organization regarding kanban and Scrum; which was better, and how do they interrelate? This post examines that issue. Also, check out our related interview with the author, Arlen Bankston.
Kanban is an interesting set of tools that can generate good data. For instance, measuring average cycle times for different service classes can help set expectations for work such as operational responses and defect resolution, in addition to new development delivery times that standard velocity tends to measure. If properly tooled, measurement is automatic, so this is useful, though not fundamentally different from velocity measures in Scrum. Team allocation is generally determined situationally in kanban, but given the costs inherent in large batch handoffs between skill sets, cross-functional team structures such as those in Scrum are often still adopted as the most efficient and effective approach.
Nothing in kanban is contrary to or in conflict with core Scrum, and they’re frequently used together or hybridized. To whit:
- Many Scrum teams use kanban-style task boards; there are no rules about what exactly a board should entail in Scrum, just that work should be visualized.
- In a “Scrumban” style approach, a team might simply fill unused slots at Sprint Planning, and see how many get done on average in a Sprint to gauge Velocity.
- Policies around how much time to spend dealing with new development versus operations and so forth may be explicitly set via classes of service in kanban, or outlined in Working Agreements in Scrum.
- Extra stories are generally prepared in Scrum, then pulled if teams finish their committed work early, effectively creating continuous flow as in kanban.
Continuous Delivery:
With regards to the comment on continuous delivery, nothing in Scrum precludes it. Scrum prescribes a development cadence and synchronization opportunity with its time-boxes, but delivery could be (and should be) on demand. That Kanban is somehow better aligned with CD is a nuance that eludes my understanding, unless of course we are talking about the ideal of a “one-piece flow” – from concept to cash.
Other considerations:
Scrum might seem overly prescriptive and dogmatic about its various ceremonies and practices but it was a breath of fresh air when first introduced, given where we were coming from. The surging interest in Kanban maybe fueled less by its solid lean underpinnings than by the notion that is it less prescriptive. That doesn’t necessarily make it easier or better in terms of adoption.
- The rigor and prescriptive nature of Scrum is actually helpful for new teams and those new to lean/Agile principles.
- Planned work that is inherently iterative in nature (cyclical and feedback-driven) seems better aligned with Scrum than Kanban, which is better suited to unplanned (doesn’t imply unknown), interrupt-driven items that follow a linear progression. For new product development, I would prefer Scrum.
- While Kanban doesn’t proscribe any specific planning meetings, it does imply and demand continual grooming of the backlog so that the team can always pull stories off the top of the backlog. If that is indeed the case, then some of the scheduled planning meetings are really context-driven and can be held only when needed, if needed at all. Scrum may frown upon it, but does it matter? In this case it’s eliminating waste.
- WIP limits constrain the amount of work in flight and are great for identifying bottlenecks and smoothing out the flow of value. The bane of time-bound Sprint with no explicit constraints on the number of items in flight work often results in last minute heroics in some teams and the risk of not reaching satisfying quality. Applying WIP limits on a Scrum board can actually tighten a sprint commitment.
- The ideal Kanban system is one of “single-piece flow” – one feature worked on by the team until done to satisfaction and shipped. This implies work being done in simultaneous phases which in turn demands high engineering discipline and an XP lifestyle. Short of that, teams would probably work on multiple features which could lengthen cycle time.
- The lack of a fixed time-box in Kanban may impede some of the predictability that iterations provide.
I could go on, but hopefully I’ve made my point. I see no reason to force either approach; let teams start where they’re most comfortable, and allow significant flexibility in technique and tool adoption while maintaining some reasonable standards around information capture and sharing. Teams will appreciate this levity and trust, and feel more ownership of their work, thus supporting better morale, quality and accountability. If you measure the impact of various things that teams try, the best approaches for various situations that are unique to your organization will simply become apparent over time.
