Just recently I attended Lean 2010 in Atlanta, GA, April 21-23, 2010. I ‘learned’ something that I didn’t know before… basically that Scrum / Agile is broken and Kanban software development is the answer. I heard two presenters at the conference giving experience reports that distinguished Kanban as being separate from Agile development approaches.
When I sought clarification, folks could not provide even vague reasons as to which basic agile principles Kanban violated that made it non-agile. When I dug deeper, the reason that these organizations failed with Scrum became clear. It had nothing to do with the approach but, as is more the norm, it was organizational issues and a lack of understanding / ability to execute the Product Owner role so as to produce and manage an effective product backlog.
I was amazed to hear how this problem went away with Kanban, that “the work didn’t need to be broken down; it was already the right size because we weren’t worried about iterations.” Wow, I thought, could this be the silver bullet we’ve all been looking for?
Unfortunately, after digging a bit deeper it was disclosed that the organizations had actually restructured their Product Owner role by establishing what I, and others, call a Chief Product Owner. Additionally they added a few Business Analysts to work with the CPO in ensuring the Product Backlog contained adequate items that had been sized, estimated and prioritized to feed the development team. This prevented delay, thus waste, for the team by allowing them to avoid becoming idle or having to waste time breaking down queued items that were too big to consume during an iteration.
There was also a claim in one of the experience reports that the presenter’s team saw a substantial increase in productivity when moving to Kanban. Upon further disclosure from the presenter, their implementation of Scrum had been mandated by upper management and pushed upon the team. We all know how well that works without proper transformation consideration given.
On the other hand, Kanban had been discovered by the development teams in the organization. They evangelized and made the request to move to Kanban, which was allowed. The Team was more productive with an approach that they found, lobbied for and implemented rather than one that was shoved down their throats? Really? Big surprise!
While I realize this was a Lean conference, this type of experience reporting is misleading for folks that are new to Agile or Lean software development.
Lean / Kanban is not a silver bullet, and the problems that challenge agile implementations are largely the same. It’s not the process, the technology or the tools, it is the lack of understanding of how to execute change in an organization, an organization’s unwillingness to change, and the classic illusion of control, with the belief that projects can be estimated and planned up front and then have teams held to precise commitments.
While Lean and Kanban are powerful ‘tools’ for a practitioner’s utility belt, they do require a certain amount of trust between management and the teams working in a Lean fashion. This trust, from my experience, is something that comes as teams mature following successful agile executions. Successful delivery and effective continuous improvements are great boosters to trust, but some has to exist to begin with or the change required to become effective with Agile software development won’t likely happen. I look forward to watching teams that have taken the training wheels off their Scrum software development endeavors begin to implement Lean and especially Kanban.
There are several good books that explore merging the principles of Scrum and Kanban such as “Scrumban” by Corey Ladas.
So before you dump Scrum and chamber Kanban as your silver bullet to slay the agile software development beast, study up, talk to some folks that have been successful with Scrum. Ask what is different about their organization and development context from yours. Then use common sense and make some incremental changes that you can measure and that you think can make a difference in your organization’s context.