Scrum: The Art of Doing Twice the Work in Half the Time

In Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland, a pioneer in software development, unveils the Scrum management system—a revolutionary approach designed to help individuals, teams, and organizations achieve extraordinary productivity and happiness. Drawing on his diverse background as a former U.S. Air Force fighter pilot, a professor of mathematics, and a seasoned technology executive, Sutherland demonstrates how this deceptively simple framework can double productivity, halve delivery time, and dramatically increase quality and morale. This book is not just for tech professionals; it’s a profound re-evaluation of how work is done, providing actionable insights that can transform virtually any endeavor, from building cars and managing government projects to revolutionizing education and alleviating poverty. Throughout this summary, we will break down every important idea, example, and insight from Sutherland’s book in clear, accessible language, ensuring comprehensive coverage of this powerful methodology.

Chapter One: The Way the World Works Is Broken

This chapter dramatically introduces the fundamental problem with traditional project management and sets the stage for Scrum as the solution. Sutherland illustrates the inefficiency and failure inherent in conventional approaches, particularly the Waterfall method.

The FBI’s Sentinel Project: A Case Study in Failure

Sutherland opens with the compelling story of the FBI’s decade-long, multi-million-dollar struggle to modernize its computer system. Jeff Johnson, Assistant Director of the IT Engineering Division at the FBI, faced a crisis in March 2010 when the massive Virtual Case File (VCF) system, which cost $170 million, was killed after three years of development without producing a single usable line of code. This failure highlighted the Bureau’s inability to “connect the dots” before 9/11 due to antiquated paper-based systems. A subsequent project, Sentinel, contracted to Lockheed Martin, also spiraled out of control, consuming $405 million and running a year late with only half the project completed. An independent analysis projected another six to eight years and an additional $350 million to finish.

The Problem with Waterfall Planning

The core issue, Sutherland explains, lies in the pervasive Waterfall method, characterized by rigid, sequential planning laid out in intricate Gantt charts. These charts, invented by Henry Gantt around 1910, create a mirage of control and predictability. Managers spend months on detailed plans, believing they can foresee every step, but these plans are almost always wrong once they encounter reality. Sutherland argues that companies often pay people to maintain this illusion, treating reports as more important than actual progress. The FBI’s experience with Sentinel, where new software defects were discovered faster than old ones were fixed, exemplifies this systemic failure.

Introducing Scrum: A New Way of Thinking

Faced with the Sentinel debacle, Johnson and his boss, CIO Chad Fulgham, made the bold decision to kill the existing program and bring development in-house. They committed to delivering the most challenging half of the project in less than a fifth of the time and a tenth of the budget using a new approach: Scrum. Sutherland describes Scrum as a radical departure from prescriptive, top-down project management. Instead, it is an evolutionary, adaptive, and self-correcting system that embraces uncertainty and creativity.

Key characteristics of Scrum include:

• Small, empowered, dedicated teams.
• One-week to one-month “Sprints” to gain momentum and ensure accountability.
• Brief daily stand-ups to track progress and identify challenges.
• Continuous improvement and the concept of minimum viable products (MVPs) for immediate consumer feedback.

Sutherland asserts that Scrum works because it observes how people actually work, focusing on introspection, iteration, and adaptation. It has become ubiquitous in the tech industry, used by giants like Google, Amazon, and Salesforce.com, and is now poised to revolutionize other sectors.

Eliminating Impediments and Driving Velocity

For the FBI’s Sentinel project, the initial steps included unraveling complex contracts with Lockheed Martin and cutting staff from hundreds to under fifty, with a core team of only twelve. They printed out 1,100 pages of requirements documentation—a common symbol of wasted effort—and then prioritized each requirement by value, aiming for the 20% of features that deliver 80% of the value. Jeff Johnson’s primary role was “impediment removal”, drawing inspiration from Taiichi Ohno’s Toyota Production System and the concept of “flow.”

The Sentinel team adopted two-week Sprints, committing to delivering a finished, demonstrable increment of product at the end of each. This allowed for near real-time feedback from stakeholders, including the Director and Deputy Director of the FBI and the Office of the Inspector General. This continuous “Inspect and Adapt” cycle enabled the team to measure their velocity (how fast they could complete work items) and identify what was slowing them down. Over time, the Sentinel team increased their productivity by a factor of three.

The Triumph of Scrum: Sentinel’s Success

Despite initial skepticism from the Inspector General and others, the Sentinel project was deployed in July 2012, eighteen months after starting the in-house Scrum process. The system was turned on for everyone simultaneously, including features for paying informants, storing evidence, and managing case files. A notable success occurred in January 2013, when an FBI field office used Sentinel to coordinate a rapid response to a hacked business account, stopping a $1 million transfer to another country within hours—a feat impossible with the old paper-based system.

Sutherland concludes by highlighting that the success of Sentinel, and the failures of projects like Healthcare.gov (where the Scrum-built front end worked, but the Waterfall-built back end failed), underscore the necessity of adopting Scrum. Traditional management methods, rooted in “command and control” and “rigid predictability,” are obsolete in a world of increasing complexity. Scrum offers a pathway to higher quality work at a faster pace, improving lives and even changing the world.

Chapter Two: The Origins of Scrum

This chapter delves into Jeff Sutherland’s diverse background and the formative experiences that led him to develop Scrum, highlighting the fundamental principles he drew from military, academic, and business contexts.

Military Roots: The OODA Loop and Risk Control

Sutherland begins by recounting his experiences as a U.S. Air Force reconnaissance pilot in Vietnam in 1967. Flying dangerous missions where 50% of pilots were shot down, he learned to control risk through a four-step process: Observe, Orient, Decide, and Act (OODA). This real-time, adaptive decision-making cycle, crucial for survival in combat, would later become a foundational element of Scrum. The ability to quickly take in information, understand the context, make a decision, and execute it, was paramount.

Academic Pursuits: Systems Theory and Complex Adaptive Systems

After his military service, Sutherland pursued a Master’s in statistics at Stanford University and a PhD in biometrics at the University of Colorado Medical School. His doctoral research focused on understanding how cells become cancerous, leading him to explore systems theory and the behavior of complex adaptive systems. He realized that organizations, teams, and even individuals behave as complex adaptive systems, moving between stable states. This insight led him to question how simple rules could guide these systems toward more productive, happier, and healthier states.

Business Innovation: MidContinent Computer Services

In 1983, Sutherland entered the business world, joining MidContinent Computer Services, a company servicing 150 banks with their new Automatic Teller Machine (ATM) networks. He found the company’s software development division to be highly inefficient, using the Waterfall method, resulting in projects that were chronically late, over budget, and ineffective. To address this, Sutherland convinced the CEO, Ron Harris, to let him form a “company within a company”—a separate, autonomous organization focused solely on ATM networks.

In this new structure, bonuses were based on total company performance, not individual metrics. Sutherland introduced early versions of concepts that would become core to Scrum: the Product Owner, a Product Backlog, and weekly Sprints. Within six months, his division became the most profitable, transforming a cost-heavy operation into a revenue driver. This early success solidified his conviction that a new way of organizing work was essential.

Inspiration from Robotics: Rodney Brooks and Self-Organization

A pivotal moment came when Sutherland encountered the work of Rodney Brooks, an MIT professor of artificial intelligence, whose company was developing six-legged robots. Brooks explained that his robots didn’t rely on a single, centralized brain but rather on decentralized intelligence, where each leg had its own “brain” and simple rules. The robot learned to walk by interacting with its environment, constantly adapting rather than following pre-programmed instructions. This concept of self-organizing, self-optimizing systems based on constant feedback profoundly influenced Sutherland. He envisioned applying this idea to human teams, allowing them to self-organize and achieve higher performance.

