David Anderson’s Kanban book and the myth of early adoption

May 25, 2010 — Posted by Al Shalloway

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.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

Alan,

I think u hit the nail on the head with this post.

I have been using agile in a very non agile friendly world (blue chip enterprise applications as a consultant for a tier one consulting firm) and have always faced stiff resistance and many challenges in implementing it. That doesn't mean I don't love agile, but I've always had to mask it, or constraint it to fire walled environment where my team could be free.

Over the last couple of years I've been engaging clients in a pure agile coaching capacity ( as opposed to running projects ) and to be honest most banks, public sector, etc appeared a lot more interested in talking than in actually engaging. With the introduction of Lean and kanban something seems to have changed. The message of a measured, evolutionary model that allows the conservative to proceed at their own pace is one that resonates in areas where agile has had the least penetration, big conservative, politically charged IT ors.

I must be talking at least once a week to a bank exec about how kanban and lean can provide value, I know the techniques are relatively easy to pick up, but they are powerful.

I can't wait to see what's next...

In my opinion Kanban's visual approach, focus on priorities and most important tasks first and constant improvement are the key success factors.

I found a bunch of really good articles and presentations on transition from Scrum to Kanban (http://kanbantool.com/kanban-library/scrum-and-kanban) and case studies (http://kanbantool.com/kanban-library/case-studies) in Kanban Library.

I also think that Kanban is a visual approach, but for me the most important thing is that Kanban helps you find where the value is created and you can easily see where you can eliminate wasteful activities.
Actually, you can also find some good resources related to Kanban here https://kanbanize.com/

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban