[Back to basics]: Scrum origin and Lean Thinking

Scrum is a Lean approach to Software development.

The term itself (“Scrum”) was introduced by Takeuchi and Nonaka (1986). The study was published in Harvard Business Review in 1986. They explain that projects using small, cross-functional teams historically produce the best results. They relate these high performance teams to “Scrum” formations in Rugby.

Scrum for software development was introduced in 1993 by Jeff Sutherland at Easel Corporation using the study by Takeuchi and Nonaka (1986) as a basis for by adopting their analogy as the name of the process as a whole for software development. The other name linked to Scrum is of course Ken Schwaber who formalized the process for the worldwide software industry in the first published paper on Scrum at OOPSLA (Schwaber, 1997).

Scrum is a simple “inspect and adapt” framework that has three roles, three ceremonies, and three artefacts designed to deliver working software in Sprints, usually 30-day iterations (Scotland, 2005).

  • 3 Roles
    Product Owner, Scrum Master, Development Team
  • 3 Ceremonies
    Sprint Planning, Sprint Review, and Daily Scrum Meeting
  • 3 Artefacts
    Product Backlog, Sprint Backlog, and Burndown Charts

Lean Thinking

Lean Concepts

The roots of Scrum lie deep in the concept of Lean as it was first laid out for the Toyota Production System (TPS). Scrum’s a framework that makes it easier for development organisations to follow the concepts of Lean.

Three Key concepts make up Toyota Production System from a high level view.  The Japanese terms for these are:

  • Muri (Load) – The concept of not overloading processes
  • Muda (Flow) -The concept of keeping the flow smooth and even
  • Mura (Waste) – The concept of removing the Non-Value adding activities

The Lean principles are effectively these three concepts broken down to 7 essential principles that enable the organisations to harvest the fruits of keeping things simple, concentrating on delivering iterative value in form of robust, vast quality shippable software:

  • Eliminate Waste
  • Build Quality In
  • Create Knowledge
  • Defer commitment
  • Respect People
  • Optimize the Whole
  • Deliver as fast as possible

Let’s explore a little bit more what these principles mean for Software Development. Here’s how Tom and Marry Poppendieck (2003) put it:

Eliminate Waste

The three biggest wastes in SW dev. are:

  • Extra Features: We need a process which allows us to develop just those 20% of the features that give 80% of the value.
  • Churn: If you have requirements churn, you are specifying too early. If you have test and fix cycles, you are testing too late.
  • Crossing Boundaries: Organizational boundaries typically increase cost by over 25%; they interfere with communication.

Build Quality In.

If you routinely find defects during verification, your development process is defective.

  • Mistake-Proof Code with Test-Driven Development: Write executable specifications instead of requirements.
  • Stop Building Legacy Code: Legacy code is code that lacks automated unit and acceptance tests.
  • The Big Bang is Obsolete: Use continuous integration and nested synchronization

Create Knowledge.

Planning is useful. Learning is essential.

  • Use the Scientific Method: Teach teams to establish hypotheses, conduct many rapid experiments, create concise documentation, and implement the best alternative.
  • Standards Exist to be Challenged and Improved: Embody the current best known practice in standards that everyone follows. Encourage everyone to challenge the standards.
  • Predictable Performance is Driven by Feedback: A predictable organization does not guess about the future and call it a plan; it develops the capacity to rapidly respond to the future as it unfolds.

Defer Commitment.

Abolish the idea that it is a good idea to start development with a complete specification.

  • Break Dependencies: System architecture should support the addition of any feature at any time
  • Maintain Options: Think of code as an experiment – make it change-tolerant.
  • Schedule Irreversible Decisions at the Last Responsible Moment: Learn as much as possible before making irreversible decision

Deliver Fast.

Lists and queues are buffers between organizations that simply slow things down.

  • Rapid Delivery, High Quality, and Low Cost are Fully Compatible: Companies that compete on the basis of speed have a big cost advantage, are more attuned to their customers’ needs, and deliver superior quality
  • Queuing Theory Applies to Development, not Just Servers: Focusing on utilization creates a traffic jam that actually reduces utilization. Drive down cycle time with small batches and fewer things-in-process.
  • Limit Work to Capacity: Establish a reliable, repeatable velocity with iterative development. Aggressively limit the size of lists and queues to your capacity to deliver.

Respect People.

Engaged, thinking people provide the most sustainable competitive advantage.

  • Teams Thrive on Pride, Commitment, Trust, and Applause: What makes a team? Members mutually committed to achieve a common goal.
  • Provide Effective Leadership: Effective teams have effective leaders who bring out the best in the team.
  • Respect Partners: Allegiance to the joint venture must never create a conflict of interest.

Optimize the Whole.

Brilliant products emerge from a unique combination of opportunity and technology.

  • Focus on the Entire Value Stream: from concept to cash, from customer request to deployed software.
  • Deliver a Complete Product: Develop a complete product, not just software. Complete products are built by complete teams.
  • Measure Up:Measure process capability with cycle time.Measure team performance with delivered business value.Measure customer satisfaction with a net promoter score.

The Characteristics of Scrum

Scrum is a simple framework used to organize teams and get work done more productively with higher quality.

It allows teams to choose the amount of work to be done and decide how best to do it, thereby providing a more enjoyable and productive working environment. Scrum focuses on prioritizing work based on business value, improving the usefulness of what is delivered, and increasing revenue, particularly early revenue.

Designed to adapt to changing requirements during the development process at short, regular intervals, Scrum allows teams to prioritize customer requirements and adapt the work product in real time to customer needs. By doing this, Scrum provides what the customer wants at the time of delivery (improving customer satisfaction) while eliminating waste (work that is not highly valued by the customer).

Scrum characteristics

  • Teams can choose the amount of work to do in one iteration and how to best fulfill the agreed goal
  • Focus on prioritizing the work based on Business Value, improving the customer satisfaction by releasing what is needed and at the right time
  • Allow to adapt to changing requirements at regular short intervals without big impact on the product development
  • Allow to deliver working software at regular intervals

Next Back to Basics Post

In the next post I am looking to explain the basic ceremonies of Scrum, expect within 7 to 10 days.


-          Poppendieck T. and Poppendieck M (2003), “Lean Software Development: An Agile Toolkit” Addison-Wesley Professional

-          Schwaber K (1997), “Scrum Development Process, in OOPSLA Business Object Design and Implementation Workshop”, Springer, London

-          Takeuchi H. and Nonaka I. (1986), “The New Product Development Game”, Harvard Business Review (Jan-Feb)

This entry was posted in Agile, Lean, SCRUM, build quality in, create knowledge, defer commitment, deliver fast, eliminate waste, optimize the whole, respect people, value stream and tagged , , , . Bookmark the permalink.

7 Responses to [Back to basics]: Scrum origin and Lean Thinking

  1. Pingback: Narek Alaverdyan

  2. Pingback: Narek Alaverdyan

  3. Pingback: Chris Rice

  4. Pingback: Antonio Santiago

  5. Pingback: Lenne Hendrickx

  6. Pingback: Aiga Matsuo

  7. Pingback: Andy Thomas

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>