The Birth of Scrum: “The New New Product Development Game”

In 1993, as VP of Object Technology at Easel, Sutherland was tasked with developing a new product line in six months—an impossible feat with the Waterfall method. He convinced the CEO to abandon Gantt charts and instead commit to delivering working software at the end of each month. His team extensively researched team organization and product development.

A breakthrough came with a 1986 Harvard Business Review paper by Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game.” This paper analyzed highly productive Japanese companies like Honda, Fuji-Xerox, and 3M, observing their use of overlapping development processes and cross-functional, autonomous teams driven by a transcendent purpose. The authors compared these teams to a rugby scrum, where the team moves as a unit, passing the ball among members. This paper directly inspired Sutherland to formally name his methodology “Scrum.”

At Easel, implementing Scrum led to the product being delivered on schedule, under budget, and with fewer bugs than any previous effort. In 1995, Sutherland and Ken Schwaber formally codified these practices in the paper “SCRUM Development Process.”

W. Edwards Deming and Continuous Improvement

Sutherland emphasizes the influence of W. Edwards Deming, an American statistician who profoundly impacted Japanese manufacturing after World War II. Deming’s concept of “statistical process control” and “continuous improvement” (kaizen) became central to the Toyota Production System and later to Scrum. Deming advocated for the PDCA cycle (Plan, Do, Check, Act):

• Plan: Define the task and objective (avoiding Muri – unreasonableness).
• Do: Execute the plan (avoiding Mura – inconsistency).
• Check: Review the results against the plan (avoiding Muda – waste through outcomes).
• Act: Adjust and improve based on what was learned.

Sutherland uses the paper airplane exercise in his training to demonstrate how quickly teams can improve productivity (2-3 times faster with double the quality) by repeatedly applying the PDCA cycle.

The “Change or Die” Imperative

Sutherland recounts his experience consulting at BellSouth, a company that perfected the Waterfall method, delivering precisely what customers asked for—but often a year and a half later, by which point the market had changed, and the customers no longer wanted it. Despite their technical excellence, BellSouth failed to adapt and eventually disappeared. This experience reinforced Sutherland’s belief in the “change or die” imperative: organizations that cling to old, rigid methodologies will be outmaneuvered by those embracing adaptive approaches like Scrum.

Shu Ha Ri: Mastery Through Practice

Sutherland connects Scrum’s philosophy to the Japanese martial art concept of Shu Ha Ri, representing different levels of mastery:

• Shu (obey): Learning and strictly following the rules and forms.
• Ha (break): Innovating within the established forms, understanding their underlying principles.
• Ri (transcend): Discarding the forms, embodying the essence, and achieving unhindered creativity.

Scrum, like Aikido, requires constant practice and attention to reach a state where work “flows” effortlessly. This foundational understanding of continuous practice and adaptation underpins Sutherland’s vision for Scrum.

Chapter Three: Teams

This chapter explores the profound impact of team dynamics on productivity and quality, arguing that focusing on team performance—rather than individual metrics—is the key to achieving extraordinary results.

The Power of Team Performance

Sutherland challenges the common business focus on individual performance, citing studies that show team performance has a vastly greater impact on project success. While the fastest individual programmers might be 10 times quicker than the slowest, the difference between the best and worst teams can be enormous—the worst teams might take 2,000 weeks to accomplish what the best teams do in one. This staggering disparity highlights why optimizing team dynamics is far more crucial than trying to staff solely with “geniuses.”

Characteristics of Great Teams

Drawing from the research of Hirotaka Takeuchi and Ikujiro Nonaka in “The New New Product Development Game,” Sutherland identifies three core characteristics of highly successful teams:

1. Transcendent Purpose: Great teams possess a sense of purpose beyond the ordinary, striving for something bigger than themselves. This collective goal elevates their self-perception and capabilities.
   • Example: West Point’s “Loose Deuce” Company: Sutherland recounts his experience as training officer for the L2 cadet company at West Point in 1963. Historically at the bottom of parade rankings, L2 achieved transcendence by embracing transparency and a relentless pursuit of improvement. By posting charts detailing every mistake, Sutherland’s method forced accountability, first among cadets, then among leaders. Within weeks, L2 became the number one company, later chosen to march at General Douglas MacArthur’s funeral. This demonstrated how a shared, higher purpose (“Duty, Honor, Country”) can unify and elevate a team.
2. Autonomy: Great teams are self-organizing and self-managing, empowered to make their own decisions about how they accomplish their work. Management sets strategic goals, but the team determines the execution.
   • Example: NPR’s Coverage of the Egyptian Revolution: Sutherland’s son, J. J. Sutherland, led NPR’s reporting team in Cairo during the 2011 Egyptian revolution. Cut off from direct oversight by Washington due to closed airports and communication shutdowns, the team was forced to self-organize to meet intense, rapidly changing deadlines. J.J. used a simplified Scrum approach, asking three questions daily: “What did you do yesterday?”, “What will you do today?”, and “What obstacles are getting in your way?”. His primary role as a de facto Scrum Master was impediment removal. This autonomy allowed the team to adapt quickly, producing award-winning coverage despite immense challenges, demonstrating that freedom can drive excellence.
3. Cross-Functional: Effective teams possess all the skills necessary to complete a project from start to finish, eliminating the need for handoffs between specialized departments.
   • Example: Salesforce.com: Nicola Dourambeis, in charge of Agile practices at Salesforce.com, views Scrum as their “secret sauce,” enabling them to release products three times a year, a rarity for major enterprise companies. She seeks diverse, unselfish, and autonomous teams that are also cross-functional. A key indicator of success is when a specialist identifies more with the product being built (e.g., “automation team”) than with their specific skill (e.g., “network engineering”).
   • Example: U.S. Special Operations Forces (SOF) in Iraq: Sutherland cites the “collaborative warfare” strategy led by General Stanley McChrystal during the Iraq war. Unlike traditional military structures that involved handoffs between intelligence and operations units, cross-functional interagency teams (CIA, FBI, Treasury, NSA, NGA) worked together in the same room. This eliminated “organizational blinks” where momentum slowed and targets escaped, demonstrating how breaking down silos enhances lethality and effectiveness. Though highly effective, these teams were disbanded post-crisis due to bureaucratic resistance from middle managers protective of their “fiefdoms” and information.

The Optimal Team Size: Why Small is Mighty

Sutherland emphasizes that team dynamics work best in small teams, ideally seven people, plus or minus two. He highlights Brooks’s Law from Fred Brooks’s The Mythical Man-Month, which states, “adding manpower to a late software project makes it later.” Studies by Lawrence Putnam confirm that projects with 20+ people require five times the effort of those with five or fewer.

The reasons for this include:

• Time to bring new people up to speed: New additions slow down existing members.
• Communication channels: The number of communication paths increases exponentially with team size (n(n-1)/2). With 5 people, there are 10 channels; with 10 people, there are 45. The human brain, capable of retaining only about four “chunks” of information in short-term memory at a time, simply cannot manage this complexity effectively, leading to slowdowns and fragmented work. Teams too large often break into less efficient sub-teams.

The Role of the Scrum Master

To facilitate team performance, Sutherland introduced the role of the Scrum Master. This individual acts as a servant-leader, coach, and facilitator, responsible for ensuring the Scrum process is effective. Their main job is to:

• Facilitate meetings (like the Daily Stand-up).
• Ensure transparency.
• Most importantly, help the team identify and remove impediments that slow them down.

