In the first part of this post we established a context about Kanban as an agile software tool (not to be confused with the manufacturing term, kanban). I also explored some of the key myths and hype behind Kanban vs Scrum. Now I’ll discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.
On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:
- Provide a high degree of visibility/transparency of the state of all work queued and in progress
- Establish and respect WIP limits in the value flow
- Commit to execution in a ‘pull-based’ manner from the prioritized work queue
Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!
Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).
Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.
This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams. These outcomes in turn destroy brands, ruin company reputations on Wall Street, increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.
Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability. But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.
In conclusion, I leave you with this advice: ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:
- Your organization’s product development and sales culture,
- The nature of the demand for service from product development,
- The competency of your organization to plan and execute change, and
- The degree to which you’re willing to face the truth
Only then can you choose the best agile software tool for the job.