Over the past weeks, we have thought a lot about Don Reinertsen‘s ideas on Second Generation Lean Product Development. His input lays the foundation for understanding methods like KANBAN, which was created by David Anderson and is currently being sold as the counterpart to Scrum. Having dealt with the ideas of Don Reinertsen intensely and having visited Anderson‘s seminar last year, it has become increasingly less clear to me why people believe that Scrum and KANBAN are entirely different. Alright, so these two may have different best-practices, but by the time that cadences are introduced in KANBAN Teams or a second row is entered on a Scrumboard to separate two projects from each other (swim lanes), the differences quickly subside.
So why are there still differences and why is there such a heated debate going on about whether Scrum is “revolutionary“ or KANBAN “evolutionary“ (David Anderson)? And why is it that in the beginning, I myself had felt heavily disappointed by KANBAN? I had not been able to see anything new in KANBAN aside from the idea of better metrics and the possibility of now being able to explain why Scrum actually works. Contrarily, I was able to see the disadvantage of KANBAN in inhibiting the agility of a Team by allowing it to include waterfall methods.
Two sides of the U
Finally, our Team member Sven Winkler – co-organiser of the Agile User Group Nürnberg (Agile Monday) – came up with the solution: Having learned of Theory U, one of the focal points of our ScrumMaster Pro Training, he came up with the concept that KANBAN positions itself on the left hand side, while Scrum sits on the right of the U. Eureka!
Of course! The power of KANBAN lies in pointing out the work and its bottle necks. Without having the problems lined up in front of one‘s eyes, one is not likely to change anything. KANBAN starts off by recording the current processes, depicting the value chain and pointing out bottle necks. This may create awareness about their ratio, yet no change is actually asked of the Team. Only when the Team itself realises that some step of the process is not working anymore, will it act. A “Work in Progress“ limit will then be introduced, followed by cadences and finished off with Retrospectives.
On the other hand lies the right side of the U, incorporating the solution, the synthesis and the epiphany. Scrum works by knowing which process (that is to say the Deming Cycle) will lead to continuous improvement and by making it clear from the very beginning that certain responsibilities must be fulfilled. Based on a scientifically evaluated, case study-proven image from the 1980s, this method has established itself by knowing exactly how product management should really work and what it takes for Teams to become truly successful. Scrum takes advantage of certain aspects that would become just as clear if KANBAN were applied over a long enough period of time. In his seminar, Don Reinertsen actually mentioned that Scrum is nothing else but Second Generation Lean Product Development.
In a way, Scrum already presents the solution:
Focus on the Team, transparency, best practices i.e. the Taskboard, cadences, regular meetings and deliveries, work in progress limits on the fly = WIP/ per Sprint = commitment and the Backlog.
Ergo, the idea of thinking in deliveries and not in Tasks.
Scrum leads to resistance
However, all of the above lies on the solutions side and not – like KANBAN – on the analysis side. If you take the SCARF model of David Rock (Your Brain at Work), you will immediately notice why Scrum often leads to resistance from Teams and Managers, whereas KANBAN is more easily integrated and adapted:
- Scrum evangelists approach Teams with the words, “You have to work differently“. This leads to resistance, as it reduces the status of the Team.
- Scrum evangelists often say, “You are the Team! Find out for yourselves how you would like to work“. This leads to instability and insecurity within the Team. KANBAN says, “For now, don‘t change anything. We appreciate what you have done so far. Hence, find out for yourself what you want to change.” By acting in that way, they respect the Principle of Autonomy more than the Scrum evangelists, since the Team eventually still decides by itself what it wants to do.
- David Rock further states that a bond between humans is important. Scrum pushes people into a “we are different and you have to change“ corner. This is not exactly how bonding works. KANBAN, however, does exactly the opposite by saying, “We are like you. We‘re just asking what kind of process you follow.“ (In German organisational development, this is called “Turn the affected into participants“).
- Last but not least: Scrum evangelists infringe on the topic of fairness. They highlight that the work processes – which had been adhered to until then – are far from perfect and that i.e. the Managers are to be blamed. Humans don‘t exactly like being shown in a negative light. In this respect, KANBAN again choses a softer approach due to being situated on the left side of the U-curve. KANBAN starts off by raising awareness and by using the explicit sentence of “The affected always know best how to work“ – hence, KANBAN ensures the statement of: You guys are okay!
Especially for the middle management – the usual source of resistance towards change – KANBAN, at first, seems to be the less dangerous option. Many consultants utilise this idea and make Scrum‘s reputation of changing things to their selling point – by positioning themselves against Scrum instead of against the waterfall. Instead of wanting to change traditional management, they want to be agile without Scrum. These consultants apply a very clever rhetorical option for persuasion by simply laying out a nightmare scenario with Scrum: “Scrum changes things, however, it is not yet clear what will happen to you as Manager. Scrum first changes the roles, so it is important for management to just go along with it“. 
Now, some of you might say (my wife had immediately intervened upon reading the last lines), “He is writing against Scrum – he is writing against his own business“! Well, at first glance, that is true. At least my readers now know how to effectively pitch KANBAN against Scrum. However, there is one thing that I have to get off my chest: Scrum is on the right side of the U. Scrum is the aspired mindset: It already includes Jurgen Appelo‘s Management 3.0 or Gary Hamel‘s Management 2.0 [https://www.phoenix.edu/lectures/gary-hamel/management-2.html]. Scrum has taken up IDEO‘s ideas on product development. Today, we are talking of the Discovery Phase – which is indeed happening in a fundamentally different way than the Zero Sprint that some had demanded. This phase is necessary, as we have come to understand that more than one Backlog is needed. Scrum has unveiled the fact that many companies still have fundamental knowledge deficits. This includes the developers that lack agile development practices, the product managers who are nothing but requirement managers, and the management that can‘t cope with creating an environment that fosters Team development. Together with the new development methods, Scrum has shown us the future, the vision.
The way that Don Reinertsen presents the Second Generation Lean Product Development in his book as well as his training, it seems like it is not yet incorporated in KANBAN. He talks of including ideas from the German warfare in the management of product development (mission-type tactics and manoeuvre warfare), while adding ideas from the US Marine Doctrine, such as “less detailed planning, little status reporting, reaction to battle, decentralised control“ etc. This way, he creates a model of the agile organisation, which we are already familiar with thanks to Peter Drucker and Tom Petersen – and which is today represented by Gary Hamel. It fascinates me to see that, again, war is the origin of all things: Scrum was invented by US military alumni and Second Generation Lean Product Development by a former marine officer. Could it be that ideas,which stem from situations where speed is important to gain new territory, might be the answer to the development of new markets and products? It has always been about the NEW NEW PRODUCT DEVELOPMENT GAME. How about we finally create companies together, in which humans can develop themselves in an optimal way.
 By the way, it‘s not like I just come up with these kinds of arguments. At the OOP 2011, a consultant approached me with exactly this chain of arguments as his sales pitch. Back then, it had truly shocked me. I had always thought that we – the Agile Community – wanted to “fight“ the waterfall, the management of the 19th century, together. The idea of trying to make a method look bad in order to sell one‘s own method – even though it has proven to desire the best for everyone – was simply alien to me. Of course, I had written against KANBAN, but only because we were already a lot further with Scrum than KANBAN. To me, KANBAN was and is a step backwards.