The Scrum Master guides the team toward continuous improvement, constantly asking, “How can we do what we do better?” This role is crucial for enabling self-organization and fostering a drive for greatness.

Overcoming the “Fundamental Attribution Error”

Sutherland discusses the “Fundamental Attribution Error”: the human tendency to attribute others’ negative behaviors to their inherent character, while attributing our own to situational factors. This error fuels blame and hinders problem-solving in organizations.

• The Milgram Experiment: Sutherland references the Milgram experiment (early 1960s, Yale University) on obedience to authority, which demonstrated that ordinary people, under the right systemic pressures, could engage in harmful acts. This suggests that behavior is largely a product of the system, not just individual character.
• NUMMI (New United Motor Manufacturing, Inc.): The joint venture between General Motors and Toyota in Fremont, California, provides a powerful business example. GM closed the plant in 1982, deeming the workforce “the worst in America.” Toyota reopened it in 1984, rehiring most of the same workers but replacing GM managers with their own system. Almost immediately, the NUMMI plant produced cars with the same high quality and low defects as those in Japan. Same people, different system.

Scrum actively counters this error by focusing on examining and fixing the system that produces failure, rather than assigning blame to individuals. It promotes a culture where positive behavior is rewarded through collaboration and tangible results.

The chapter concludes by asserting that great team performance is not magical but the result of intentionally designing a framework that encourages transcendence, autonomy, cross-functionality, and small size, fostering an environment where individuals can align purpose and trust to achieve synchronicity and greatness.

Chapter Four: Time

This chapter emphasizes time as the ultimate constraint in human endeavor and explains how Scrum’s structured approach to time, particularly through Sprints and Daily Stand-ups, maximizes productivity and eliminates wasted effort.

The Sprint: Maximizing Focused Work

Sutherland reveals that the “Sprint”—a core concept in Scrum—was inspired by the MIT Media Lab’s policy in the early 1990s. Every three weeks, teams at the Media Lab had to demonstrate a working and “cool” prototype of their projects. If the demo wasn’t compelling, the project was killed. This forced students to build quickly and get immediate feedback, preventing months of wasted effort on products nobody wanted.

When Sutherland introduced Scrum at Easel in 1993, he promised the CEO a piece of working software every month instead of a Gantt chart. This commitment led to the formal adoption of “Sprints,” chosen for their connotation of intensity and focused effort followed by a review.

• Team WIKISPEED Example: Sutherland highlights Joe Justice’s Team WIKISPEED, which builds street-legal, 100+ mpg cars that are 5-star crash rated and affordable. They operate in one-week Sprints, committing to “Done” features every Thursday. Their workshop features a large whiteboard with “Backlog,” “Doing,” and “Done” columns, reflecting their transparent, continuously improving process. A crucial rule for Sprints is that once a team commits to tasks for a Sprint, nothing else can be added by external forces, protecting the team’s focus and momentum.

The Daily Stand-Up: A Team’s Heartbeat

Sutherland describes the Daily Stand-up (or Daily Scrum) as the heartbeat of a Scrum team. Inspired by Jim Coplien’s research at AT&T’s Bell Labs, which found that the Borland Software Corporation’s “Quattro Pro for Windows” team achieved record productivity (1,000 lines of code per person per week) due to 90% communication saturation (compared to an industry average of 20%), Sutherland sought to replicate this.

He implemented three key rules for the Daily Stand-up:

1. Held at the same time every day: Creates a consistent rhythm.
2. Limited to fifteen minutes: Encourages crisp, direct communication.
3. Everyone stands up and actively participates: Promotes focus and engagement.

During the meeting, each team member answers three questions:

1. What did you do yesterday to help the team finish the Sprint?
2. What will you do today to help the team finish the Sprint?
3. What obstacles are getting in the team’s way?

This meeting fosters self-organization by allowing the team to identify and swarm on problems collectively. The Scrum Master’s role is to ensure these obstacles are removed. Sutherland recounts that after implementing the Daily Stand-up during his first Scrum effort at Easel, the team’s velocity increased by 400% in the very next Sprint, finishing a month’s work in a week.

The Myth of Multitasking

Sutherland vehemently debunks the notion of multitasking as efficient, labeling it as a significant source of waste. He presents compelling evidence:

• Driving and Cell Phones: Research from the University of Utah shows that people talking on cell phones while driving (even hands-free) are more prone to accidents because their attention is diverted from the external environment. Those who believe they are good at multitasking are often the worst at it, as they have trouble inhibiting impulses to switch activities.
• Simple Exercise: Sutherland’s exercise of writing Arabic numerals, Roman numerals, and letters (1-10, I-X, A-L) by rows vs. columns demonstrates how context switching halves the time taken for sequential tasks.
• Gerald Weinberg’s “Quality Software Management”: A table from Weinberg’s book illustrates the “Loss to Context Switching”:
  • 1 simultaneous project: 0% loss
  • 2 simultaneous projects: 20% loss
  • 3 simultaneous projects: 40% loss
  • 4 simultaneous projects: 60% loss
  • 5 simultaneous projects: 75% loss
    This means 75% of work is pure waste when managing five simultaneous projects.
• Harold Pashler’s “Dual Task Interference”: Pashler’s early 1990s research demonstrated that adding even a simple second task doubles the time involved, suggesting a processing bottleneck where the brain can truly only focus on one thing at a time.
• Multitasking and Intelligence: A 2005 study at the University of London found that IQ scores dropped by over ten points in distracting, multitasking environments, indicating that multitasking can literally make you “stupid.”

Sutherland urges individuals to be conscious of the cost of context switching and to minimize it by dedicating blocks of time to complex tasks without interruption.

“Half Done Is Not Done At All”

Borrowing from Taiichi Ohno’s “Lean” manufacturing principles from the Toyota Production System, Sutherland introduces the concept of “Work in Process” (WIP) or “inventory” as waste. Having partially completed items ties up resources without creating any value. Value is only delivered when something is completely “Done” and usable by the customer.

• “Honey-Do” List Analogy: Partially painting a bathroom, having dog food in the trunk but not in the bowl, or writing a mortgage check but not mailing it—these are all examples of expended effort without delivering final value.
• GM’s Excess Inventory: In December 2012, GM laid off workers because it had built too many unsold trucks (245,853 pickups, or 139 days’ worth of inventory, representing $7.5 billion in tied-up capital). While the cars were “built,” they were not “sold,” meaning no value was delivered. The industry standard is 60 days of inventory.

Scrum emphasizes minimizing WIP by ensuring that tasks are either fully “Done” and shippable at the end of a Sprint, or not started at all.

“Do It Right the First Time”

Sutherland highlights the wastefulness of “re-work,” citing James Womack’s The Machine That Changed the World.

• Automobile Manufacturing Comparison: Japanese luxury car manufacturers (e.g., Toyota, Honda) produced cars in 16.8 hours with 34 defects per 100 vehicles. European manufacturers (e.g., Mercedes-Benz) took 57 hours and had 78.7 defects per 100. The key difference: Toyota empowered every worker to stop the production line if a problem was found, fixing it immediately and permanently. European companies had dozens of people at the end of the line fixing defects, meaning they spent more time fixing mistakes than the Japanese spent building the car in the first place.
• Palm’s Software Bugs: Palm, a PDA developer, found that fixing a software bug on the day it was created took 24 times less time (1 hour vs. 24 hours) than fixing it three weeks later. This is due to the “mind space” or mental construct created around a project; re-creating it later is time-consuming.

The lesson is clear: fix mistakes as soon as they are discovered, preventing them from compounding into larger problems.

