I believe there is a significant difference between trying something and responding to what happens and trying to create an underlying model and testing one’s understanding. Scrum's stated underlying approach is based on the first, Kanban's on the second. I believe this difference to be more important than Scrum has iterations while Kanban does not. Everybody, of course, says they believe in the scientific method. But in the software world, many also say software development is too complex to attribute any cause and effect to things. While portraying themselves as scientists, they actually say we must take an empirical approach and not attempt to create models that would explain the behavior we see.
I strongly disagree. I have written many blogs on this over the years. Here are a few:
I believe the mindset one has is important. A mindset is like a pair of colored glasses - the mindset both facilitates and obscures ideas – in much the same way a pair of colored glasses blocks certain colors while tinting everything else.
Discussing mindsets is challenging however. But I realized that the contrast between controlling chaos and using the scientific method provides exactly the distinction I was looking for. Controlling chaos has been used as an underlying explanation for Scrum ever since I can remember. Unfortunately, few people actually understand chaos and tend to think it implies some degree of randomness or non-determinism.
Chaotic systems are characterized by small events having large effects on the system’s results. Some chaotic systems display this behavior with extremely small actions making them unpredictable. Theoretically, an extremely miniscule event can achieve a huge effect – the so-called butterfly effect, where a butterfly flapping its wings in one place can cause a hurricane in another. Chaotic systems may be deterministic, but, given their extreme sensitivity to events may appear not to be.
Controlling chaos means that one can not look at understanding the underlying model of the system one is working with, but rather, must deal with the system in an empirical manner, doing something, seeing the response and then responding to that. One’s method is limited to trying things, seeing their results and then adjusting.
The scientific method, of course, is considerably different. It involves a four step process:
When a hypothesis is disproven, it is often not abandoned, but rather modified.
The difference between these two models of learning is significant and has considerable consequences. The underlying model of Kanban is, of course, lean-product development flow. Kanban is based on continuous learning via the scientific method. Kanban boards and managing work in progress (WIP) represent the ongoing experiment called our work. The board represents our understanding of the best current way of doing our work. Explicit workflows provide us with clarity on what we are doing. Queue sizes and cycle time provide us with a measure of results. We make small, frequent,improvements to our workflow based on the results we achieve.
Because we are using explicit workflows based on a scientific understanding of software development, others, besides the development teams themselves, can understand what is happening in the teams. This enables us to create a common vision of how and why things work across the organization. This helps management understand the cause and effect of their actions. This scientific method enables management and teams to work together and create a shared understanding. The notion of chickens and pigs would never arise - we are all in this together.
Classic Scrum bases its approach on taking an empirical approach. We see the impacts of this in both how individual teams work, how teams don’t attempt to include management in their methods (except to remove impediments) and the lack of an over-reaching approach to coordinate teams other than Scrum-of-Scrums which is essentially an empirical approach at scale.
Putting lean practices into Scrum is not the same as having iterations in Kanban because even though the practices may look the same at first glance, the underlying belief systems in which they operate are not. If your underlying beliefs are different, you will get different results even with similar practices. I am recently realizing that it also explains why statements put forward by the Kanban community are answered by with comments about those making the statements than about the statements themselves - If you don’t believe in science I guess you have to believe in personalities.
The irony is that I believe more and more people who are starting to adopt Scrum do believe in a scientific approach, but don’t understand that the Scrum they’ve been taught does not include it. It’ll be interesting to see where Scrum ends up in a few years. For my prediction, see my recent blog How To Get the Scrum of 2017 Today.
To see what we're doing today, based on the science of lean, see the Net Objectives Lean-Agile Roadmap.
Of course, I invite anyone who is looking at how to extend their use of Scrum to be effective at the enterprise level to contact me directly at [email protected]
CEO, Net Objectives