Controlling Chaos or the Scientific Method

July 29, 2012 — Posted by Al Shalloway

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:

  1. Propose an underlying model (hypothesis) of a particular phenomenon
  2. Make a prediction based on this model
  3. Run an experiment that tests this prediction
  4. If the evidence supports the prediction, you have evidence that the hypothesis is correct, if the data doesn’t match the prediction, the hypothesis is disproved

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 alshall@netobjectives.com

Alan Shalloway

CEO, Net Objectives

 

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.



        

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