“Working Too Hard Makes More Work”

Sutherland presents a counterintuitive argument: working long hours actually decreases productivity.

• Scott Maxwell’s Experience at McKinsey & Company: Scott Maxwell, founder of OpenView Venture Partners, observed that working seven days a week at McKinsey in the 1970s was less productive than working six, and then five days a week. He found that beyond ~40 hours/week, productivity declines, and the quality of work suffers.
• The Maxwell Curve: Sutherland references a curve showing that peak productivity occurs at just under 40 hours per week, declining thereafter. Overworked employees make more mistakes, get distracted, and make bad decisions, leading to more work in the long run.
• “Ego Depletion” and Judicial Decisions: Research from Israel, published in Proceedings of the National Academy of Sciences (2011), showed that judges were more likely to grant parole (make favorable, creative decisions) after a food break, with rates dropping to nearly zero before the next break. This “ego depletion” suggests that decision-making capacity is a finite resource that depletes with use and requires rest to replenish.

Sutherland advocates for a sustainable pace, urging companies to send people home at five and encourage true vacations, as this leads to more and better work done. He challenges companies to measure output, not hours worked, recognizing that hours themselves represent a cost if not efficiently utilized.

Waste Is a Crime: Muri, Mura, and Muda

Sutherland reiterates Taiichi Ohno’s three types of waste:

• Muri (Unreasonableness): Waste from absurdity, unreasonable expectations, and overburden. This includes expecting heroic efforts, relying on crisis management, and having onerous company policies or meaningless meetings.
• Mura (Inconsistency): Waste from unevenness or variation, which Scrum addresses through consistent Sprints and daily rhythms.
• Muda (Waste through outcomes): Waste from activities that don’t add value, such as defects, excess inventory, or unnecessary processing.

He adds a fourth, “Emotional Waste,” generated by “assholes” in the workplace who create chaos and fear, undermining team cohesion and excellence.

Sutherland concludes by stating that while all processes are inherently wasteful, Scrum aims to be the lightest-weight process that focuses human effort on effortless “flow,” achieved through discipline and continuous elimination of waste. This ultimately allows people to find joy and purpose in their work.

Chapter Five: Waste Is a Crime

This chapter focuses on the insidious nature of waste in modern work, drawing heavily from Jeff Sutherland’s experiences and the principles of Lean manufacturing, particularly Taiichi Ohno’s insights. It argues that recognizing and eliminating waste is not just about efficiency but about human purpose and dignity.

The Pervasive Problem of Waste

Sutherland begins by noting that while Scrum aims to create positive work rhythms, many organizations are afflicted by “negative patterns”—frustration, despair, and a sense of being trapped in uncaring systems. He recounts a job interview where a candidate described 50% of his work at a textbook company being “completely and totally wasted” due to market changes or shifting direction. Sutherland states that in his experience, about 85% of effort in companies is wasted, with only a sixth of work producing actual value. This pervasive waste, he argues, is “shameful” and a “crime.”

He reiterates Taiichi Ohno’s philosophy from the Toyota Production System: “Waste is a crime against society more than a business loss.” Ohno identified three types of waste: Muri (unreasonableness), Mura (inconsistency), and Muda (outcomes without value). Sutherland links these to Deming’s PDCA cycle: Plan (avoid Muri), Do (avoid Mura), Check (avoid Muda), and Act (the will to address all).

Do One Thing at a Time: The Cost of Multitasking

Sutherland strongly condemns multitasking, calling it “stupid” and inherently wasteful. He highlights:

• Cell Phone Driving Study (Strayer, Drews, and Crouch): Even hands-free, talking on a cell phone while driving significantly impairs attention, leading to drivers failing to “see” objects they are looking at. Research from the University of Utah (Sanbonmatsu et al., 2013) found that people who multitask most have inflated views of their ability and are less able to inhibit impulses to switch tasks.
• Arabic/Roman Numerals Exercise: This simple exercise demonstrates that performing tasks sequentially (completing all Arabic numerals, then all Roman, then all letters) takes approximately half the time compared to switching between contexts (Arabic, Roman, Letter for each number).
• Gerald Weinberg’s “Quality Software Management” Table: This table quantitatively illustrates the “Loss to Context Switching.” With 5 simultaneous projects, 75% of available time is lost to context switching, meaning three-quarters of the day’s effort produces no value.
• Harold Pashler’s “Dual Task Interference”: Research shows that adding even a simple second task doubles the time involved due to a “processing bottleneck.” The brain must “pack up” one process, pull out another, and run it, consuming time.
• Brain Scans (Charron & Koechlin, 2010): fMRI studies suggest that while it’s possible to “think” about two things simultaneously, the brain is actually rapidly switching between tasks in a serial fashion.
• Multitasking and IQ (Wilson, 2005): A small study found that mean IQ scores dropped by over ten points in distracting, multitasking environments.

Sutherland advises individuals to be conscious of this cost and minimize it by creating focused blocks of time for complex tasks, shutting off distractions. For teams, he illustrates that by working on one project to completion before moving to the next, they can finish multiple projects in a little more than half the time compared to trying to do everything at once.

Half Done Isn’t Done At All: The Waste of Work in Process (WIP)

Drawing from Lean manufacturing, Sutherland emphasizes that Work in Process (WIP) is a form of waste or “inventory.” Just as unsold cars on a lot (like GM’s $7.5 billion in excess truck inventory in 2012) represent tied-up capital and effort, so do partially completed projects.

• “Honey-Do” List: A list of partially completed chores (e.g., half-painted wall, unmailed check) represents expended effort without delivering any value. Value is only created when the task is completely “Done.”
• Scrum’s “Definition of Done”: Scrum addresses WIP by requiring that at the end of each Sprint, every completed item meets a “Definition of Done,” meaning it’s a complete, deliverable product that can be used by a customer. If something is half-done, it’s considered not done at all, and resources invested are wasted.

Do It Right the First Time: The Cost of Rework

Sutherland highlights the enormous cost of “re-work,” or fixing mistakes after they’re made.

• Toyota vs. European Car Manufacturers (Womack et al., The Machine That Changed the World): Toyota’s approach of empowering every worker to stop the production line to fix problems immediately resulted in vastly fewer defects and faster production times compared to European luxury car makers who spent more time fixing defects at the end of the line than Toyota spent building the car initially.
• Palm Software Bug Fixes: Palm’s internal data showed that fixing a software bug on the day it was created took 24 times less time than fixing it three weeks later. This is because the developer can easily recall the “mind space” and context of the original work.

The lesson is to fix mistakes immediately when they are discovered, preventing the exponential increase in time and effort required for later fixes.

Working Too Hard Only Makes More Work: The Impact of Overwork

Sutherland argues that excessive work hours are counterproductive.

• Scott Maxwell’s Experience (OpenView Venture Partners): Maxwell observed that working beyond 40 hours a week leads to diminishing returns and eventually negative productivity. He began sending employees home early, emphasizing that working late was a sign of failure, not commitment, because overworked employees make more mistakes, become distracted, and make bad decisions.
• “Ego Depletion” (Avnaim-Pesso et al., 2011): The study of Israeli judges’ parole decisions demonstrated that their capacity for making sound, favorable decisions (requiring more mental energy) declined over time between breaks, indicating that decision-making itself depletes mental resources.
  Sutherland concludes that by respecting the brain’s limitations and encouraging rest, individuals and teams can achieve more and higher-quality work. He advocates for measuring output, not hours.

Unreasonable Expectations and Emotional Waste

Sutherland expands on Ohno’s Muri (Unreasonableness):

