In the 2020 version of the Scrum Guide a new thinking model was added to the principles on which Scrum is founded - Lean Thinking. However, not enough justice is done in explaining WHY Lean Thinking was introduced or added to Scrum Guide. In fact, the change to founding principles doesn’t even find a place in revision history. Also, while introducing Lean Thinking, a very generic statement is used which seems more like lip service for adding the term to Scrum Guide.
Here’s what Scrum Guide states -
“Scrum is founded on empiricism and lean thinking………Lean thinking reduces waste and focuses on the essentials.”
And in the remaining Scrum Guide there is no other reference to Lean Thinking or no attempt has been made to make a connection between Scrum and Lean Thinking. Thus, creating more gaps for either misinterpretation or completely omitting any connection to Lean Thinking. In the past four years, I haven’t come across any Scrum Masters who could well establish the connection. I am strictly speaking based on the Scrum Master interviews I have conducted and the Scrum Masters I have worked with. There might be others who might be able to do that but I haven’t had the opportunity to work with them. And this stands true for the other accountabilities on the Scrum Team as well.
This is my effort to get the people, who want to explore the connection between the two, to a starting point. I hope this will help.
Lean Thinking
Lean Thinking goes much further than just reducing waste and focusing on the essentials. However, often it is reduced to this very myopic view by many people who do not truly understand the concepts of Lean. And exploring Lean Thinking through a blog article might not be justifiable. I would recommend the Lean Primer by Craig Larmann and Bas Vodde for anyone who wants to explore this topic in detail. What I learned from this book is
- The purpose (goal) of Lean is to get to the shortest sustainable lead time with quality and value.
- To achieve this purpose, Lean folks focus on two key pillars
- Respect for People
- Continuous Improvement
- The pillars are then supported by
- 14 Lean Principles
- Quality Product Development
- To ensure all this succeeds, the foundation is built by Leaders who focus on being enablers, teachers.
Lean Software Development
As Scrum is typically utilized by Software Engineering teams, I will shift the focus to Lean Software Development. Yet again, I will recommend a book with the same title by Mary and Tom Poppendieck to get a good hold of the subject.
Lean Software Development focuses on applying a few principles from Lean Thinking to Software Development in order to make software product delivery more efficient. There are 7 principles which the book focuses on and I remember the principles through an acronym that I created while teaching the principles to Scrum teams. The acronym is DEBASED.
DEBASED
D - Deliver as early as possible
Lean Thinking clearly states that we need to respect the people. One of the criteria of respecting people is about not keeping your customers waiting. And Customer, is anyone who consumes your work. With that definition in mind, a person who is skilled in Testing is a customer for the person who is skilled at Coding. In my experience, I have observed that even though teams are using Scrum, their approach is still waterfallish. In a Sprint, the first few days go towards developing the code, while the testers are waiting (waiting is waste, let me call out). The work is then passed to testers in the lagging end of sprint, expecting them to test everything out within whatever limited time they have left on the Sprint. Clearly, no respect for people.
This also leads to another related problem. If testers identify bugs then the work is not releasable unless the bugs are fixed. This means the Value delivery to the end customer is also delayed. If we need to Respect the People, then the first step is to not keep them waiting. Thus, implying that we need to Deliver as early as possible.
Scrum’s approach to Deliver as early as possible
At the end of the Sprint there has to be at least one DONE increment which can be released to the end user if the Product Owner decides to do so. It doesn’t matter how small or large the impact of value Increment will create.
From the Scrum Guide:
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
E - Eliminate Waste
In order to Deliver as early as possible, the Scrum Team will have to remove any kind of wastes in their way of working; their processes, their tools and other aspects of their product development.
As Mary and Tom Poppendieck highlight, the first step towards removal of waste is, identification of waste. For ex: waiting is waste, if team members are waiting on each other to complete a work item then it is leading to waste. A Scrum Team will have to find out such wastes in their way of working and address them.
Defects are a waste. If a Scrum Team with every release adds more bugs than fixing them, clearly is going to do a lot of rework which is a waste.
Scrum’s approach to Eliminating Waste
Scrum establishes clear Accountabilities, Artifacts and Events. Using the accountabilities, artifacts and events for the right purpose leads to reduction of waste. For ex: A Scrum Team that creates Transparency through usage of automated tools, can avoid unnecessary status update meetings to a large extent. Similarly, if the right stakeholders are invited to the Sprint Review, then any additional update meetings can be avoided.
B - Build Integrity In
Another key requirement to Deliver as early as possible is to ensure that there is enough quality built into the product from the very beginning. And quality should not stop only at testing.
There are many factors that go beyond testing and are required to create a valuable product. Lean Software Development goes to describe all these factors together as Product Integrity; which is then classified as Conceptual Integrity and Perceived Integrity.
Conceptual Integrity is about ensuring core functions of the product work cohesively. Perceived Integrity is about ensuring that customers have a wholesome experience while using the product. There has to be a balance of features, usability, reliability of the product.
Scrum’s approach to Building Integrity In
Besides having the Product Backlog and Sprint Backlog to manage the work, Scrum has a very important aspect that ensures a clear focus on Building Integrity In. This is the Definition of Done (DoD). A Scrum Team is expected to adhere to a Definition of Done that will make the Increment releasable. The DoD encompasses various attributes ranging from the testing to be performed to compliance and documentation which enable both perceived as well as conceptual integrity.
A - Amplify Learning
In order to build valuable products it is imperative that the Scrum Teams are open to learn about the needs of their customers and at the same time they are also open to new ideas to build the product in a better way. Learning about the product needs, customer needs, the evolving domain/market along with the processes, tools, skills, knowledge and expertise needed to build a product is important.
Scrum’s approach to Amplify Learning
Scrum has two dedicated events, every sprint, to improve the learning process. Sprint Review, enables the Scrum Team to collaborate with their key stakeholders to understand the changes in the market domain or customer needs or stakeholder expectations and then improve the Product Backlog as needed.
Sprint Retrospective is the other event that Scrum Team uses to focus on their internal ways of working as a collaborative unit to create great products.
S - See the WHOLE
This principle focuses on Systems Thinking i.e. taking an holistic approach to Product Development. Product Development is not only about writing and testing code. It is impacted by many factors that might be beyond the realm of the Scrum Team.
In Systems Thinking, there are three patterns which are considered
- Limits to growth
- Shifting the burden
- Suboptimization
Often, Scrum Teams may be impacted by all of it. For example, when a team focuses a lot on test automation while they don’t even have a refined Product Backlog is a clear case of suboptimization. On the other hand, ecosystem related aspects such as contracts or inter-team dependencies might lead to “limits to growth” pattern.
Scrum’s approach to See the WHOLE
Scrum enables the big picture perspective through the usage of transparent Artifacts and making the information readily available that might be needed to make decisions. Similarly, Scrum Events can provide opportunities to cross-team and stakeholder collaboration, thus overcoming any challenges.
E - Empower The Team
When barriers and boundaries are put on people of what they should do, how they should, when they should; it makes them zombies. They are often disengaged from the work they are doing and rarely care about it.
While we are dealing with complex problems, aka software delivery, we need people to be creative, innovative and fully engaged in their work. For people to really engage in their work they should be having enough authority and freedom to make decisions within their context. This authority/freedom of making decisions is similar to the intrinsic motivation factor Autonomy, highlighted by Daniel Pink in his book Drive.
Scrum’s approach to Empower The Team
Scrum clearly calls out the need of self-managing teams in order to create value.
From the Scrum Guide:
They are also self-managing, meaning they internally decide who does what, when, and how.
Scrum Teams are empowered to make decisions within their context. They are not dependent on people outside the team to make their decisions. For ex: A Product Owner has full authority on the ordering of the requirements as well as whether to make or not to make a release.
Scrum also enables empowerment and autonomy within the teams by providing them clear purpose through the use of Product Goals or Sprint Goals.
D - Decide as late as possible.
At the outset it might seem contradictory to the principle “Deliver as early as possible” but when Lean Thinking states Decide as late as possible, it is not promoting procrastination but it is about expecting changes even late in development. So, instead of deciding on a very specific solution early on, provisions are made to accommodate changes as they happen. This eliminates waste that might be created from deciding on a solution that no longer is helpful because of the changes and thus enables “Deliver as early as possible”.
Scrum’s approach to Decide as late as possible
A simple approach to how Scrum enables late decision is through the Inspect & Adapt opportunities built in the Scrum Events. A Scrum Team does just-in-time planning i.e. the Scrum Team plans only for the current sprint with the latest information that they have. The Scrum Team will not come up with a plan for the tenth Sprint in its first Sprint Planning.
Another way a Scrum Team practices the principle of Deciding as late as possible is through its engineering practices. A Scrum Team may explore multiple solutions (aka set-based design) or have concurrent development to evaluate which could be the best suited implementation of a problem.
Conclusion:
Lean Thinking in itself is a huge subject to explore. However, when it comes to software development some of the principles of Lean Thinking can be easily replicated. Scrum at its core enables the principles of Lean Software Development to create better value products.