Learn from the Trenches – Lean, Scrum, XP and Kanban in a nutshell

Software development with Lean Scrum XP Kanban

I have recently the book “Learn from the Trenches” from Henrik Kniberg ( @henrikkniberg ). This is an outstanding “how to” build complex and robust software, delivered on time and with quality.

Here is an extract (pages 106-113) I would like to share because it gives a brilliant overview about Lean, Scrum, XP (Extreme Programming) and Kanban.

If this content has to be removed for copyrighting reason, please send a message and I will do it immediately.

Lean in a Nutshell

Lean is the western term for what the Japanese call “TPS” (Toyota Production System) -an approach to manufacturing that has helped make Toyota the most successful car manufacturer in the world. The underlying principles behind TPS, the Toyota Way, have turned out to be applicable almost anywhere, including software development.

Agile and Lean can be seen as cousins with comon values but different origins. Lean arose from manufacturing. Agile arose from software development. Both sets of principles fit well together and are very broadly applicable. More and more software development organizations are discovering how to combine these principles to cover the whole chain from product concept to delivery.

Mary and Top Poppendieck have heen instrumental in mapping Lean principles to software development. Here is their summary: www.poppendieck.com

Optimize the Whole

Optimizing a part of a system will always, over time, suboptimize the overall system.

  • Focus on the entire value stream: From concept to cash. From customer request to deployed software.
  • Deliver a complete product: Customers don’t want software; they want their problems solved. Complete solutions are built by complete teams.
  • Think long term: Beware of governance and incentive systems that drive short-term thinking and optimize local performance.

Eliminate Waste

Waste is anything that does not add customer value. The three biggest wastes in software development are the following:

  • Building the wrong thing: “There is nothing so useless as doing efficiently that which should not be done at all.”
  • Failure to learn: Many of our policies – for example, governance by variance from plan, frequent handovers, and separating decision making from work – interfere with the learning that is the essence of development.
  • Thrashing: Practices that interfere with the smooth flow of value – task switching, long lists of requests, big piles of partly done work –deliver half the value for twice the effort.

Build Quality In

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

  • Final verification should not find defects: Every software development process ever invented had as its primary purpose finding and fixing defects as early in the development process as possible.
  • Mistake-proof your process with test-first development: Tests – including unit tests, end-to-end tests, and integration tests – must be available to establish confidence in the correctness of the system at any time during development, at every level of the system.
  • Break dependencies: System architecture should support the addition of any feature at any time.

Learn Constantly

Planning is useful. Learning is essential.

  • 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.
  • Maintain options: Think of code as an experiment -make it change-tolerant.
  • Last responsible moment: Learn as much as possible before making irreversible decisions. Don’t make decisions that will be expensive to change before their time -and don’t make them after their time!

Deliver Fast

Start with a deep understanding of all stakeholders and what they will value. Create a steady, even flow of work, pulled from this deep understanding of value.

  • Rapid delivery, high quality, and low cost are fully compatible: Companies that compete on the basis of speed have a big cost advantage, deliver superior quality, and are more attuned to their customers’ needs.
  • Queuing theory applies to development, not just servers: Focusing on use creates traffic jams that reduce use. Drive down cycle time with small batches and fewer things in process. Aggressively limit the size of lists and queues.
  • Managing workflow is a lot easier than managing schedules: The best way to establish reliable, predictable deliveries is to establish reliable, repeatable workflows with iterations or a Kanban system.

Engage Everyone

The time and energy of bright, creative people are the scarce resources in today’s economy and the basis of competitive advantage. People who are paid farily and adequately are motivated by autonomy, mastery and purpose.

  • Autonomy: The most effective work groups are semi-autonomous teams with an internal leader who has end-to-end responsibility for complete, meaningful tasks.
  • Mastery: Respect for people means providing the challenge, feedback, and environment that enables everyone to become excellent.
  • Purpose: The work to value. Only by believing in the purpose of their work will people become engaged in achieving that purpose.

Keep Getting Better

Results are not the point -the point is to develop the people and the systems capable of delivering results.

  • Failure is a learning opportunity: The most reliable performance comes when even small failures are deeply investigated and corrected -when noise is not tolerated.
  • Standards exist to be challenged and improved: Embody the current, best-known practice in standards that everyone follows, while encouraging everyone to challenge and change the standards.
  • Use the scientific method: Teach teams to establish hypotheses, conduct many rapid experiments, create concise documentation, and implement the best alternative.

Scrum in a Nutshell