• Absurdity: Setting impossible goals that only demotivate teams.
• Unreasonable Expectations: Relying on “heroic actions” to meet deadlines is a sign of systemic failure, leading to burnout and preventing continuous improvement.
• Overburden: Imposing onerous policies, unnecessary reporting, and meaningless meetings (the “Dilbert cartoon” office).

He adds “Emotional Waste,” caused by “assholes” who create chaos and fear, undermining team morale and effectiveness. Sutherland stresses that these behaviors must be eliminated for a healthy, productive environment.

Ultimately, Sutherland concludes that Scrum’s underlying goal is to achieve effortless “flow” in work. While process is inherently wasteful, Scrum strives to be the lightest possible framework that enables focused, disciplined human capability, by systematically identifying and eliminating waste, thereby allowing individuals to experience joy and purpose in their work.

Chapter Six: Plan Reality, Not Fantasy

This chapter critically examines traditional project planning, revealing why detailed, upfront plans often fail. It then introduces Scrum’s adaptive planning approach, emphasizing prioritization, relative estimation, and continuous adjustment based on real-time feedback.

The Illusion of Upfront Planning

Sutherland starts with a phone call from Mark Landy, Chief Architect of Software at Medco (a Fortune 100 pharmaceutical company), detailing a crisis. Medco’s president, Kenny Klepper, had promised Wall Street a new system of specialized Therapeutic Resource Centers by July 7, 2007. This ambitious plan, meant to improve patient care and guarantee cost savings by providing comprehensive pharmacist insights into patient medications, was announced without consulting the technical teams on implementation time. The teams later discovered that, at best, the project would be delivered a year late.

Sutherland explains that this failure stemmed from a common mistake: the belief that everything can be planned upfront. Months were spent creating plausible-looking detailed plans (like Waterfall Gantt charts) that ultimately described a fictional reality. The problem, Sutherland asserts, is that “the map is not the terrain,” and the act of planning itself often becomes more important than the actual plan or its connection to reality.

Unraveling the Medco “Deadlock”

Sutherland and Scrum trainer Brent Barton arrived at Medco in December 2006 to address the crisis. They faced a company in “deadlock” with numerous conflicting interests. Their first step was radical transparency: they asked everyone involved to print out all project documentation. The resulting two-foot-tall stack of paper was largely unread and filled with duplication and boilerplate—over 50% was pure waste.

They then guided the teams to:

• Cut out every actionable item and stick it on the wall as a sticky note.
• Estimate the effort for each sticky note (not time, but “work”).
• Define a “Definition of Done” for each task, incorporating FDA compliance, quality assurance, and other requirements at the work-item level, not just at the end of the project. This prevents rework and ensures quality from the outset.

This process transformed an overwhelming stack of paper into a comprehensible, manageable set of tasks, likened to “eating an elephant, one bite at a time.”

The “Cone of Uncertainty” and Adaptive Planning

Sutherland introduces the “Cone of Uncertainty,” a graph showing that initial project estimates can be wildly inaccurate (ranging from 25% to 400% of actual time, a factor of 16 difference). As a project progresses and more is learned, the estimates narrow until they align with reality. This highlights the folly of detailed upfront planning for complex endeavors.

Scrum’s solution is to refine the plan throughout the project, rather than doing it all at the start. The key is to:

• Plan in just enough detail to deliver the next increment of value.
• Estimate the remainder of the project in larger chunks.
• Deliver a working “increment” at the end of each iteration to get immediate customer feedback. If the direction is wrong, the plan can be changed quickly.

Relative Sizing: “Dog Points” and the Fibonacci Sequence

Since humans are poor at absolute time estimation but good at relative sizing, Scrum uses comparative methods for estimating work effort.

• “Dog Points” (Mike Cohn): Teams estimate tasks by comparing them to different dog breeds (Dachshund = 1, Labrador = 5, Great Dane = 13). This allows for intuitive, relative comparisons.
• Fibonacci Sequence (1, 3, 5, 8, 13, etc.): Scrum commonly uses numbers from the Fibonacci sequence for estimation. These numbers are “far enough apart” that the difference between them is easily discernible, preventing subtle but misleading distinctions (like 5 vs. 6). This sequence, which appears frequently in nature, aligns with human intuitive understanding of ratios, facilitating group consensus.

Avoiding Bias: The Delphi Method and Planning Poker

To ensure accurate, unbiased group estimation, Scrum employs techniques to counter common cognitive biases:

• Informational Cascade (Bandwagon Effect): People follow the actions of those before them, disregarding their own information (e.g., journal rejections).
• Halo Effect: One positive characteristic influences perceptions of unrelated qualities (e.g., attractive people assumed to be smart).

Sutherland references the Delphi method, developed by the Rand Corporation in the 1950s, which uses anonymous surveys and iterative feedback to narrow expert opinions without bias. While effective, Delphi is too slow for daily Scrum.

• Planning Poker: This quick and accurate method uses decks of Fibonacci-numbered cards. Each person secretly chooses a card representing their estimate for a task, then all cards are revealed simultaneously.
  • If estimates are close (within two cards), they are averaged.
  • If estimates vary widely (more than three cards apart), the highest and lowest estimators explain their reasoning, and the group re-estimates.
    This process ensures all knowledge is shared and reduces anchoring biases. Sutherland notes that only the team doing the work should do the estimating, as demonstrated by the failure of GSI Commerce’s attempt to use “expert” estimators, which resulted in unusable estimates and project disasters.

Work as “Stories”: Character, What, and Why

To provide context and motivation, Scrum reframes tasks as “User Stories” following a structure: “As a [character/role], I want [what], so that [why/motivation].”

• Example: Captain Picard’s Log: “As a starship captain, I’d like the log function to automatically use today’s stardate…” The “why” (e.g., for audit, or simply convenience) drives different implementation approaches.
• Example: Special Forces Mission (Tim Stoll): A Special Forces medic planned his mission to Laos using “Courses of Action” as stories: “As a Special Forces medic, I must teach basic physiology to my students, so they can understand the human body.” This ensured the motivation and value were clear.

Stories should be:

• INVEST Criteria (Bill Wake): Independent, Negotiable, Valuable, Estimable, Small, and Testable.
• “Definition of Ready”: Stories meet INVEST criteria before being brought into a Sprint.
• “Definition of Done”: Clearly defined conditions and tests a story must pass to be considered complete. Sutherland states that Ready stories double implementation speed, and truly Done stories double speed again.

Knowing Your Velocity and Addressing Impediments

After a few Sprints, a team can calculate its “Velocity”—the total points of completed stories per Sprint. This provides a measurable pace. The Product Owner can then use this velocity, combined with remaining Backlog points, to forecast a reliable completion date.

At Medco, after three Sprints, the team’s velocity accelerated from 20 to 60 points/Sprint (a 400% increase), forecasting a December 1 delivery. Management, however, insisted on the original July 1 target. Sutherland presented a list of twelve “impediments” (from process issues to interpersonal conflicts) to senior management, who, inspired by a former Toyota executive, eliminated them within four days. This immediate removal of impediments further accelerated velocity to 90 points/Sprint, pushing the delivery to September 1. Through continued negotiation and scope reduction, they ultimately met the July 2007 deadline.

This Medco case demonstrates how Scrum transforms culture, empowers teams, and aligns interests to deliver real value. The company’s stock price doubled within a year, and the experience paved the way for “Medco 2.0,” a company-wide restructuring based on Scrum.

Chapter Seven: Happiness

This chapter makes a powerful case for happiness as a fundamental driver of success, not just a byproduct. Sutherland argues that happiness, when properly cultivated and measured, is a key predictive metric for organizational performance and personal fulfillment.

Happiness as a Predictive Measure

Sutherland asserts that real happiness is found in the “pursuit,” not just the “arrival.” He uses the analogy of mountain climbers who find joy in the struggle of the climb, not just the summit. He challenges the societal norm that only rewards results, not processes.

Drawing on research from Harvard’s Professor Tal Ben-Shahar (Happier), Sutherland emphasizes that “Happiness leads to success in nearly every domain of our lives… happiness precedes important outcomes and indicators of thriving.” Happy individuals are more likely to:

• Secure job interviews.
• Receive positive supervisor evaluations.
• Show superior performance and productivity.
• Be better managers.
• Make more money.
• Have better jobs.
• Live longer and be healthier.

Even small increases in happiness lead to markedly better outcomes. Sutherland’s goal for Scrum is to provide a framework that systematically builds this happiness, using rigor and hard data to prove its value.

Quantifying Happiness: The Happiness Metric

To ensure happiness is not just a vague concept but a measurable force for improvement, Sutherland developed the “Happiness Metric.” At the end of each Sprint, each team member answers four simple questions:

1. On a scale from 1 to 5, how do you feel about your role in the company?
2. On the same scale, how do you feel about the company as a whole?
3. Why do you feel that way?
4. What one thing would make you happier in the next Sprint?

This exercise fosters insightful conversations and helps the team quickly identify a “kaizen” (continuous improvement) for the next Sprint. This improvement must be concrete and actionable, with acceptance tests to confirm its completion in the next Sprint Retrospective.

Sutherland illustrates with his own company, Scrum, Inc. After implementing the Happiness Metric, his company’s velocity tripled from 40 to 120 points per Sprint in just a few weeks, simply by addressing the issues that made people unhappy (e.g., vague user stories). He also notes that the Happiness Metric is a predictive indicator; a drop in happiness often precedes a drop in velocity or productivity by weeks, allowing management to intervene before a crisis.

The Power of Transparency: Making Everything Visible

A crucial element for cultivating happiness and high performance is transparency.

• “Sunshine” Laws Analogy: Inspired by Colorado’s “Sunshine” laws that mandate open public meetings and records, Sutherland believes that in Scrum, “everyone should know everything.” There should be no secret cabals or hidden agendas.
• PatientKeeper Example: When Sutherland implemented Scrum at PatientKeeper (a hospital application developer), he made all engineering data transparent. Despite initial developer apprehension (fear of being “beaten up” by metrics), this transparency enabled cross-team coordination and identified roadblocks. Productivity increased more than four times, leading to 45 product releases per year (compared to two after a new management team abandoned Scrum). This demonstrated that transparency, while initially scary, is vital for rapid innovation.
• Open Financials: Sutherland advocates for making all company financials (salaries, expenditures, P&L statements) visible to everyone. He argues that secrecy only serves individual agendas and infantilizes employees, whereas full transparency fosters alignment with a unified purpose.
• The Scrum Board: The visual centerpiece of transparency is the Scrum board (To Do, Doing, Done columns). Sticky notes, representing tasks, are moved across the board, providing a real-time, at-a-glance view of progress and challenges for anyone in the room. This self-regulating mechanism allows teams to quickly identify and address issues, such as a story stuck too long in “Doing.”

Delivering Happiness: Zappos’s Culture of Connection

Sutherland highlights Zappos as a company that successfully integrates happiness into its core culture, leading to phenomenal growth (from $1.6 million to over $1 billion in sales in eight years).

• “Wow!” Moments and Happy Employees: Zappos focuses on creating “Wow!” moments for customers, understanding that this requires “happy people on the other end of the phone.”
• Culture of Connection: Zappos deliberately fosters connections among employees through:
  • Physical design: Closing all but one exit to encourage chance encounters.
  • “Boot Camp”: A four-week intensive onboarding for every employee (from warehouse to director) that instills company culture and creates lasting bonds.
  • Internal Hiring and Learning: Prioritizing internal promotions and offering free classes (e.g., “Finance 101,” “Coding for Beginners”) to encourage continuous learning and growth (mastery).
• Empowerment and Accountability: Zappos allows employees to “control their own destiny” and grow, which leads to high employee satisfaction. They have a 12% attrition rate, with most turnover in their call center where those not “passionate about delivering for customers” are let go.
• Eliminating “Misers”: Like Scrum, Zappos’s transparency quickly exposes “misers”—individuals who hoard specialized knowledge. Sutherland states that in his companies, such individuals are given a choice: change their mindset or leave.

“Thriving” vs. Complacency: Popping the Happy Bubble

Sutherland clarifies that true happiness in the workplace is not complacency but “passionate engagement” and “thriving.” Research from Harvard Business Review (Spreitzer and Porath, 2012) found “thriving” employees perform 16% better, have 125% less burnout, and are 32% more committed.

However, a danger exists: the “happy bubble.” This occurs when successful Scrum teams become complacent, resting on their laurels and believing they no longer need to improve. This leads to a productivity plateau and eventual decline, akin to the overconfident 2004 US Olympic basketball team.

• Role of the “Wise Fool”: To pop this bubble, Sutherland advocates for “Wise Fools”—individuals (like the child in “The Emperor’s New Clothes”) who ask uncomfortable questions and speak uncomfortable truths, even if it challenges the team’s comfort zone.
• Constant Measurement: Regularly measuring velocity and happiness helps identify complacency. If there’s no positive growth or if happiness drops despite seemingly good results, it signals an underlying problem.

Happiness Today, Happiness Tomorrow: The Four Types of People

Sutherland uses Ben-Shahar’s framework of how people approach work:

• Hedonist: Focuses on immediate happiness, ignoring future consequences (e.g., start-ups without sustainable products).
• Nihilist: Experiences unhappiness today with no hope for a better tomorrow (e.g., burnt-out employees).
• Rat-Race Addicted: Endures unhappiness today for a promised, but often elusive, future happiness (e.g., managers constantly seeking promotions).
• Thriver (Scrum Ideal): Finds work enjoyable today and sees a path to continued enjoyment and fulfillment in the future.

Scrum aims to move everyone toward the “thriver” mindset by systematically removing causes of unhappiness and empowering people. It aligns with Maslow’s hierarchy of needs, focusing on the top layers of self-esteem and self-actualization (achieving full potential), which lead to greater effectiveness and innovation.

Sutherland concludes that happiness, when effectively harnessed through Scrum’s tools like the Happiness Metric and transparency, drives results, transforms cultures, and ultimately helps people achieve greatness in their work and lives.

Chapter Eight: Priorities

This chapter delves into the critical importance of effective prioritization in Scrum, explaining how to align effort with value to maximize impact and achieve “greatness” in any endeavor. Sutherland argues that knowing what to do first is as crucial as knowing how to do it efficiently.

The Problem of Misplaced Priorities

Sutherland opens by reiterating his collaboration with Scott Maxwell of OpenView Venture Partners, emphasizing that Scrum’s power lies not just in speed but in boosting impact (revenue, in the VC world). He presents a Venn diagram showing the intersection of “what you can build,” “what you can sell,” and “what you are passionate about.” The “sweet spot” at the center represents a vision rooted in reality with a real possibility of greatness. Many companies, like Pets.com (compared to Zappos), fail because they have vision and passion but lack a clear sense of what to do when—they don’t prioritize effectively.

The Product Backlog: The Definitive List

The first step in Scrum is creating a Product Backlog—a comprehensive list of everything that could possibly be included in a product or project over its lifetime. It serves as the single, definitive product roadmap, reflecting the Product Owner’s vision.

