I should start this post with some qualifications. I’m an consultant for a company called Imaginet. We’re a full service IT consultancy. Imaginet is a LeanKanban University (LKU) Founding Member organization. I am Imaginet’s Accredited Kanban Training Program Advisory Board representative and I also sit on the LKU Management Board. I’m an Accredited Kanban Trainer (AKT) and a Kanban Coaching Professional (KCP) with LKU. That said, I’m going to try and be as unbiased in my responses as possible, but please bear with me if I rant a bit. 😀
This week seems to have been a particularly interesting week in the volume of rhetoric and misinformation that is being spread about The Kanban Method. I’m not even sure where to start, but I’m compelled to say SOMETHING!
What is Kanban
I saw a tweet from Alan Shalloway (@alshalloway) talking about a great blog post from Joseph Hurtado (@josephhurtado) discussing What is Kanban? In this article, Joseph describes the current state of confusion in the industry around the word kanban and tries to start a movement to provide some clarity.
I’m the first to agree that there is a lot of confusion around the word kanban. In all of my webinars and presentations, I take a moment to provide some clarity on this issue. I think it’s very important that we all do this.
Joseph goes on to add some definitions, which is great.
This is where I start to take exception to his blog post because he then goes on to start actually misinforming his readers. He states:
The problem is that David Anderson, LKU and some other Kanban Consultants have decided that there can be only one valid Kanban method for business or even IT, theirs. In their view if you do not follow exactly The Kanban Method, dare to call Kanban Agile or add any Lean or Agile practices to it you are wrong.
This is so blatantly wrong that I hope it is unbelievable to his readers, but I feel compelled to respond because Imaginet and I belong in the group “LKU and some other Kanban Consultants”.
Our understanding of The Kanban Method (as per wikipedia) is:
The Kanban method as formulated by David J. Anderson  is an approach to incremental, evolutionary process and systems change for organizations.
I’ve heard David (@djaa_dja) speak many times defending this definition of The Kanban Method because as far as I know, he is the originator of the name and the definition attributed to it. That seems reasonable to me. And in those conversations and in David’s classes, I have often heard him embrace specific improvement tactics from other industry-specific methodologies like Scrum or XP. Many of the LKU Kanban practitioners that I have personally spoken with embrace many of these same improvement tactics. David even goes ones step farther than many “Agile” evangelists and embraces improvement tactics from traditional project management methodologies like PMI when they make sense in a context.
What I think Joseph (and others) are doing is trying to define the meaning of the word kanban in a manner that suits them and at the same time belittle David, LKU and it’s members, for trying to protect the definition of “The Kanban Method” which we also sometimes just shorten to Kanban. Joseph and Alan also seems disturbed that we often shorten The Kanban Method to simply Kanban.
There was a time when I thought somewhat like Joseph but in a Scrum context. I often thought that people, who said “You are not doing Scrum” when a team was doing some of the tactics that the Scrum Guide but not all of them, where wrong and mean. Of course we were doing Scrum, just not all of it. I then had a conversation with Ken Schwaber and he put it very simply and it made sense and my thinking change. Ken used the game of Chess as an analogy and said to me (paraphrased) “If you use the rules of chess, you can say you are playing chess. But if you change the rules, are you still playing chess? No. The same goes with Scrum. If you follow the rules provided in the Scrum Guide, you are doing Scrum. If you deviate from the rules, you aren’t doing Scrum.” It seems to me that this is the same issue that Joseph is having an issue with, except we’re going one step further and using an abstract word (in this case) like kanban.
Joseph then goes on to create a new ‘thing’ which is great. Open Kanban. Sounds good until he describes it. And it starts to re-describe things that The Kanban Method has described. It describes some things that LKU Kanban practitioners have described. Which is honestly really flattering. As the saying goes, imitation is the sincerest form of flattery. The problem though is that now there is a competition. The Kanban Method vs. Open Kanban. And we’re back to rhetoric and bickering because honestly, we are all here to make money and grow our businesses.
To wrap up this portion, here are a bunch of thoughts that I hope counter some of the misinformation in Joseph’s article.
- The Kanban Method has a definition. I don’t think we should really argue about that.
- The Kanban Method has a singular purpose. Catalyze (encourage?) incremental and evolutionary process changes for organizations.
- David freely gives credit to all of the people who have influenced his journey and his continuing growth in this space.
- David strives to stimulate continuous improvement of The Kanban Method, especially by reaching out to the community of practitioners.
- Whatever your process is or the process that emerges to help your organization create value, that is NOT The Kanban Method, but simply what The Kanban Method helped you create.
- You’re process will likely evolve towards being flavoured by Agile or Lean thinking. They are both #reallygoodthings
- The Kanban Method is not Scrum. It does not compete with Scrum.
- The virtual kanban system that may be used to help your organization evolve WILL compete with Scrum. The Kanban Method does suggest the use of virtual kanban systems to better manage work. This doesn’t have to be viewed as a bad thing unless you are a Scrum evangelist who isn’t interested in new ideas. Scrum and Kanban both have noble goals.
- Scrum has a virtual kanban system at the heart of its work management system. It just uses larger batches than most kanban practitioners like and couples cadences unnecessarily.
- The virtual kanban system that may be used to help improve your organization will probably use some sort of kanban (visual signals, signboards)
- The Kanban Method does not advocate the exclusion of any kind of improvement tactic for the process or the organization. It just doesn’t necessarily provide specific guidance, which is fine. You are MORE than welcome to pull in unit testing, team formation, automated builds, continuous integration, iterations, tooling improvments, etc. if the specific tactic is anticipated to improve the system.
- The Kanban Method, as a methodology, won’t give you advice on a specific improvement tactic. It does not understand the context and it would be deemed “tampering” (and perhaps arrogant) to suggest improvements without information.
- The Kanban Method does provide guidance on several high-level improvements tactics that will help you create an environment for your organization to improve.
- These high-level tactics usually lack specific implementation details. Let’s call them meta-tactics that will allow for the creation of context-specific tactics.
- Don’t let myths and misconceptions cloud your assessment and the opportunity to learn about The Kanban Method, or any of these other methodologies. Please go out, learn and make your own decisions.
I’d love to talk to you about this. I’ll be at Agile 2013 in Nashville next week. If you’re going to be there and you’d like to discuss any of this, I’d love to catch up with you. Please message/mention me at @agileramblings on twitter and we’ll figure out a way to get together over a pint or two.
“Scrum has a virtual kanban system at the heart of its work management system. It just uses larger batches than most kanban practitioners like and couples cadences unnecessarily.”
I have to disagree at least with the coupling of cadences as being unnecessary. Having an iteration endpoint is like a shared goal for our team. Having a firm goal in sight, for many, provides a sense of motivation or urgency that would not exist in a world where the backlog continually flows in and completed work flows out.
The shared goal helps with team cohesion. For example, our developers are (surprisingly) willing to get on-board with taking on testing tasks, typically done by dedicated QA team members, just to get an iteration wrapped up. Any stories left incomplete when we reach a retrospective give us concrete examples to illustrate ways our team can improve. Our egos push us to minimize the number of such examples while the scrum master guides us to reflect upon them.
The iteration boundary also pushes us to become “release ready” at a given point in time. I know that in an ideal world there should be sufficient tests, tools, and practices to have a code-base be release ready at any moment, but I’ve yet to work on a project that has fully achieved this level of nirvana. In reality, for most of us, there is at least some stabilization effort required.
Another benefit of having an iteration with a finite size is that we are forced to consider breaking down epics into manageable stories. The vast majority of the time this is a really good thing.
In conclusion, to brush aside the of benefits of a coupled cadence as “unnecessary” is unnecessarily callous.
Hello David and thanks for commenting!
I didn’t mean to infer that coupled cadences are always unnecessary because that was not my intent. And I didn’t intend to infer there is no value in iterations.
I think that prescribing a coupled cadences for disparate activities limits improvement opportunities for flow and limits our opportunity to align our activities with upstream and downstream partner activities, especially when the upstream and downstream partners are different. I think that when we are allowed to find the optimal cadences for interaction points with upstream and downstream partners, they will naturally disconnect but not always so we have to make informed decisions about these policies.
To be clear, when I talk about coupling, I am talking about the interface points between upstream and downstream partners and scheduled hand-offs or transitions of work. I’m not talking about the value of rituals and their support of various team-based activities. Goal setting is really important, but I think there are better ways to set goals than to give a deadline. I think that a team that does everything (BA + Dev + QA + Delivery + Support) will like cadences and find them beneficial. I don’t think that is always the case. I wasn’t discussing the value of an iteration or timebox, although I do understand that iterations naturally start and end and couple all the activities inherent in those phases of the workflow.
How would you envision a continuous delivery situation?
Are there other tactics/practices that we could use to drive out the benefits you’ve spoken of coming from iterations?
I too have been having this misgivings about Joesph Hurtardo’s characterization of Kanban – and his having to define and carve out a different definition – while also mis-characterizing DJA’s definition of Kanban. You have well articulated the unease that I was experiencing.
All because of wanting to cash in on a very sophisticated – but yet deceptively simple thing like Kanban, I presume.
Whille I am not aware of his b/g or his history or his motivations – I often wonder how it might have been – if Joeseph had instead chosen to belong to the larger Kanban community – and the contributions that he would have likely made – to it.
Thanks and With Best Regards