Scrum is a software development approach that Jeff Sutherland and Ken Schwaber developed during the early 1990s. It is rooted in empirical process control and complex adaptive systems theory and was inspired by a Harvard Business Review article called “New New Product Development Game” from 1986 (you can find it on Internet). The core concepts of Scrum are as follows.

Ordered Product Backlog

Split your work into a list of small, concrete deliverables -the product backlog. The product owner defines a product vision and orders the backlog by business value and other factors such as risk and dependencies.

Cross-functional Teams

Split your organization into small, cross-functional, self-organizing teams. Each team has a Product Owner, who provides the vision and overall business priorities, and a Scrum Master, who focuses on improving the team and removing impediments.


Split time into short fixed-length iterations, or sprints (typically two or three weeks long). The team chooses how many product backlog items to pull into each iteration. Each iteration ends with a demonstration of a tested, potentially shippable release.

Continuously Adjusted Release Plan

The product owner optimizes the release plan and updates priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.

Continuously Adjusted Process

The teams optimize the development process by having a retrospective after each iteration. So, with Scrum:
Instead of a large group spending a long time building a big thing
… we have a small team spending a short time building a small thing.
But integrating regularly to see the whole

Scrum does not mandate any specific engineering practices -those are left up to the team. In practice, however, succeeding with Scrum without including the core engineering practices of XP is very hard.

XP in a Nutshell

Extremme Programming (XP) is a software development approach that Kent Beck created in the mid-1990s. It is based on the values of simplicity, communication, feedback, courage, and respect. XP evolved in parallel with Scrum and, in fact, includes most of the same elements. For example, on-site customer in XP corresponds roughly to product owner in Scrum.

Scrum with XP practices
Source: https://www.oreilly.com/library/view/lean-from-the/9781941222935/images/Agile-lean-nutshell/Scrum-XP-compressed.png

In that sense, Scrum can be seen as a “wrapper” around XP, focusing on structural issues and external communication, while XP duplicates most of that and adds some team-internal engineering practices. These include the following:

  • Continuous integration: Have a system that automatically builds, integrates and tests the code as the team develops it. This gives the team early feedback on the quality of their work.
  • Pair programming: Program together in pairs on one workstation to maximize learning, maximize design quality, and minimize defects.
  • Test-driven development: Use test code to drive the design of the system. Write an automated test, then write just enough code to make that one test pass, and then refactor the code primarily to improve readability and remove duplication. Rinse and repeat.
  • Collective code ownership: Anybody on the team is allowed to (and, in fact, encouraged to) edit any part of the code base. This creates a sense of team ownership and ensures a coherent, easy-to-understand design across the whole system.
  • Incremental design improvement: Instaed of creating a complete design from the beginning, start with the simplest possible design and then, continuously improve it using techniques such as refactoring.

Many of these practices build upon each other. For example, incremental design improvement is difficult, scary, and risky if the system isn’t well covered by automated tests, and good test coverage is best achieved by doing test-driven development and pair programming. However, that gets painful if all the tests have to be triggered manually and run locally on each developer’s workstation, so we need a continuous integration system to do that automatically in the background. And so on.

Kanban in a Nutshell

Kanban is a Lean approach to Agile software development.

Actually, Kanban means many things. Literally, Kanban is a Japanese word that means “visual card” (or sign). At Toyota, Kanban is the term used for the visual and physical signaling system that ties together the whole Lean production system.

In 2004, however, David Anderson pioneered a more direct implementation of Lean thinking and the Theory of Constraints to software development. Under the guidance of experts such as Don Reinertsen, this evolved into what David called a “Kanban system for software development” and which most people now simply refer to as “Kanban”.

So although Kanban as applied to softwre development is quite new, Kanban as used in Lean production is more than a half-century old.

The rules of Kanban are simple. But, like chess, just because the rules are simple doesn’t mean the game is easy.

  • Visualize the workflow:
    • Split the work into pieces, write each item on a card, and put the card on the wall.
    • Use named columns to illustrate where each item is in the workflow.
  • Limit work in progress (WIP): Assign explicit limits to how many items may be in progress at each workflow state.
  • Measure and manage cycle time: Average the time to complete one item, sometimes called lead time (a better term might be flowthrough time). Optimize the process to make the cycle time as small and predictable as possible.
Kanban visual flow
Source: https://olemortenamundsen.files.wordpress.com/2010/03/kanban_illustration.png

This is basically a direct implementation of a Lean pull-scheduling system.

While Scrum focuses on structure and communication and XP adds engineering practices, Kanban focuses on visualizing flow and managing bottlenecks.

Leave a Reply

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