• Home Automation System Example: Sutherland describes a company building a home automation system that created a Backlog with hundreds of “stories” (e.g., “As a home owner, I want to be able to see who is at my door, so that I can open the door only for those people I want to come in.”).
• Prioritization is Key: The critical step is to prioritize this list based on business impact, customer importance, revenue potential, and ease of implementation. The goal is to deliver the most value with the lowest risk first. Scrum’s incremental development aims to “de-risk” a project by creating revenue and demonstrable value as early as possible.
• 80/20 Rule (Pareto Principle): Sutherland stresses a fundamental rule in product development: “80 percent of the value is in 20 percent of the features.” Scrum’s goal is to identify and build that crucial 20% first, avoiding the waste of traditional methods where teams often build 80% waste before realizing what customers truly want.

The Product Owner: Visionary and Value Accountability

Sutherland describes the Product Owner as one of the three core roles in Scrum. This individual is responsible for owning the Backlog, defining its content, and, most importantly, prioritizing it.

• Inspiration from Toyota’s Chief Engineer (Shusa): The role is inspired by Toyota’s Chief Engineer, a powerful but non-authoritarian leader who “owns” the vision for a product line (e.g., Corolla). Shusas don’t have direct reports but influence by persuasion and knowledge, not coercion. This concept informed Sutherland’s decision to split the leadership role into the Scrum Master (how) and Product Owner (what).
• First Product Owner: Don Rodner: Sutherland appointed Don Rodner, a smart individual from Product Marketing (not Engineering), as the first Product Owner at Easel. Rodner understood the product from a customer’s perspective, which is crucial.

Sutherland distills the essential characteristics of a Product Owner to four:

1. Knowledgeable about the Domain: Understands both what’s technically possible and what truly translates into meaningful value for the market/customer.
2. Empowered to Make Decisions: Has the authority to set the product vision and prioritize the Backlog, resisting internal and external pressures.
3. Available to the Team: Engages in constant dialogue with the team, explaining tasks and incorporating their expertise. Lack of availability is a common cause of Scrum failure.
4. Accountable for Value: Measured by concrete outcomes, such as revenue generated per “point” of effort, number of arrests made (for a law enforcement team), or church congregation growth.

The OODA Loop: Rapid Decision-Making

Sutherland reinforces the importance of John Boyd’s OODA loop (Observe, Orient, Decide, Act) as fundamental to the Product Owner’s role and Scrum itself. This loop, derived from air-to-air combat, emphasizes rapid decision-making based on real-time feedback.

• “Inside the Enemy’s Decision Loop”: Boyd’s insight was that superior visibility and faster decision-making (e.g., F-86 Sabre’s bubble canopy vs. MiG-15’s restricted view) allowed American pilots to react quicker, confusing and paralyzing the enemy.
• Scrum’s Application: Scrum enables the Product Owner to get constant, real-time feedback on delivered increments (the “Observe” step). This allows for rapid “Orienting” (adjusting understanding of the market), “Deciding” (re-prioritizing the Backlog), and “Acting” (the next Sprint’s work). This continuous feedback cycle accelerates innovation and adaptation.
• Incremental Releases: Even for complex products like cars or video games, the key is to deliver “Minimum Viable Products” (MVPs) or prototypes that generate real feedback.
  • Toyota Prius: Achieved a 15-month development cycle by rapidly prototyping and continuously improving vehicles based on feedback, rather than adhering to a fixed upfront design.
  • Team WIKISPEED: Produces and sells fully functional car prototypes every week, getting immediate feedback from early adopters.
  • Video Games: More developers now use “early access” alphas to gather feedback from dedicated fans, allowing for real-time adjustments before full release.
    This strategy allows companies to make mistakes early and cheaply, course-correcting before major investments are made.

“First Things First”: Constant Reprioritization

The Product Owner’s job is not to set a fixed order but to constantly update and re-prioritize the Backlog every Sprint. The “right” order is always in flux, adapting to new information, market changes, and team learnings. Sutherland cites Frederick II of Prussia’s adage, “He who will defend everything defends nothing,” to warn against the danger of prioritizing everything, which leads to thinning resources and achieving nothing. The German defense against the D-Day invasion failed partly because they spread forces too thin, unable to prioritize attack points.

“Money for Nothing and Change for Free”: De-Risking Projects

Sutherland proposes a radical contract model: “Change for Free.” Instead of costly change orders that stifle innovation and learning, a fixed-price contract allows clients to freely change priorities and features within the agreed-upon effort.

• Software Developer Example: A Scrum developer won a $10 million, 20-month contract with a clause allowing early termination with a 20% penalty on the remaining value. After three months and $1.5 million spent, the customer terminated the contract, having received the needed value. The customer paid $3.2 million for software that would have cost $10 million and got it 17 months early. The Scrum company increased its profit margin from 15% to 60%. This “win-win” aligns interests and highlights Scrum’s ability to deliver high value quickly.

This model fundamentally addresses financial risk and market risk. By delivering value incrementally, companies quickly learn what customers truly want and are willing to pay for, avoiding massive investments in products that might not succeed. It also helps manage technical risk by building and comparing multiple prototypes (set-based concurrent engineering) before committing to full production.

Sutherland concludes by urging immediate action: start with a small Backlog (a week’s worth), form a team, and begin Sprinting. The Product Owner should create a high-level roadmap, but remain flexible, knowing the picture will constantly change. This transparency and continuous adjustment are key to Scrum’s power.

Chapter Nine: Change the World

This concluding chapter broadens Scrum’s application beyond business and technology, demonstrating its potential to solve humanity’s most complex problems, from education and poverty to government, and even shape the future of work itself.

Scrum’s Universal Applicability

Sutherland begins by reiterating that Scrum’s principles are universally applicable, accelerating human effort regardless of the domain. He points to its emergence in unexpected areas, tackling deep societal challenges.

Revolutionizing Education: eduScrum in the Netherlands

Sutherland details “eduScrum” as implemented by Willy Wijnands, a chemistry teacher at Ashram College in Alphen aan den Rijn, Netherlands. Wijnands applies Scrum to high school chemistry classes:

• Team-Based Learning: Students form cross-functional teams based on self-rated skills (bravery, math enjoyment, organization), learning to appreciate diverse talents.
• Student-Led Planning: Students gather around Scrum boards (“flops”) with columns like “Alle items,” “Te doen,” “In uitvoering,” and “Klaar” (All Items, To Do, In Progress, Done). They decide which lessons to tackle, moving sticky notes from the Backlog to “Te doen.”
• “Definition of Done” for Learning: A key metric is “everyone understands the material.” Wijnands quizzes students on “Klaar” items; if any student doesn’t grasp a concept, it goes back to “Te doen.”
• “Definition of Fun”: Boards include a “Definition of Fun” with criteria like “Trust,” “Humor,” and “Gezelligheld” (a uniquely Dutch word for coziness/belonging).
• Daily Stand-ups and Retrospectives: Teams conduct brief check-ins and regular retrospectives to improve their learning process, even assigning their own homework based on what’s needed to meet Sprint goals.
• Measurable Results: In Wijnands’s classes, average test scores jumped over 10%, and students report deeper understanding and better collaboration.
• Scaling Impact: eduScrum is growing beyond Ashram College, with the eduScrum Foundation in the Netherlands training teachers and expanding to new schools, aspiring to be a new “Montessori movement.” Sutherland notes that an autistic student, previously unengaged, found a way to thrive with Scrum, showing its capacity to help individuals connect and flourish.

Fighting Poverty: The Grameen Foundation in Uganda

