Explaining Lean By Showing How To Make Scrum Truly Incorporate Lean-Thinking

Note: This article is a work in process. I will be adding sections to it over the last 2 weeks of February as I hope to complete it by March 1. I will put dates on the sections I add. I will announce updates on twitter when I have them. You can follow me there at @alshalloway

This article provides a Lean primer to anyone who is familiar with Scrum. Its purpose is three fold. First, to illustrate what Lean is in a pragmatic manner. Second, to demonstrate that Scrum is not Lean, although it borrows from a few Lean practices. And third, to provide a path for those doing Scrum who wish to become truly Lean.

In 2007 Ken Schwaber and Jeff Sutherland unequivocally stated that Scrum was not based on Lean. In 2009 Ken disavowed the Lean practice of explicit workflow stating it’d lead to mechanistic processes. The Scrum guide now says “Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.”

Notice that stating that “Lean Thinking reduces waste and focuses on the essentials” merely states what Lean achieves. There is no mention of its thought processes, how it accomplishes this or even what its essentials are.

I assert that Scrum is a poor reflection of Lean. Although it includes a few diminished Lean practices, it incorporate virtually no Lean-thinking. Furthermore, many of Scrum’s practices are counter to Lean-thinking. Having a few Lean practices in Scrum makes it no more Lean than doing a daily standup in a waterfall approach would make it Scrum.

To accomplish the intentions of the article, I will go through the 2020 Scrum Guide and take excerpts and elaborate on them as they relate to Lean-Thinking.

The End Up Front (Feb 14)

The end result of this will be creating a Scrum Guide based on Lean theory, principles and practices. Instead of presenting the roles, events, artifacts and rules as immutable, the intent of each of these will be presented with what the Scrum Guide presents as an example of these objectives. It will also include a few critical concepts missing from the Scrum guide based on the theories of Flow, Lean and ToC.

You can get the essence of this by looking at Net Objectives' old Introduction To Team-Agility and Scrum as Example

A Quick Overview of Lean (Feb 14)

The essence of Lean is:

• How to learn to continuously improve the organization’s ability to provide value to their customers at a lower cost than before
• It’s based on systems thinking, taking a holistic view of the group of people attempting to use it. This includes both themselves and anyone they interact with
• It shifts our focus from the productivity of the people (or machines) doing the work to the value stream. It provides theories, principles and practices to shorten the time from concept to consumption. The focus is on removing delays which cause waste. While in manufacturing one can strive to eliminate waste directly, in knowledge work the focus must be on delays which cause waste. This is proverbially known as “just-in-time.”
• It focuses on quality of what is being produced because of the recognition that the system causes most of the problems.

The lack of systems thinking in most Agile approaches has most people not recognize the importance of “stopping the line” when an error occurs. Most Scrum teams I see are like people deciding where to put the buckets under a leaking roof instead of going up and patching it. When it’s pointed out that Scrum doesn’t prevent the “patching” I point out that it also doesn’t provide you the insights to see the absurdity of the situation.

Frameworks should be there to help you build better products. They should not be so incomplete that you spend much of your time having to figure out what the qualities of a good workflow is. The belief that a reasonably complete of principles to guide you practices would be restrictive is only held by those who haven’t figured out how to provide the principles in an non-restrictive manner.

Systems Thinking

Systems thinking is considering a system to be an interrelated and interdependent set of parts which is defined by its boundaries and is more than the sum of its parts (subsystems). Changing one part of the system affects other parts and the whole system, with predictable patterns of behavior. Positive growth and adaptation of a system depend upon how well the system is adjusted with its environment, and systems often exist to accomplish a common purpose (a work function) that also aids in the maintenance of the system or the operations may result in system failure. The goal of systems thinking is systematically discovering a system’s dynamics, constraints, conditions and elucidating principles (purpose, measure, methods, tools, etc.) that can be discerned and applied to systems at every level of nesting, and in every field for achieving an optimized end state through various means.

See Systems Thinking and how it can be applied to frameworks and methods. 

For a great overview of systems thinking watch If Russ Ackoff had given a TED Talk

NOTE: I will include information about how to move to systems thinking but after writing this feel this is a bit premature in the article. So I'll be inserting things here soon.

A Move to Systems Thinking

Any approach that incorporates systems thinking would attend to how it relates to the people using it. For example, it would ask the following questions:

• Are people going to resist anything about this?
• Does this require people to change from something they are attached to and which is ok if they hold on to?
• How does any practice affect other practices?
• Is there a transition approach from where they are to where they should be heading?
• What pace should our adoption be?
• Are the roles specified appropriate fort he organization and the work it is attempting to do?
• …

Scrum pretty much ignores these questions with its opening definition of its required roles.

Scrum also puts an emphasis on being “lightweight.” This is not a Lean concept. Lean focuses on being effective – simplicity is a result. Lean focuses on reducing delays. Lightweight may be requirement because heavyweight processes will cause waste and excess activity. But the focus is on doing the work more effectively. This is somewhat like focusing on lowering cost often has adverse side effects. Focusing on being lightweight can do the same.

Attending to People

A common phrase from Scrum proponents when people aren’t successful with it is “well they weren’t doing Scrum.” One of Scrum co-founders, Ken Schwaber, has even coined a term for this “Scrumbut.” Scrum org defines “ScrumBut” as “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

There are two problems with this line of thinking. The first is, Scrum doesn’t consider why people are prone to Scrumbut. The question “why are people doing it instead of finding a solution that fits their needs?” It may be that the best solution for them is not within the scope of Scrum. The other is that Lean does not have a set of practices that you must follow. If people are having a dysfunction, Lean doesn’t just provide a limited set of practices, but rather provides a broad set of principles and insights to help you solve them.

Ken even has a CD called “ScrumButs: The Dangers of Customizing Scrum.” However, if Scrum incorporated Lean-thinking you would be able to customize it to make it more effective. At Disciplined Agile we call this choosing your WoW (Way of Working). A more generic approach can be seen at How to Improve or Change Your Scrum Practices.

Three posts to learn more:

• Why I hate the term ScrumBut
• How Scrum creates ScrumBut and what to do about it
• Rethinking Scrumbut and ScrumAnd