(R)Evolutionary Agility: Scrum is Lean

I believe that Scrum is the most Lean among all Agile methods.

And not only because the word "scrum" was first used in 1986 by two professors at Hitotsubashi Univeristy in Japan, Hirotaka Takehuchi and Ikujiro Nonaka, in their famous HBR-published article "The new new product development game".

In 2003 Mary and Tom Poppendieck coined the term Lean Software Development by publishing a book with the same name and proposing a translation of Lean thinking and practices to the software development domain. Lean Sofware development is based on 7 principles, which may be implemented by means of a number of tools:

Eliminate waste
Amplify learning
Decide as late as possible
Deliver as fast as possible
Empower the team
Build integrity in
See the whole

If you want to know more, Mary and Tom published two more books:

Now, even though Scrum and Lean Sofware development might seem to have formally nothing in common (different principles and different practices), I will try to explain why and how I think the seven Lean SW Development principles are somehow mapped (or at least found) in Scrum.

1. Eliminate waste

The book reports seven wastes in SW development: partially done work, extra features, extra processes, task switching, waiting, motion, defects.

I think that the Scrum framework as such contributes to eliminate those sources of waste:

- the iteration-based approach, through the use of the Sprint Backlog, and the focus on doing whatever it takes to get things done and transform the items in the Sprint Backlog into a Potentially Shippable Product Increment, contributes the eliminate partially done work

- the Product Backlog handling, by building first the features which are more valuable for the customer and not spend too much time on the ones that are coming later, contributes to minimize partially done work and not needed features

- self-organized teams, who have the best knowledge, who are empowered to decide how to do the work and who continuously adjust their process through Sprint retrospectives, contributes to remove extra processes

- teams focusing on the Sprint goal minimize task switching

- cross-functional development teams working together side by side and daily with the Product Owner can remove waiting and handover of work items

- high skilled development teams, feeling responsibility for product quality, minimize defects

2. Amplify learning

Scrum is all about seeing SW development as a learning process. The Sprint will help create knowledge both on the product and on the process: the Sprint Review and the Sprint Retrospective are the main points in time where the knowledge on the product and the process are built respectively via feedback loops. The Daily Scrum also creates knowledge about how far the team is from the Sprint goal

Cross-functional teams learn continuously from each other skills and share knowledge inside the team and between different teams.

3. Decide as late as possible

A Product Backlog which is more fine grained on the top and more coarse on the bottom and “just enough just in time” planning via a Sprint based approach, allow a Scrum Team to reduce complexity and defer decisions which are not necessary at a certain point in time.

They can keep instead options open up to the last responsible moment: they can use time to collect more information and learn more about the product and the context in order to take better decision later, based on facts. They will of course learn fast by means of quick feedback loops provided by the Sprints.

This allows a Scrum team to be more flexible to react to the changes that will surely happen in the market and in the technology: they can truly embrace change inside their process of developing SW.

4. Deliver as fast as possible

Short delivery cycles represented by Sprints allow deliver quickly to maximize return on investment, get feedback from real customers and users and reduce risk that you won’t deliver a product that meets customers’ needs, due to misunderstanding or any changes in markets and technology.

A team focusing only on delivering the Sprint backlog will produce potentially shippable SW increments faster.

5. Empower the team

Scrum is all about empowering self-organized teams to find the best way to accomplish work. Self-organized teams can leverage all members’ talents and intelligence in the best possible way to achieve their goal as fast as possible.

Real empowerment is achieved by having the Product Owner to decide the “What” and the “Why” and explicit it by means of Product Backlog items in the form of User Stories: the development team will then decide the “How” and find the fastest possible way to get a User Story done.

6. Build integrity in

In a waterfall approach, piling up code without testing often result in a very expensive re-factoring effort, due to bugs, but especially to requirement change or misinterpretation.

Quality in a complex environment like SW development can be built only via iterative and fast feedback loops. A Sprint provides the main feedback loop mechanism in Scrum. Inside the Sprint there might be other even quicker feedback loops:

- the Product Owner (customer representative) works together with development: they are part of the same Scrum teams and work daily together: they collaborate on the Product Backlog and the real Product and this ensures a continuous feedback loop on requirements and system behavior

- Scrum teams adopting XP practices perform continuous refactoring, continuous testing, and continuous integration, which are Agile ways to build quality in.

7. See the whole

End-to-end Product Backlog items (slicing the product end-to-end vertically and explaining why) and cross-functional teams allow looking at the whole system: they can adapt the work items and the process to maximize the value delivered and achieve the Product Vision in the fastest possible way.

An empowered and self-organized team, working closely and daily with a customer representative (the Product Owner), have the possibility to look at the whole development process, find the weakest link or the bottleneck at hand and do whatever they see as necessary to fix it.

They have enough visibility of the whole to avoid sub-optimizations which typically, in traditional environments, try to optimize some small part of the system, which may not help the whole system.

If you want to implement a Lean thinking in your organization, try to practice effective Scrum first and you will get an extraordinary teacher. Scrum is Agile and Lean.

What do you think?