Sutherland recounts how the Grameen Foundation uses Scrum to combat poverty in rural Uganda, drawing parallels to the microfinance principles that originally inspired Scrum.

• Community Knowledge Workers (CKWs): The Foundation recruited 1,200 CKWs in remote villages, providing them with smartphones containing agricultural and market information.
• Actionable Data: Farmers can identify plant diseases, get instant, low-cost treatments, and access real-time market prices, empowering them to negotiate better deals with middlemen.
• Measurable Impact: One woman’s agricultural yield doubled, and her prices doubled (from 300 to 600 shillings per bushel) after accessing market data via the CKWs. This translates to double the profit for the same work.
• Scrum in Kinshasa Office: Eric Kamara, who heads technology for Grameen’s Kinshasa office, uses Scrum to prioritize application features. His team rates features on a 1-7 scale based on: importance to mission, contribution to CKW work, and partner support. This transparency helps focus limited non-profit resources on high-impact initiatives.
• Eliminating Wasteful Meetings: The Kinshasa office replaced dreaded, hours-long status update meetings with Scrum boards and daily check-ins, allowing the director to instantly see roadblocks and leading to faster problem-solving.

Scrum harnesses the passion of NGO workers by providing discipline, clarity, and accountability, enabling measurable social good through the “Progress Out of Poverty Index.”

Reforming Government: Transparency and Accountability

Sutherland argues that government, often mired in bureaucracy and outdated practices, can also benefit from Scrum.

• Washington State’s Lean Government: The Chief Information Officer’s (CIO) office in Washington State, under Governor Jay Inslee, has embraced “Lean government” and implemented Scrum. They tore down cubicle walls, formed Scrum teams, and aim to deliver actionable, implementable policies every week (their “shippable product”). This incremental approach (e.g., updating customer call processes without waiting for all documentation) aims to deliver value faster and continuously.
• Challenges: Roadblocks include state laws mandating Waterfall methods and legislative structures fragmented into committees, which makes holistic “outcome-based” legislation difficult.
• Iceland’s Constitution: After the 2008 financial crisis and the “pots and pans revolution,” Iceland’s constitutional committee used Scrum. They delivered one section of the constitution to the public every Thursday, collecting feedback via Facebook and Twitter. This highly transparent and collaborative process led to a new constitution with overwhelming public support, although it was later ignored by the established political parties. This demonstrates Scrum’s ability to drive public engagement and responsiveness even in large-scale governance.

Sutherland asserts that Scrum’s speed, transparency, and responsiveness will ultimately defeat traditional, obfuscating power structures.

The Future of Work: Valve’s “Flatland”

Sutherland concludes by presenting Valve, a self-funded video game and software company, as a model for how organizations may operate in the future.

• “Welcome to Flatland”: Valve has no traditional management or hierarchy. Employees don’t “report to” anyone, including the founder/president, Gabe Newell. Every employee has the power to green-light and ship projects.
• Self-Organizing Teams (“Cabals”): Projects start when someone decides to pursue an idea and convinces others to join. Employees literally vote with their desks, wheeling them into new “cabal” configurations to collaborate on projects.
• “Big Picture” Example: Greg Coomer, a Valve founder, describes how he initiated the “Big Picture” project (delivering Steam games to TVs and mobile devices) by mocking up a vision and then using a “movie” to recruit needed talent (coders) to his team. The team decided when the product was “good enough” to ship.
• Peer Review and Accountability: While there are no bosses, constant peer review acts as a powerful corrective. If a team member isn’t contributing or acting in alignment with Valve’s ethos, other team members address it, sometimes leading to dismissal (as happened in 2013 when a large influx of new hires struggled to adapt).
• Innovation through Freedom: Valve’s ethos is to eliminate internal structures that serve their own needs rather than customer value. They are constantly changing and innovating, not just in crisis.
• Scrum-like Principles: While Valve doesn’t mandate Scrum, many teams naturally adopt its principles (whiteboards with sticky notes, self-organization), recognizing its effectiveness in maximizing human freedom, ability, and creativity.

Sutherland argues that Valve represents a “capitalist innovation” as powerful as industrial revolutions, demonstrating that a focus on human potential and transparent, self-organizing structures can lead to immense success. He ends with a call to action, urging readers not to listen to cynics but to “amaze them with what can” be done through Scrum.

Key Takeaways

• Prioritize Value Over Volume: The core insight of Scrum is to focus on delivering the 20% of features that provide 80% of the value. Always ask: what is most important to the customer, and how can we deliver that value as quickly as possible, even if it feels incomplete?
• Embrace Change and Uncertainty: Traditional, rigid plans (Waterfall) are doomed to fail in complex environments. Scrum thrives on continuous adaptation, recognizing that “the map is not the terrain” and that plans will always change.
• “Done” Means Deliverable Value: Half-done is not done. Every “Sprint” (a fixed, short period of work, usually 1-4 weeks), the goal is to produce a “potentially shippable” increment of value that can be seen, tested, and used by a customer. This ensures real progress and early feedback.
• Multitasking Is a Myth and a Crime: Stop trying to do multiple things at once. Context switching is a massive waste of time and energy, making you slower and less effective. Focus on one task at a time until it is truly “Done.”
• Happiness Drives Success: Happy people are more productive, creative, loyal, and make better decisions. Measure happiness as a predictive metric, and actively work to remove impediments that hinder it. Empowering teams with autonomy, mastery, and purpose is key to fostering genuine engagement.
• Transparency and Open Communication: Make all work visible through tools like the Scrum board. Encourage open dialogue, even about uncomfortable truths. Eliminate secrecy and silos, as they breed distrust and slow progress.
• Optimize the System, Not Just Individuals: Don’t blame individuals for systemic failures. Scrum focuses on identifying and removing “impediments” and improving the underlying process (kaizen) to enable the team to perform at its best.
• A Leader Is Not a Boss: The Product Owner defines what needs to be done and why, while the team decides how to do it. The Scrum Master coaches the team and removes obstacles. Leadership in Scrum is about enablement and persuasion, not command and control.
• Accelerate Everything: Scrum’s principles of short cycles, continuous feedback, and relentless improvement can be applied to any human endeavor—from software development and car manufacturing to education, poverty alleviation, and government reform.

Next Actions:

1. Form a Small Team: Gather a cross-functional team of 3-9 people with all the skills needed for a project.
2. Appoint a Product Owner: Choose someone knowledgeable about the domain, empowered to make decisions, available to the team, and accountable for value.
3. Appoint a Scrum Master: Select a facilitator who will coach the team and relentlessly remove impediments.
4. Create a Product Backlog: List all potential items for your project, prioritize them by value, and estimate them using relative sizing (e.g., Fibonacci numbers).
5. Start Your First Sprint: Begin a short, time-boxed iteration (1-4 weeks), committing to a “Definition of Done” for what you aim to achieve.
6. Hold Daily Stand-ups: Conduct 15-minute daily meetings answering: What did you do? What will you do? What’s blocking you?
7. Conduct Sprint Reviews and Retrospectives: At the end of each Sprint, demo your “Done” product, and then reflect on what went well and what can be improved for the next Sprint.

Reflection Prompts:

• Where in your current work or personal life are you experiencing the “waste” of multitasking or “half-done” efforts? What is one specific, small change you can make to minimize this waste this week?
• If you were to apply the “Happiness Metric” to your own role or your team, what would be the single most impactful “kaizen” you could implement in the next week or month to increase joy and productivity?
• How can you, or your organization, better embrace transparency to foster trust and accelerate progress, even if it feels uncomfortable at first?