Rob Bowley has suggested that treating Kanban as a methodology is wrong when it is just a tool. He seems to be suggesting that Lean is the methodology and questions why we needed to call out Kanban in the title of Lean & Kanban 2009 and UK Lean & Kanban 2009.
Israel Gat has responded to Rob with a thoughput piece titled It's not What it is that Really Matters!
My response to Rob is that Kanban has evolved as the name (or "brand") for true pull system implementations in software development. This is as opposed to the application of Lean Thinking to traditional project management or Agile software development and project management approaches. We specifically separated the tracks at the conference to give a day of material for people talking about generic application of Lean Thinking to software engineering, development and project management, while dedicating the rest of the event to people implementing full blown pull systems.
This difference is important. Pull changes everything! When implementing pull, you first have to embrace the concept (or paradigm) of flow. Flow and Pull are two of the 5 pillars of Lean. The other three being Value, Waste Elimination and Continuous Improvement. It is quite possible to adopt and apply the other 3 pillars of Lean without embracing Flow and Pull. Hence, I (and others) perceive a two-speed adoption of Lean in our industry. There are the (yet) few who have embraced all five pillars of Lean and have implemented true pull systems. Those folks resonate with Kanban as a brand -even the folks who've developed their own flavors or solutions - such as Joshua Kerievsky, Amit Rathore and Arlo Belshee (with his branded Naked Planning approach.) For those who haven't embraced flow and pull they are still finding exceptional value in applying other aspects of Lean to their existing approaches. Indeed in the past I created my own Lean approach based on a more traditional agile project management paradigm, the MSF for CMMI Process Improvement method supplied with Microsoft Visual Studio Team System, is based on an Agile method and expands it with Lean ideas to give it coverage of the necessary CMMI process areas. I used to teach a class in MSF for CMMI Process Improvement titled "Lean Project Management" and I gave several presentations on the topic including this one. I came to Kanban and the five pillars of Lean having been down the road of pursuing Agile + Lean and embracing Value, Waste Elimination and Continuous Improvement. I suspect that many others will have to make the journey for themselves. They will eventually get to a kanban based pull system as they gradually add more Lean elements to their base Agile method.
It is likely that the current clear water between the Kanban folks and the Lean applied to Agile folks will disappear in future but for now the differences are significant.
I believe the root of the misunderstanding is in this quote from Taiichi Ohno in his book Toyota Production System
"The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban." -- Taiichi Ohno
People see the word tool and they look only at the mechanism of the signalling cards. The fail to see that without Kanban there is no system. Without Kanban there is no Toyota Production System. So if we introduce kanban (small "k") as a tool to change our process and approach to software engineering should we called it "[Insert name] Development System" and explain that "The tool used to operate the system is kanban." Which might give us...
"The two pillars of the Anderson Development System are just-in-time feature prioritaztion and automation through continuous integration and quality assurance tests. The tool used to operate the system in kanban."
Personally, I'd prefer to stick with Kanban (large "K") as a brand.
I like this quote which gives some clues that Kanban is more than a tool...
"I thought of [kanban] entirely in terms of reducing work-in-process, raising productivity, and illuminating problems. Of course, it is good for all those things. But your basic aim is something else, isn't it? You use the kanban to create a positive tension in the workplace by reducing work-in-process, and that motivates people to do better than they ever thought they could do." -- Michikazu Tanaka
Kanban pull, visual control and the flow paradigm encourage people to: identify bottlenecks and resolve them releasing greater throughput; identify root causes to impediments blocking flow improving cycle time and reliability; identify waste and eliminate it to improve flow of value; and encourage a whole system view rather than a locally optimized developer-centric view.
As Israel Gat points out, there is now significant evidence that adopting Kanban changes the culture in organizations. It encourages greater cross-functional collaboration and end-to-end value stream collaboration. Alan Shalloway has made the same observation. Kanban does this because it exposes the mechanism. It provides a "white box" approach where Agile methods like Scrum are "black box." By exposing the mechanism, a workflow controlled by policies, it opens up the discussion about optimizing those policies to maximize the economic outcome. It lets upstream and downstream folks not involved in the development see the effects of their actions. Equally it allows middle and senior management to see the effects of their actions. This encourages empowerment and self-organization by encouraging pushing authority for policies down to the lower levels including individual contributors and by explicitly exposing policies, for example, pull prioritization and class of service policies, it allows the team to self-organize in a control and risk free fashion. Middle and senior management are not afraid of self-organization because the understand the mechanism - the policies in use - and have authority to change those if required. Kanban brings managers into the process while methods like Scrum shut them out and proxy for them with the Scrummaster. Kanban brings upstream partners such as marketing managers into the process rather than excluding them and proxying for them with a Product Owner.
So Kanban (pull) changes the underlying paradigm from project-centric to flow and value-stream centric. It changes the view of development from "black box" to "white box." It tends to eliminate negotiation and replace it with collaboration. It fully implements all five pillars of Lean. While I talk about introducing Kanban as not changing anything - I mean this at the small level, at the practices, job titles, responsibilities and workflow level. What this message disguises is that Kanban changes the really big important thing - the paradigm under which the work is governed and scheduled. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban
