I've had an interesting last 5 weeks – 3 conferences and a week of vacation! I keynoted at Agile Japan in Tokyo alongside Professor Nonaka (co-creator of the general Scrum product development method from which Jeff Sutherland created the Scrum Software Development process). I gave two talks at the Lean Software and Systems Consortium (LeanSSC) conference in Atlanta and I just sponsored and talked at the San Diego PMI. All with a vacation in between where I was able to reflect on the industry (those who know me know I never totally disengageJ ). These last few days I've been re-reading David Anderson's Kanban book – which I highly recommend to all software developers and managers.

The conferences represented very diverse audiences: those new to software agility, experts in software agility, and those unclear what Agile even is (and with many not even in software). Nevertheless, there was a common theme across all three: Respect for management, the recognition of the need to attend to the whole value stream, and a belief that people were good and if there were problems you needed to look at the systems in which they were working rather than accuse the teams of lacking discipline or motivation. It was refreshing! And, unfortunately, not something I typically notice to be widespread in many mainstream Agile conferences (particularly those centered around non-Lean Agile). Fortunately, this awareness is slowly growing in these more mainstream Agile conferences.

I point this out because I believe Agility is entering a new phase.

In our own practices at Net Objectives, we've seen the number of teams of our clients adopting Kanban or Scrumban go from 20% to 80%. We've seen a wide variety of teams adopt Kanban/Scrumban now – with great results.

In the last few months, I've heard several people say Kanban's success is because it is early adopters who are applying it. I actually believe just the opposite is true. While Net Objectives consultants may be considered "early adopters" (we are always looking for the next best thing to offer our clients) most of the teams that have adopted Kanban or Scrumban are actually late adopters. That is, they have gone from non-agile or some kind of generic agile to Kanban/Scrumban. The reason is that they couldn't see how Scrum could work. Or, the teams weren't excited about doing Scrum.

Given that Scrum has a limited context in which it works without major disruption to an organization, this should not be surprising. Yes, I know Scrum is supposed to make impediments visible and have the company remove them. But making impediments painful is not the only way to make improvement in one's process.

Over the last couple of years, I've seen three groups for which Kanban is particularly useful:

• Those doing maintenance work where time-boxing adds overhead with little value
• Those who have specialized skills present which makes it difficult to create well-formed teams where each team member is only on one team
• Those who are nervous about Agile and do not see how it will work for them

Kanban is useful for these three groups for different reasons. Respectively:

• Kanban manages small pieces in a chaotic environment extremely well. And this is the situation most maintenance teams find themselves. Little overhead is added as estimation and planning the iteration is not needed (just prioritization).
• For many organizations, specialization is the only viable route (despite what many in the Agile community would say). Stress testing experts may be an extreme case in skills, but many people are aware of companies that have limited numbers of staff knowledgeable of the intricacies of their own legacy code.
• Kanban was designed to start where people are. This enables a smooth transition from current to incremental delivery with much less disruptions.

It is interesting to note that the last two groups are often late adopters to Agile. For those having people with specialized skills, they've often avoided Agile because they don't see how Scrum or XP can work (neither can I, BTW). In the second, they don't want to try such a deep dive into a new method.

I think much of the reason Kanban has been successful is not because it has been adopted by early adopters, but rather because it was designed for late adopters (that is, those afraid of change). The fact is that many of the success stories of Kanban are now coming from late adopters of Agile – saying otherwise is merely marketing obfuscation. Kanban works not because who is adopting it, but because it was designed to be adopted in an incremental (dare I say, Agile) manner. Scrum, on the other hand, is a "jump in the water (may or may not be) fine." Kanban works because it truly manifests the principles of agility – respect people. Let them use what they know and let them turn up the volume, so to speak, of agility at their own pace. Don't force them into it because they'll know that's the right approach after they've done it. In other words, Kanban consultants tell their charges – "trust yourselves, don't trust us."

David Anderson's book discusses a lot of the motivations behind Kanban's evolutionary style of implementation. This is a great aspect of Kanban. It allows you to adopt it at a rate that your organization can stand. I think Scrumbut is often a manifestation of Scrum being too difficult in many places because too much needs to change or Scrum provides little insights on areas outside the team that needs to change. Either way, teams get frustrated and tired and eventually compromise on what they should do. If you are interested in more on this, I'm currently writing a three part blog series that'll go into the transition aspects of Kanban and Scrum. I'll be publishing these on the Lean Software and Systems Consortium site very soon. I will cover:

• Kanban and Scrum as change agents
• The dark sides of Kanban and Scrum
• An inherent problem with driving from practices

For now, please don't ascribe Kanban's success to who is using it. I think that's a subtle way to discount it. I wonder what early adopters of Scrum would have said if we were told that it only worked because we were early adopters. I know what my reaction would have been back then – my reaction today is similar.

Technorati Tags: Lean Lean-Agile

tag with del.icio.us