Agile Zone is brought to you in partnership with:

Michael became a Certified Scrum Master (CSM) in 2004 and is huge advocate of better (XP) engineering practices since discovering unit testing in 2001. Michael has a B.A.Sc. from University of Toronto in Engineering Science and a M.Sc. from U.B.C. in Computer Science. He has presented at Agile Tour Toronto and the XPToronto/Agile User group on Scrum and XP. His is also an active member of the Agile community and co-organizer of Agile Tour Toronto. Michael lives and works in Toronto, Canada, as an independent Agile and Lean coach, consultant and trainer. Michael is a DZone MVB and is not an employee of DZone and has posted 87 posts at DZone. You can read more from them at their website. View Full User Profile

What’s the first Decision? Implementing Kanban vs Scrum

01.31.2012
| 3496 views |
  • submit to reddit
If your development team or manufacturing team is considering moving to using Kanban vs. Agile Scrum, one of the biggest decisions is choosing the right agile development methods for the job. Let’s discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

The content of this post was written by a guest blogger, Michael DePaoli, whose information can be found at the bottomof the article


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:

  1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
  2. Establish and respect WIP(work in progress) limits in the value flow
  3. 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.

Michael DePaoli Bio

Over his 26 years in IT, Michael DePaoli’s experienced has included serving in different
traditional roles in highly respected companies. The roles have included analyst, software
engineer, quality engineer, development manager, project manager, Director of Engineering,
VP of R&D, CTO and Consultant in companies, such as American Express, Sprint, Deloitte
Consulting, Sapient, Knowledgepoint, Adobe Systems, AOL, NetApp and VersionOne. Michael
works as an agile / lean coach and product consultant with the VersionOne services group.

Source: http://agilitrix.com/2012/01/what%E2%80%99s-the-first-decision-implementing-kanban-vs-scrum/

Published at DZone with permission of Michael Sahota, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)