Book Notes #39: Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

The most complete summary, review, highlights, and key takeaways from Scrum. Chapter by chapter book notes with main ideas.

Title: Scrum: The Art of Doing Twice the Work in Half the Time
Author: Jeff Sutherland
Year: 2014
Pages: 256

Scrum: The Art of Doing Twice the Work in Half the Time is a book written by Jeff Sutherland, one of the co-creators of Scrum, that provides an overview of how to increase productivity and efficiency using Scrum methodologies.

What if working faster didn’t mean working harder—and doing less actually led to better results? That’s the surprising promise behind Scrum, a book that doesn’t just challenge how we work—it offers a totally different mindset.

That change-maker point is Scrum. According to its creators, at least.

As a result, I gave this book a rating of 9.0/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Scrum

Work Smarter

Instead of doing more, Scrum teaches you to do less—with more focus and impact. You stop wasting time on things that don’t matter. You learn how to get real results, faster.

Fix Broken Systems

Most workplaces are full of waste, delays, and frustration. This book gives you a way to fix those problems without burning out. It’s a refreshing take on how work can actually work better.

Real-World Impact

Scrum isn’t just for tech teams. It’s been used in schools, governments, and even in the fight against poverty. The stories show how these ideas can change lives—not just workflows.

Book Overview

Have you ever wondered why some teams seem to achieve the impossible while others, despite working hard, seem to get stuck in a never-ending loop of inefficiency and frustration?

In Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland reveals a game-changing approach that might just be the key to understanding how some teams consistently outperform others.

This isn’t just about getting things done faster—it’s about getting the right things done, and doing them in a way that feels energizing, motivating, and—most importantly—sustainable.

The core of Scrum isn’t a set of rigid steps or a secret formula for success. It’s a mindset shift. Rather than relying on traditional, rigid planning methods that lock teams into unrealistic expectations and huge, monolithic goals, Scrum encourages adaptability, speed, and collaboration. The idea is simple: focus on small, iterative steps that provide real feedback quickly, adjust based on that feedback, and keep moving forward. Scrum teaches that you don’t need to work harder or longer—you need to work smarter.

One of the most powerful insights from this book is how time is handled. Sutherland doesn’t just talk about managing time better, he challenges the entire way we think about it. Traditional project management is obsessed with creating detailed schedules and plans that are often wildly inaccurate, only to be discarded as the project evolves. In contrast, Scrum proposes that we should stop pretending we can predict the future and instead embrace short, focused work cycles known as Sprints.

Each Sprint is a time box—a fixed period where teams commit to completing certain tasks, after which they get immediate feedback on whether their efforts have paid off. No more waiting until the end of a multi-year project to find out it’s off-track. This shift to smaller, focused chunks of work makes progress measurable and manageable, and encourages the kind of continuous learning that leads to real, lasting improvements.

What’s particularly inspiring is how these principles apply far beyond tech teams and software projects. Sutherland shares stories of schools in the Netherlands where teachers brought Scrum into classrooms, transforming education by giving students the autonomy to organize and direct their work in teams. Instead of endless lectures and homework assignments, students worked in collaborative sprints, learned from one another, and engaged with real-world problems.

The results? Test scores went up, and more importantly, students found new joy in learning. It was a prime example of how Scrum’s focus on collaboration, accountability, and progress can impact not just companies, but entire communities.

But the lessons in this book aren’t just for those who run businesses. Scrum provides a framework for improving any kind of system, whether it’s in healthcare, government, or even personal productivity. The concepts of transparency and constant improvement can be applied to just about any area of life. Want to make a habit of writing more?

Create a small sprint of writing for a set period each day and measure your progress. Struggling with managing a household? Treat each week as a Sprint to focus on a specific improvement, then reflect on what worked and what didn’t. The beauty of Scrum is that it’s a flexible tool that anyone can use to break down big goals into achievable actions, and it’s proven to work not just for businesses, but for real, human problems too.

By the end of Scrum, the reader is left with the undeniable truth that it’s not just the big, fancy plans that matter—it’s the small, everyday choices we make to keep things moving forward. It’s about focusing on what delivers value, learning from our mistakes, and keeping the pace up so we never get bogged down in unnecessary details.

The real challenge, as Sutherland points out, is getting over the urge to fall back into traditional, linear thinking and embracing the chaotic, yet deeply fulfilling world of iteration, feedback, and continuous improvement.

This book doesn’t just lay out a methodology—it inspires a new way of thinking about work and life. By focusing on small, steady improvements and getting feedback fast, we can achieve more, learn faster, and—most importantly—enjoy the journey.

The world is full of inefficiencies, but Scrum proves that with the right mindset, we can begin to tackle them, one Sprint at a time.

Ken Schwaber and Jeff Sutherland

Ken Schwaber sees Scrum not as a solution, but as a mirror. In his view, Scrum exists to expose the dysfunctions that organizations would rather not face—unclear priorities, siloed teams, command-and-control leadership, and the illusion of predictability in complex work.

In The Enterprise and Scrum, Schwaber is clear: Scrum is intentionally disruptive. It’s designed to force uncomfortable conversations and shine a spotlight on what’s broken.

For him, the value of Scrum lies in its ability to create transparency, encourage inspection, and drive real, often painful, change—not in wrapping organizations in agile labels or surface-level rituals.

Jeff Sutherland, on the other hand, tends to present Scrum with more emphasis on speed, performance, and success.

In his book Scrum: The Art of Doing Twice the Work in Half the Time, the tone is more upbeat and results-focused. Sutherland highlights how Scrum can lead to high-velocity teams, fast learning cycles, and breakthrough outcomes.

While he also acknowledges the need for discipline and accountability, his approach leans more on the benefits of Scrum when it’s working well, rather than the turmoil of getting there. It’s a more optimistic take, often aimed at energizing teams and executives to adopt Scrum for competitive advantage.

The core difference lies in tone and focus. Schwaber is the realist—he sees Scrum as a mechanism to challenge an organization to grow up. Sutherland is the idealist—he shows what’s possible when Scrum is embraced deeply and used to unlock a team’s full potential. Both perspectives are true, and both are valuable.

But if you’re looking for a tough love, no-nonsense guide that holds up a mirror to your company’s behavior, Schwaber’s lens offers a raw, unfiltered look at what Scrum really demands.

Chapter by Chapter

Chapter 1 – The Way the World Works Is Broken

A Massive Failure at the FBI

The book opens with the dramatic collapse of a major FBI project—Sentinel. After a decade of effort and hundreds of millions spent, the system meant to modernize the FBI’s operations was failing. The problem wasn’t the people or even the technology. It was how they worked. Endless planning, inflexible contracts, and rigid project structures created a bureaucratic nightmare. Jeff Johnson, brought in to fix it, realized the only way forward was to throw it all out and try something radically different.

The Illusion of Planning

One of the biggest culprits behind these failures was the reliance on traditional project planning tools—like Gantt charts. They look impressive, with colorful bars and dependencies mapped out, but in reality, they’re always wrong. Teams spend so much time updating charts and trying to stick to a plan that doesn’t reflect what’s actually happening. The author compares it to the Soviet Union’s fake reports before its collapse—beautiful on paper, but meaningless in practice.

A New Way of Thinking: Scrum

Scrum was born as a reaction to this madness. Instead of rigid plans, Scrum uses short cycles of work—called Sprints—where teams deliver working results, inspect their progress, and adapt based on what they’ve learned. It’s about learning fast, adjusting often, and focusing on delivering real value. This idea isn’t new—studies since WWII have pointed to better ways of working—but Scrum pulls it all together in a clear, practical framework.

Fixing Sentinel with Scrum

When the Sentinel project was handed over to Johnson’s smaller, internal team, they used Scrum to rethink everything. They prioritized what actually mattered, dropped the 1,100-item requirement list, and focused on what would create the most value. By working in two-week Sprints, demonstrating real progress regularly, and focusing on team performance and flow, they delivered the impossible. What once seemed doomed was deployed across the FBI in just 20 months—faster, cheaper, and better.

Prioritization and Value First

A key shift in mindset was learning to say no to unnecessary features. Sutherland highlights a common rule: 80% of a product’s value comes from 20% of its features. By forcing teams to ask, “What brings the most value?” they naturally start with the most impactful work and often realize that the rest doesn’t matter as much as they thought.

Velocity and Continuous Improvement

Scrum also introduces the idea of velocity—how fast a team can deliver valuable work. Instead of guessing deadlines upfront, Scrum lets the team’s actual progress guide planning. Each Sprint becomes a chance to improve, identify what’s slowing them down, and remove obstacles. Johnson focused on clearing these “impediments,” inspired by Toyota’s concept of “flow”—the idea that work should move smoothly, without waste or blockage.

Transparency and Trust

One of the most powerful elements in Scrum is the regular demo. Every two weeks, the team showed working software to stakeholders—from agents to the FBI Director. These weren’t slide decks or status reports—they were live, functioning results. This transparency built trust, even among skeptics who thought the basement team would fail again.

Changing the Culture

The real change wasn’t just in process—it was cultural. The Sentinel team didn’t just work differently; they thought differently. They were aligned, focused on results, and committed to continuous improvement. On their wall hung the Agile principles and a pig-shaped bell, representing commitment. They weren’t just involved—they were all in.

Scrum Beyond Software

Sutherland closes the chapter by pointing out that Scrum isn’t just for IT or the FBI. It’s being used to solve real-world problems—from healthcare to education to crime. Even failures like Healthcare.gov could have been avoided if teams had used Scrum to deliver working software incrementally instead of waiting until the end to find out it didn’t work.

This chapter challenges the way most people think about work. It calls out the waste, the overplanning, and the blind faith in outdated methods. Scrum isn’t just a tool—it’s a mindset. It invites us to think differently, prioritize value, and embrace constant learning. And in today’s world, that difference can mean success—or failure.

Chapter 2 – The Origins of Scrum

From Fighter Pilot to Framework Builder

Jeff Sutherland opens this chapter with a gripping memory from his days as a U.S. Air Force fighter pilot in Vietnam. His missions were high-risk and intense, and he learned something crucial in those moments of life-or-death decision-making: Observe, Orient, Decide, Act. That four-step cycle, drilled into him during combat training, later became one of the core ideas behind Scrum. It taught him how to act with clarity and speed in chaotic environments—and that same principle would guide how teams could work better under pressure.

Seeing Organizations Like Living Systems

After the war, Sutherland moved into academia, studying statistics and biometrics. Through his cancer research, he became fascinated with how complex adaptive systems—like cells—change from one state to another. He noticed something profound: teams and organizations behave like these systems. With the right energy and small shifts, they could be nudged from dysfunction into health. But first, you had to inject change, let go of control, and allow a new state to form.

Escaping the Waterfall

His first leap into corporate life was at a company struggling with a mess of late and over-budget projects. Everything was built using the Waterfall method—plan everything upfront, stick to the script, and hope it works. But it didn’t. So he asked for something bold: to run a separate, fully autonomous unit, where they could do things differently. They created their own structure, focused on team-based success, and started testing new ideas like Product Owners, Sprints, and Backlogs—concepts that would later become Scrum.

In just six months, they went from failure to profitability. They flipped the model from individual rewards to team ownership. That shift made a huge difference—and it stuck with him.

Lessons from a Six-Legged Robot

One of the most fun and unexpected sources of inspiration came from a robot. While working near MIT, Sutherland met Rodney Brooks, an AI professor whose six-legged robot would regularly escape into Jeff’s office. But this robot wasn’t pre-programmed—it learned to walk from scratch every time it was turned on, using a few simple rules. Each leg had its own “brain,” coordinating with the others. That decentralized learning approach sparked a question in Sutherland’s mind: what if people could work like that—autonomously, yet in sync?

The Birth of Scrum

The turning point came at Easel, where Sutherland was asked to lead a project with a tight six-month deadline. He knew the old ways wouldn’t work, so he searched for something new. That’s when a team member found a paper by Japanese professors Takeuchi and Nonaka: “The New New Product Development Game.” It described teams that were cross-functional, autonomous, empowered, and driven by a higher purpose—and it used the metaphor of a rugby “scrum” to explain how they worked.

Inspired, Sutherland and his team adopted those principles, experimented with them, and delivered the product on time, under budget, and with higher quality than ever before. That was the moment Scrum was truly born.

Why Scrum Works

The real magic of Scrum comes from its Inspect and Adapt cycle—borrowed from Japanese manufacturing and American statistician W. Edwards Deming. It’s a loop: plan what you’ll do, do it, check if it worked, and adjust. Repeat. In Scrum, teams go through short bursts of work (Sprints), learn quickly, and improve constantly. The goal is never perfection—it’s continuous improvement.

Sutherland even trains people using paper airplanes. They go through rapid PDCA cycles (Plan, Do, Check, Act), and within minutes, they see real improvement. The lesson is clear: working in short cycles, with real feedback, always beats long, rigid plans.

Change or Die

This chapter doesn’t shy away from tough truths. Sutherland shares how he warned engineers at BellSouth that their perfect execution of the Waterfall method was leading to products no one wanted—because the world had moved on while they were still building. His message? Change or die. And indeed, BellSouth is no longer around.

Scrum as a Practice—and a Path

To wrap up, Sutherland reflects on Scrum not just as a method, but as a craft. He draws from his own aikido training and the Japanese concept of Shu Ha Ri—three levels of mastery. First, you follow the rules (Shu). Then, once you’ve internalized them, you innovate (Ha). Eventually, you let go of the forms altogether and work with fluid mastery (Ri). That’s what great Scrum looks like—effortless collaboration that seems almost magical, but is grounded in deep, practiced skill.

This chapter isn’t just about where Scrum came from—it’s about the mindset behind it. A mindset that values learning, flexibility, and real human collaboration. And that mindset, Sutherland argues, is what we need more than ever.

Chapter 3 – Teams

Why Teams Matter More Than Individuals

Jeff Sutherland opens the chapter with a strong statement: teams are what get things done in the world—not individuals. Yet, most companies still focus their performance systems around individual rewards, promotions, and metrics. It might seem intuitive to hire the best individuals to get the best results, but the data tells a different story.

A programming course at Yale showed that while some students completed assignments ten times faster than others, their grades were nearly identical. That’s impressive on its own—but it gets more interesting. When researchers looked at team performance across thousands of projects, the gap between the best and worst teams wasn’t 10x—it was 2,000x. That means improving team performance is way more powerful than obsessing over individual talent.

The Magic of Great Teams

We’ve all seen—or been part of—teams where everything just flows. Sutherland compares them to legendary sports teams like the ’80s Celtics or the Patriots in the Brady era. It’s not just talent. It’s alignment, trust, and a shared sense of purpose. He wanted to understand what made those teams great and if it was possible to replicate that magic.

Turns out, yes—it is. Takeuchi and Nonaka, in the paper that inspired Scrum, found that great teams share three traits: transcendence, autonomy, and cross-functionality. They have a higher purpose, self-manage their work, and include all the skills necessary to get the job done. And that’s the recipe Scrum uses.

A Story from West Point

Sutherland shares a personal story from his time as a cadet at West Point. His company, L2—the “Loose Deuce”—had ranked at the bottom for over a century. As training officer, he had no real authority, but he introduced radical transparency by posting visual performance charts. No blame, just visibility.

Slowly, the team improved. They reached the top of the rankings and ended up being selected to bury General MacArthur. What changed wasn’t skill—it was clarity, purpose, and self-motivation. That sense of pride and alignment made all the difference. His company had achieved transcendence.

Autonomy in Action: NPR in Cairo

In a completely different context, Sutherland shares how his son J.J. applied Scrum principles during the Egyptian revolution. NPR was scrambling to cover the rapidly unfolding events, and traditional coordination from headquarters wasn’t working. J.J. stepped in—not to manage—but to support the team.

Using Scrum-style check-ins (“What did you do? What will you do? What’s in your way?”), they aligned, adapted, and improved. The autonomy given to the reporters—combined with a clear mission—led to award-winning coverage. No top-down control. Just trust, feedback, and purpose.

Cross-Functionality: One Team to Ship the Product

Another key insight is that great teams must be cross-functional. That means having every skill required to get the job done—from planning to building to testing to delivering. Sutherland criticizes old models like NASA’s “phase-gate” process, where work moves from one specialized team to another, often creating delays and errors. The Challenger disaster, for instance, was partly blamed on such a siloed process.

He points to Salesforce.com as a modern example. Agile lead Nicola Dourambeis ensures that teams are diverse in skills and mindset—and that members identify with the product they’re building, not their individual roles. The goal is to build one team that owns the outcome.

Scrum at War: Collaborative Warfare

One of the most powerful examples in this chapter comes from the military. U.S. Special Forces operate in small, cross-trained units that can execute missions end to end. But during the Iraq war, even their elite performance wasn’t enough to create strategic impact—until General McChrystal introduced collaborative warfare. This meant bringing in people from the CIA, FBI, NSA, Treasury, and more—all in the same room, sharing everything in real time.

This shift—essentially forming a mega cross-functional team—allowed them to track and dismantle terrorist networks more effectively. But once the crisis passed, the bureaucracy returned, and the teams were broken up. Sutherland uses this to show how traditional structures often resist transparency and teamwork—because they threaten the status quo and personal power.

Small Teams Are Faster

But size matters. Not bigger—smaller. The ideal team size is seven people, plus or minus two. Once a team gets too big, communication breaks down and velocity slows. This isn’t just theory—it’s backed by research. Larger teams take five times longer to produce the same output as smaller ones. The reason? Human brains can only handle a limited number of relationships and information chunks at once.

Fred Brooks’ famous law says it simply: adding more people to a late project makes it later. And that’s because more people = more communication channels = more complexity. In Scrum, clarity and alignment are crucial, so keeping teams small is key.

The Role of the Scrum Master

To support this system, Scrum introduced a role called the Scrum Master—part coach, part servant leader. Not a manager barking orders, but someone who ensures the team follows the process, removes roadblocks, and helps the team ask the right questions. Sutherland compares it to a coach who guides the team to reflect and continuously improve.

He describes watching rugby videos with his early Scrum team, studying the All Blacks and their pre-game haka. That sense of unity, hunger, and celebration of every teammate’s success became a model for how Scrum teams could behave. The Scrum Master helps nurture that kind of culture.

Stop Blaming People—Fix the System

One of the most powerful parts of the chapter tackles a common workplace habit: blaming individuals. Sutherland calls out the Fundamental Attribution Error—our tendency to explain others’ failures by their personality, but our own by the situation.

He shares chilling psychological studies, like the Milgram experiment, where ordinary people obeyed authority to the point of harming others. The takeaway? It’s not that people are bad—it’s that systems shape behavior. Scrum is designed to fix the system, not punish the people.

He also references how Toyota turned around a failing GM plant (NUMMI) by keeping the same workers but changing the process—and got world-class results. The right system makes all the difference.

Reaching Team Greatness

The chapter ends with a story from a soccer match—one player kicks the ball blindly, trusting a teammate will be there. And they are. That moment of perfect synchronization, of trust and flow, is what Scrum aims to create.

It’s not magic. It’s about setting the right environment, giving teams autonomy, aligning around a purpose, and ensuring they have the tools and trust to succeed. That’s how good teams become great—and how work transforms into something inspiring.

Chapter 4 – Time

Time Is the Most Valuable Resource

Jeff Sutherland begins the chapter with a reminder we all need: time is the one thing we can’t get back. Once it’s gone, it’s gone. That’s why wasting time—at work or in life—is such a crime. Yet, most workplaces are designed in a way that wastes time constantly. People are overworked, unfocused, and awful at estimating how long things will take. But it’s not about being lazy—it’s just how humans are wired.

The Birth of the Sprint

The idea of the Sprint came from an unlikely place: the MIT Media Lab. There, students had to show working demos of their projects every three weeks. If what they built wasn’t functional and cool, it got scrapped. That culture of constant delivery and immediate feedback became the heart of Scrum.

Sutherland applied the same principle at Easel. Instead of long plans and Gantt charts, he promised the CEO that every month he’d deliver real, working software. Something the customer could actually use. Not backend code. Not theory. Actual features. This short, focused, high-energy period of work became what we now call the Sprint.

Building Cars in a Week with Scrum

A great example of Sprints in action is Team WIKISPEED, a group that builds fuel-efficient, street-legal cars. They work in one-week Sprints. Every Thursday, they decide what they’ll do that week. They put tasks on sticky notes, move them across columns (Backlog → Doing → Done), and finish real, usable features—like working turn signals or a modular steering rack.

The rule is clear: nothing moves to “Done” unless it’s usable by the customer. That discipline forces focus, commitment, and constant progress. Their whiteboard becomes a visual heartbeat of the team. Everyone can see what’s happening and jump in to help.

The Power of Time Boxes

Sprints work because they are time-boxed—set periods where the team commits to finishing certain tasks, and nothing can be added mid-Sprint. This rhythm builds trust and predictability. It also prevents distractions and scope creep, which are productivity killers. Scrum lets teams move fast because they stay focused.

Introducing the Daily Stand-Up

To improve even more, Sutherland added another idea: the Daily Stand-Up. It’s a short, 15-minute meeting where each team member answers three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. What’s in your way?

That’s it. No status reports, no manager-led assigning. It’s a fast huddle—more like a football team planning its next play than a boring office meeting. Everyone stands up to keep the energy high and the meeting short. This simple ritual creates alignment, removes blockers, and builds team accountability.

Communication Saturation: The Key to Speed

Why do these meetings work so well? Because they boost what Sutherland calls communication saturation. When everyone knows everything they need to do their job, things move faster. He references a legendary project at Borland Software where a team produced code at record speed. The secret? They had 90% communication saturation—everyone was constantly in sync.

The problem in most workplaces is specialization. People guard their titles and knowledge, which slows down progress. At Easel, Sutherland solved this by removing all titles—no job labels, no hierarchy. Just a team focused on the goal.

Scrum in Space and Construction

Scrum isn’t just for tech. Sutherland describes a rocket company using Scrum to build avionics systems, and a home renovation project that finished on time and on budget because it used Sprints and Stand-ups.

His friend Eelco renovated an entire house in six weeks using Scrum, with contractors checking in daily and working together as a team. A neighbor with the same house and same crew—but no Scrum—took three months. Same people, same tools, wildly different results.

Why Scrum Changes How You Think About Time

After using Scrum for a while, people start to see time differently. It becomes cyclical rather than linear. Each Sprint becomes a cycle of progress. Each Stand-up becomes a chance to course-correct. This shift changes your mindset—from feeling overwhelmed by huge projects to seeing constant opportunities to improve.

Sutherland closes the chapter with a challenge: do you want to suck forever? Because staying stuck is a choice. He wants teams that push each other, get excited about progress, and come out of meetings saying, “Let’s do this.”

Chapter 5 – Waste Is a Crime

We Crave Rhythm—but Often the Wrong Kind

Jeff Sutherland starts this chapter by reflecting on how deeply humans are drawn to rhythm. We seek patterns in everything. But while rhythm can lead to positive habits, it can also trap us in toxic routines—like feeling stuck at work, being treated like a cog in a machine, or going through the motions in systems that don’t care about people. Scrum, he argues, creates a new kind of rhythm—one that supports energy, focus, and pride in what we do. But to fully benefit from it, we have to confront one of the biggest enemies of progress: waste.

The Hidden Cost of Wasted Work

Sutherland shares the story of a man who spent a year developing textbooks—only to find that half of it was scrapped. Not because it was bad, but because priorities had changed. It felt like a waste of his life—and that’s not unusual. According to Sutherland, when he walks into most companies, he sees that around 85% of work is waste. Only a fraction of what people do actually creates value. And instead of seeing that as a tragedy, we joke about it. But really, he says, we should mourn it.

Three Kinds of Waste: Muri, Mura, and Muda

Drawing from the Toyota Production System, Sutherland introduces three Japanese terms that describe different types of waste:

  • Muri: Waste caused by unreasonableness—pushing people beyond what’s sustainable.
  • Mura: Waste caused by inconsistency or unevenness in work.
  • Muda: Waste caused by doing things that don’t add value.

Scrum, much like Deming’s PDCA (Plan, Do, Check, Act) cycle, is built to reduce all three types. It’s not just about going faster—it’s about going smarter.

Multitasking Is a Lie

A big chunk of this chapter dives into a familiar workplace myth: multitasking. We love to brag about juggling five things at once, but Sutherland uses science to tear that idea apart. Studies show that multitasking makes us slower, more error-prone, and dumber. People who think they’re great multitaskers are usually the worst at it. Context-switching—moving from one task to another—burns mental energy and causes delays. In fact, if you work on five projects at once, you lose up to 75% of your time to switching costs. You’re busy, but not productive.

Half-Done Work Is Worthless

Another major source of waste? Starting too many things and finishing none. Sutherland compares it to a “honey-do” list at home—if everything is half-finished, nothing gets done. Painting one wall, writing a check but not mailing it, buying dog food but leaving it in the trunk—it’s all work with no value. In Scrum, “Done” means truly done—usable, shippable, complete. Anything less is just inventory. In manufacturing or software, having half-built products or features ties up resources without delivering any benefit.

Fix Mistakes Immediately

If you do make a mistake, fix it right away. That’s another lesson Scrum takes from Toyota. Sutherland shares data from Palm, where fixing a software bug on the same day it’s created takes one hour. Wait three weeks, and it takes 24 hours. Why? Because your brain has already moved on. You forget the context, lose the mental model, and have to relearn everything. The longer you delay fixing problems, the more painful—and expensive—it becomes.

Working More Doesn’t Mean Getting More Done

Sutherland also challenges another dangerous assumption: that working longer hours equals better results. Research shows it’s the opposite. People hit peak productivity just below 40 hours per week. After that, performance drops, mistakes increase, and decisions get worse. He shares the story of a venture firm, OpenView, that adopted Scrum across the whole company. When they cut back on work hours, productivity and quality went up. The CEO even told employees that working late was a sign of poor planning, not dedication.

Decision Fatigue Is Real

One of the most fascinating insights in this chapter comes from a study of Israeli judges. The study found that judges were much more likely to grant parole after a snack or lunch break. As the day went on and decision fatigue set in, they defaulted to “no” more often. The takeaway? Our ability to make good decisions is limited, and the more tired or overloaded we are, the worse those decisions become. Breaks aren’t lazy—they’re essential to thinking clearly.

The Danger of “Heroic” Work

Sutherland warns against celebrating heroics—those last-minute, late-night sprints to save a project. While they may seem admirable, they’re actually signs of a broken system. A team that relies on constant emergencies isn’t managing work well—it’s just surviving. Real success comes from steady, sustainable effort and continuous improvement—not adrenaline-fueled chaos.

Don’t Be Unreasonable—or an Asshole

Scrum also calls out other common wastes: absurd goals, unrealistic expectations, and unnecessary bureaucracy. All of these fall under the idea of Muri—pushing people too hard, with too little reason. And one type of waste Sutherland adds himself: emotional waste, often caused by toxic people. Assholes, as he bluntly puts it, kill teams. They create fear, chaos, and burnout. A single bad actor can derail an entire group. So don’t tolerate that behavior—not in yourself or in others.

Flow: The Ideal State

In the end, Scrum isn’t just about eliminating waste—it’s about finding flow. That effortless state where work feels smooth, focused, and satisfying. Just like a martial artist or a dancer, great teams move in sync, without wasted energy or distraction. But flow only comes with discipline—cutting the clutter, focusing on what matters, and finishing what you start.

Chapter 6 – Plan Reality, Not Fantasy

The Problem with Planning

The chapter kicks off with a story about Medco, a massive pharmaceutical company that promised Wall Street they’d launch a new system by a specific date—without actually asking the teams how long it would take. That decision created chaos. They had old systems, unclear requirements, and a deadline they were guaranteed to miss. The mistake? They fell in love with the plan—beautiful, detailed documents that looked great on charts, but had little to do with reality.

Jeff Sutherland makes this point loud and clear: the map is not the terrain. Plans are guesses. When we try to plan everything up front, we end up building fantasy timelines, not real ones. And that fantasy leads to waste, stress, and failure.

Cut the Paper, Stick to Reality

When Sutherland got involved with Medco, the first thing he and his team did was call all stakeholders into a room and ask for printed documents—no emails, just paper. The pile was over two feet tall. Then, using scissors and sticky notes, they cut out every item that was actual work. Everything else—boilerplate, duplications, legal fluff—was tossed. They discovered that over half the “plan” was just noise.

Once everything was on the wall in sticky notes, they could finally see what really needed to be done. Each note had a description and, importantly, a “Definition of Done”—what it meant for that task to be complete, including compliance and quality checks. That alone drastically reduced rework later.

Prioritize by Value

Next came prioritization. The team debated what to do first, asking: what delivers the most value right now? Not everything was urgent, even if it felt that way. This simple act—sorting work by value—helped the team move from being stuck to taking action.

To explain this further, Sutherland uses the example of planning a wedding. Everyone has a long list of tasks, but not all are equally important. If the goal is to have a great wedding and you’re running out of time or money, you need to know which parts you can cut without hurting the experience. That’s what business projects often forget.

We Suck at Estimating—But That’s Okay

Humans are famously bad at estimating time and effort. That’s where the Cone of Uncertainty comes in—a concept that shows how early estimates can be off by 400% in either direction. Even months into a project, estimates are still often way off.

But there’s a better way: estimate using relative sizing. Instead of guessing exact hours, teams compare tasks using categories like dog breeds, T-shirt sizes, or Fibonacci numbers. For example, if a task feels like a “bulldog” and another one’s a “Great Dane,” you’re not saying exactly how long each will take—you’re just comparing sizes. This removes the pressure to be perfectly accurate and gives a more realistic picture of effort.

Avoid Bias with Group Estimation

To keep things honest, Sutherland introduces techniques like the Delphi method, where people give estimates anonymously, reducing bias from loud voices or “halo effects.” But when speed is needed, Planning Poker is the go-to method. Everyone uses cards with Fibonacci numbers, estimates the size of the task, and flips their card at the same time. Big disagreements trigger discussion and another round. This creates fast, fair estimates with shared understanding.

Only the Team Knows the Real Work

One major lesson from a failed experiment at GSI Commerce is this: only the team doing the work should estimate it. When outside “experts” tried estimating for multiple teams, nothing was delivered on time. But when teams took control of their own planning again, estimates became realistic and deadlines were met.

Each team is unique. They know their strengths, challenges, and rhythm. Trying to fit every team into the same plan or expectation is a guaranteed path to disappointment.

Tasks Are Not Just Tasks—They’re Stories

Instead of assigning abstract tasks, Scrum uses User Stories: short narratives that explain who wants something, what they want, and why they want it. This format—“As a [user], I want [something], so that [goal]”—grounds work in real people and real needs. It avoids miscommunication and helps teams understand the bigger picture.

Stories can be small and specific or grouped into larger Epics, which represent broader goals. The key is keeping them testable, valuable, and small enough to complete within a Sprint.

Be Ready. Be Done.

Two key concepts in Scrum are “Definition of Ready” and “Definition of Done.”

A story is only ready if it meets the INVEST criteria:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

And “Done” means it meets all quality, compliance, and value requirements. When teams start using these definitions, Sutherland says speed can double—twice.

Sprint Planning and Velocity

During each Sprint Planning meeting, the team selects a set of stories to complete. Based on past Sprints, they know their velocity—how many story points they typically complete in a Sprint. By adding up the remaining story points, they can predict when they’ll be done. This also reveals what’s slowing them down, helping teams continuously improve.

A Real Turnaround at Medco

Back at Medco, the team’s initial velocity was slow. But as they removed impediments—bureaucracy, bad processes, missing people—they jumped from 20 points to 60 per Sprint. Then to 90. Still, they weren’t going to hit the July deadline.

So they asked three questions:

  1. What can we do differently?
  2. Can we offload any work?
  3. Can we reduce scope?

With creative thinking, smarter decisions, and management support, they found ways to trim and accelerate. Eventually, they hit the promised date. The company’s stock soared. Confidence grew. And the culture started changing.

Culture Is the Real Victory

Sutherland ends by highlighting the deeper win: Scrum changed the culture at Medco. It shifted the focus from paperwork and status to value and delivery. It empowered teams to speak up, ask questions, and challenge norms. And most importantly, it helped people see that change is possible—even in big, complex organizations.

Chapter 7 – Happiness

Happiness Comes from the Pursuit

Jeff Sutherland opens this chapter with a story that hits deep: a mountain climber soloing Everest near sunset, knowing he might not make it down alive, still felt deeply fulfilled. That moment of extreme challenge gave him joy—not the summit itself, but the struggle. This is the kind of happiness Scrum aims to create: not surface-level comfort, but purpose-driven, active joy that comes from progress and challenge.

We’re Wired to Find Joy in the Journey

Modern society tends to reward results, not effort. But most of life is lived in the effort. If we only find satisfaction at the finish line, we spend most of our lives unhappy. This is a problem in many workplaces, where people are only praised after hitting arbitrary targets. Scrum turns that around—it focuses on continuous improvement and joy in the process, not just at the end.

Sutherland shares how he had to unlearn his rigid fighter-pilot mindset when he built his first Scrum team. He realized emotional well-being mattered just as much as technical skill. Joy wasn’t a fluffy extra—it was the fuel for great performance.

Happy Teams Outperform Everyone

The data is clear: happiness drives success—not the other way around. Studies show that happy people are more productive, better at selling, more creative, healthier, and live longer. One major meta-analysis confirmed that happiness consistently precedes success in careers, relationships, and life in general. And the cool part? Even small increases in happiness lead to better outcomes. You don’t need a complete life overhaul—just small wins, repeated consistently.

So… Measure It

Sutherland isn’t just about feel-good stories—he wants hard data. So he developed the Happiness Metric, a simple way to track joy and use it to drive improvement. At the end of each Sprint, each team member answers:

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

The team then identifies a top improvement and makes that their kaizen—the #1 thing to fix or improve in the next Sprint. They don’t just talk about it—they define success criteria so it’s measurable. That small step leads to compounding gains.

Sutherland shares how using this tool helped his team at Scrum, Inc. triple their productivity in just a few weeks. It wasn’t by working harder. It was by continuously listening to what made people happier—and fixing it, Sprint by Sprint.

Happiness Predicts the Future

What makes the Happiness Metric powerful is that it’s forward-looking. Financial metrics tell you what already happened. But happiness gives early warning signs. If happiness dips, productivity usually follows. If you address emotional roadblocks early, you can avoid performance issues altogether. It’s like seeing storm clouds before the rain.

What Really Makes People Happy

The three key drivers of happiness at work are:

  • Autonomy – control over your work
  • Mastery – the feeling you’re getting better
  • Purpose – knowing your work matters

Scrum creates the conditions for all three. But it starts with transparency—making everything visible. When everyone knows what’s being worked on, why it matters, and how progress is going, people feel included and empowered.

Sutherland recalls how introducing transparency at PatientKeeper scared developers at first. They thought it would be used against them. But he made a promise: it would only be used to make things better. And it worked. Productivity increased fourfold, and the company released software faster and more reliably than anyone else in the industry.

The Danger of Hiding Information

Transparency in Scrum isn’t just about tasks—it includes salaries, finances, roadmaps, and more. Sutherland argues that secrecy slows teams down, breeds mistrust, and infantilizes employees. People can only contribute meaningfully if they understand how the business works.

A Scrum board—a simple whiteboard with sticky notes—becomes a symbol of this transparency. Everyone can see what’s To Do, Doing, and Done. It creates accountability, fosters collaboration, and helps teams self-regulate.

Case Study: Zappos and the Power of Culture

Zappos is a real-world example of building a business around happiness. From their customer service to how they train new hires, everything is designed to build connection, autonomy, and growth. They even funnel all employees through a bootcamp to immerse them in the culture.

Their success speaks for itself: over a billion dollars in annual sales. Zappos proves that happiness isn’t a distraction—it’s a business strategy.

They also embrace internal mobility and self-directed learning, helping employees explore new paths and build mastery. The culture isn’t soft; it’s intense. But it’s also joyful. As one executive put it: people want to come to work, not because they have to, but because they love to.

Beware the “Happy Bubble”

Sutherland warns about a trap: teams that improve, feel proud, and then stop improving. They hit a plateau and start coasting. He calls this the happy bubble—when joy leads to complacency. The team is doing okay, but they’ve stopped chasing excellence.

To pop the bubble, you need someone who will ask uncomfortable questions—a Wise Fool. Like the child in The Emperor’s New Clothes, they speak up when no one else will. Scrum Masters should be watching for stagnation and use the team’s metrics (like velocity) to challenge the group to keep growing.

Finding Sustainable Joy

Sutherland references Tal Ben-Shahar’s framework to show four types of people at work:

  1. Hedonists – Happy today, don’t care about tomorrow.
  2. Nihilists – Unhappy today, no hope for the future.
  3. Rat Racers – Suffer today hoping to be happy someday.
  4. Thrivers – Happy today and optimistic about tomorrow.

Scrum aims to create Thrivers—people engaged in meaningful work that energizes them now and sets them up for a better future. It systematically removes barriers to joy, encourages learning, and builds better systems that support human potential.

The Pyramid of Human Needs

The chapter closes with Maslow’s hierarchy of needs. Scrum isn’t just about productivity—it’s about helping people move up that pyramid: from survival to safety to love, respect, and self-actualization. When work supports people’s full growth, amazing things happen. Not just for the individual—but for the company too.

Chapter 8 – Priorities

Vision Alone Isn’t Enough

Jeff Sutherland starts with a warning: a great product idea doesn’t guarantee success. He contrasts Zappos, which thrived, with Pets.com, which flopped—even though both had similar visions. The difference? Prioritization. Knowing what to do and when to do it is the game-changer.

Scrum isn’t just about speed—it’s about delivering the right things in the right order. Sutherland emphasizes this through his work with OpenView Venture Partners. Every successful company they backed had one key strength: a ready, prioritized, and sized Backlog. That’s where the real power of Scrum kicks in.

Start with the Backlog

The first practical step in Scrum is building a Backlog—a list of everything that might be needed to deliver your product or service. Not every item will get done, but everything that could be part of the vision should go there. It’s not about immediate action—it’s about capturing possibilities.

For example, a company developing a home automation system created user stories like: “As a homeowner, I want to see who’s at the door so I can let in only people I trust.”

They ended up with hundreds of stories. But here’s the trick: they didn’t try to do it all. They asked: What has the biggest impact? What do customers value most? What’s fastest and lowest-risk to implement? Those went to the top of the list.

Deliver Value Early and Often

Sutherland returns to the 80/20 rule: 80% of a product’s value is in 20% of its features. Scrum focuses on finding and building that 20% first. Instead of waiting months or years to deliver something, teams deliver small, valuable increments constantly.

So instead of aiming for a perfect product from day one, you aim for the most useful slice—what Sutherland calls a Minimum Viable Product (MVP). That MVP might feel incomplete, even rough. But it delivers real value and, more importantly, gives you feedback fast.

The Role of the Product Owner

Enter the Product Owner, one of the three roles in Scrum. The Product Owner doesn’t manage people—they manage the value. They own the Backlog, prioritize the work, and deeply understand what customers actually need.

Sutherland was inspired by Toyota’s Chief Engineers—leaders with no direct authority, but massive influence. They lead not by command but by vision, knowledge, and trust. The Product Owner does the same.

To be effective, a Product Owner needs four key traits:

  1. Domain knowledge – They understand the market and the product deeply.
  2. Empowerment – They can make real decisions without constant approvals.
  3. Availability – They spend time with both the team and the customers.
  4. Accountability for value – They’re judged by results, not effort.

A Product Owner isn’t just a planner. They’re a translator of vision into real, measurable progress.

OODA Loop: Fast Feedback, Fast Success

To explain decision-making speed, Sutherland brings in a brilliant concept from military strategy: the OODA loop—Observe, Orient, Decide, Act. Developed by fighter pilot John Boyd, this cycle explains how the U.S. Air Force outmaneuvered better-equipped enemies.

Scrum puts Product Owners inside the market’s decision loop. They observe real feedback, re-orient the priorities, make new decisions, and guide the team to act—all in real-time. Each Sprint becomes a mini-OODA loop. It’s how teams stay ahead of changes, customers, and competitors.

Incremental Releases Work Everywhere

You might wonder: “But what if my product isn’t something you can release piece by piece?” Sutherland argues you often can—you just need to change how you think. Take Team WIKISPEED: they build and sell road-legal car prototypes weekly. Game developers offer paid early access to alphas. Toyota built the Prius in 15 months using fast prototypes. The point isn’t perfect—it’s progress.

Even if your product can’t go public early, an internal demo to stakeholders or team leaders gives you feedback and direction. You don’t need to wait until it’s finished to learn what works.

Avoid Building the Wrong Thing

One powerful story: U.S. efforts in Iraq spent millions building a chicken-processing plant, assuming that’s what the locals needed. Turns out, they just needed a footbridge to cross the river. A cheap, simple, life-changing fix—missed because no one asked.

Scrum helps avoid this mistake by delivering fast, asking for feedback, and adjusting priorities constantly. It’s not about what sounds impressive—it’s about what people actually value.

Sometimes, Done Means Done

Sometimes you build the MVP, deliver massive value early, and… you’re done. No need to pile on more features. Sutherland gives the example of a beautiful, minimalist alarm clock. The team could’ve added more functions, but the core was already perfect. So they shipped it and moved on.

“Change for Free” Beats Change Control Boards

In traditional contracts, changes mean fees, delays, and red tape. Sutherland proposes a radical idea: “Change for Free.” Instead of punishing change, Scrum welcomes it. You can swap features of equal size at any time. Want to add something? Just drop something of similar effort. This keeps momentum high and lets you adapt to real needs.

He shares a story of a Scrum company that delivered a $10M project in just 3 months. The customer ended the contract early (with a small fee) because they had everything they needed. The customer saved $7M. The company quadrupled their profit margin. Everyone won.

Scrum Reduces Risk

Scrum isn’t just fast—it’s safer. It reduces three major risks:

  • Market Risk – You learn what customers want early, before it’s too late.
  • Technical Risk – You test small parts (like a camera lens) before scaling.
  • Financial Risk – You stop investing in features that won’t pay off.

You don’t need to guess. You test, learn, and decide. The worst-case loss is a few Sprints—not your entire budget or product cycle.

What You Can Do Tomorrow

Sutherland closes the chapter with a clear call: Just start.

Build a Backlog. Run your first Sprint. Create a roadmap. Share progress openly. Start small, move fast, and adjust constantly. Scrum doesn’t need months of prep. It needs a team, a list, and a decision to begin.

Because while others are still planning, you’ll be learning, adapting, and delivering real results.

Chapter 9 – Change the World

Scrum Is Bigger Than Software

Scrum may have started in software development, but Jeff Sutherland makes it clear: its potential goes far beyond that. In this chapter, he shows how the same principles—transparency, prioritization, teamwork, continuous improvement—are transforming schools, fighting poverty, reforming governments, and even reshaping how we think about work itself.

This chapter isn’t just about process. It’s about hope.

Scrum in the Classroom

We begin in the Netherlands, in a small town called Alphen aan den Rijn. There, a teacher named Willy Wijnands brought Scrum into his chemistry classroom. He didn’t stand at the front lecturing. Instead, students organized into small, self-directed teams. They used Scrum boards, sticky notes, burndown charts, and even created their own “Definition of Fun”—a playful addition alongside the usual “Definition of Done.” Trust, humor, and a Dutch word called gezelligheid (a cozy, connected kind of joy) were part of what made school work enjoyable.

In this system, students didn’t just learn chemistry. They learned how to work together, how to plan, estimate, reflect, and lead. The results? Test scores shot up by over 10%, and students who had felt like outsiders began to thrive—including a previously disengaged autistic student who finally found a way to connect.

Wijnands called it eduScrum. It started with one teacher. Now, it’s grown into a movement with its own foundation, spreading across schools and supported by the business community. What started as a small classroom shift is now reshaping how education works.

Scrum in the Fight Against Poverty

Then we go to rural Uganda, where over a third of the population lives on less than $1.25 a day. The Grameen Foundation, inspired by microfinance pioneer Muhammad Yunus, launched a program to empower local farmers. They trained 1,200 Community Knowledge Workers (CKWs) and gave them smartphones loaded with agricultural and market data.

Now, instead of guessing or relying on shady middlemen, farmers could diagnose crop diseases on the spot, learn modern techniques, and find fair prices for their goods. One woman doubled her yield and doubled her profit just by using that information.

Behind the scenes, the tech team developing these tools used Scrum to prioritize what to build next. Every feature was rated on three questions:

  1. Does it help the poor?
  2. Will CKWs use it?
  3. Do we have partners for it?

This clarity allowed them to focus on what truly mattered. They even began applying Scrum to the way they ran the organization—replacing endless meetings with visual boards and actionable steps. What used to be bureaucracy became momentum.

Scrum for Government Reform

Governments are often the slowest to change. But even here, Scrum is making progress. In Washington State, the CIO’s office adopted Scrum to transform how IT projects were delivered. They started small—one improvement a week—but that meant real value, shipped regularly, not buried under endless planning.

They tore down cubicle walls, formed Scrum teams, and focused on making tangible, usable changes every Sprint. There were challenges—like laws that required outdated waterfall methods—but they pushed forward. Their goal wasn’t perfection. It was improvement, week by week.

And in Iceland, after a financial crash devastated the country, citizens demanded a new constitution. A committee used Scrum to write it—publishing one section each week and getting feedback via Facebook and Twitter. The process was open, fast, and people-powered. Though political forces blocked the constitution in the end, the process itself showed what’s possible when the public is truly involved.

How We’ll Work in the Future

The chapter then turns to the future of work—and it’s a wild ride. Sutherland explores Valve, a videogame company that has no managers. Zero. Everyone decides what to work on, forms teams by persuasion, and literally wheels their desks around the office to join projects. It’s self-organization in action.

Valve employees green-light their own projects, decide when something’s ready, and hold each other accountable—not through hierarchy, but through shared ownership. Their employee handbook proudly declares: “You have the power to ship products.” It’s freedom with responsibility—and it works.

Even when the company made a rare misstep—hiring too many people at once who didn’t align with the culture—they course-corrected quickly. They weren’t afraid to admit what didn’t work and try again. That’s Scrum thinking, even if they don’t call it that.

Other companies, like Morning Star (a tomato-processing giant), are also ditching traditional management in favor of peer-to-peer accountability. No job titles. No bosses. Just clear goals, shared responsibility, and open communication.

Scrum Is for the Dreamers Who Act

The final section is deeply reflective. Sutherland calls out the danger of cynicism—the belief that things can’t change. He acknowledges the chaos in the world, from wars to corruption to political failure, and then offers a quiet but powerful counterpoint: Scrum is the code of the anti-cynic.

Scrum doesn’t just hope for a better world—it builds one. Sprint by Sprint. Step by step. It’s used today to deliver vaccines, build houses, catch criminals, end hunger, and even explore other planets. It’s not a fantasy. It’s a plan.

A Better World Isn’t Naïve—It’s Actionable

The last quote in the chapter is from T.E. Lawrence:

“All men dream: but not equally… the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible.”

Scrum, in the end, is a tool for those dreamers. The ones who look at the mess and say, “We can do better.” And then go do it.

4 Key Ideas from Scrum

Sprints

Short, focused work cycles that replace long, exhausting timelines. They bring fast feedback and real progress. Each sprint builds momentum and drives improvement.

Definition of Done

A clear, shared understanding of what “finished” actually means. It avoids miscommunication and hidden rework. Done means done—usable, valuable, and complete.

Prioritized Backlog

Not everything is urgent or important. The backlog is a living list that gets sorted by real value. Teams focus on what matters most, and drop what doesn’t.

Continuous Improvement

Every Sprint ends with reflection and adjustment. Teams constantly ask, “How can we get better?” Improvement isn’t a one-time fix—it’s part of the rhythm.

6 Main Lessons from Scrum

Focus Beats Busy

Doing less can create more value. Prioritize what really matters and stop multitasking. Attention is a superpower—use it wisely.

Plan for Reality

Big plans are just guesses. Learn to adapt as you go. Reality is always changing, so build in flexibility from the start.

Start Small, Learn Fast

You don’t need the full picture to begin. Just take the next step, test it, and adjust. Progress comes from action, not perfection.

Fix the System, Not the Person

People don’t fail—systems do. If something’s not working, change the process. Blame solves nothing; structure solves everything.

Make Happiness Measurable

Happy teams perform better. Ask what makes people excited, motivated, and proud. Then improve it, one Sprint at a time.

Done Is Better Than Perfect

Half-finished work delivers no value. Focus on shipping small, complete results. It’s better to finish something useful than polish something no one needs.

My Book Highlights & Quotes

Planning Is Useful. Blindly Following Plans Is Stupid. It’s just so tempting to draw up endless charts. All the work needed to be done on a massive project laid out for everyone to see—but when detailed plans meet reality, they fall apart. Build into your working method the assumption of change, discovery, and new ideas.

Inspect and Adapt. Every little while, stop doing what you’re doing, review what you’ve done, and see if it’s still what you should be doing and if you can do it better. 

Change or Die. Clinging to the old way of doing things, of command and control and rigid predictability, will bring only failure. In the meantime, the competition that is willing to change will leave you in the dust. 

Fail Fast So You Can Fix Early. Corporate culture often puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users. Work that does not produce real value is madness. Working on the product in short cycles allows early user feedback and you can immediately eliminate what is obviously wasteful effort. 

Hesitation Is Death. Observe, Orient, Decide, Act. Know where you are, assess your options, make a decision, and act!

Look Outward for Answers. Complex adaptive systems follow a few simple rules, which they learn from their environment. 

Great Teams Just Are. They are cross-functional, autonomous, and empowered, with a transcendent purpose. 

Don’t Guess. Plan, Do, Check, Act. Plan what you’re going to do. Do it. Check whether it did what you wanted. Act on that and change how you’re doing things. Repeat in regular cycles, and, by doing so, achieve continuous improvement.

Shu Ha Ri. First, learn the rules and the forms, and once you’ve mastered them, make innovations. Finally, in a heightened state of mastery, discard the forms and just be—with all the learning internalized and decisions made almost unconsciously. 

Pull the Right Lever. Change Team performance. That has much more impact—by several orders of magnitude—than individual performance. 

Autonomy. Give teams the freedom to make decisions on how to take action —to be respected as masters of their craft. The ability to improvise will make all the difference, whether the unit is reporting on a revolution in the Middle East or making a sale. 

Cross-functional. The team must have every skill needed to complete a project, whether the mission is to deliver Salesforce.com software or capture terrorists in Iraq. 

Small Wins. Small teams get work done faster than big teams. The rule of thumb is seven team members—plus or minus two. Err on the small side. 

Blame Is Stupid. Don’t look for bad people; look for bad systems—ones that incentivize bad behavior and reward poor performance. 

Time Is Finite. Treat It That Way. Break down your work into what can be accomplished in a regular, set, short period—optimally one to four weeks. And if you’ve caught the Scrum fever, call it a Sprint. 

Demo or Die. At the end of each Sprint, have something that’s done— something that can be used (to fly, drive, whatever). 

Throw Away Your Business Cards. Titles are specialized status markers. Be known for what you do, not how you’re referred to. 

Everyone Knows Everything. Communication saturation accelerates work. 

One Meeting a Day. When it comes to team check-ins, once a day is enough. Get together for fifteen minutes at the Daily Stand-up, see what can be done to increase speed, and do it. 

Multitasking Makes You Stupid. Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong—it does. 

Half-Done Is Not Done. A half-built car simply ties up resources that could be used to create value or save money. Anything that’s “in process” costs money and energy without delivering anything. 

Do It Right the First Time. When you make a mistake, fix it right away. Stop everything else and address it. Fixing it later can take you more than twenty times longer than if you fix it now. 

Working Too Hard Only Makes More Work. Working long hours doesn’t get more done; it gets less done. Working too many results in fatigue, which leads to errors, which leads to having to fix the thing you just finished. Rather than work late or on the weekends, work weekdays only at a sustainable pace. And take a vacation.

Don’t Be Unreasonable. Goals that are challenging are motivators; goals that are impossible are just depressing. 

No Heroics. If you need a hero to get things done, you have a problem. Heroic effort should be viewed as a failure of planning.

Enough with the Stupid Policies. Any policy that seems ridiculous likely is. Stupid forms, stupid meetings, stupid approvals, and stupid standards are just that—stupid. If your office seems like a Dilbert cartoon, fix it. 

No Assholes. Don’t be one, and don’t allow the behavior. Anyone who causes emotional chaos inspires fear or dread or demeans or diminishes people needs to be stopped cold. 

Strive for Flow. Choose the smoothest, most trouble-free way to get things done. Scrum is about enabling the most flow possible 

The Map Is Not the Terrain. Don’t fall in love with your plan. It’s almost certainly wrong. 

Only Plan What You Need To. Don’t try to project everything out years in advance. Just plan enough to keep your teams busy. 

What Kind of Dog Is It? Don’t estimate in absolute terms like hours—it’s been proven that humans are terrible at that. Size things relatively, by what breed of dog the problem is, or T-shirt size (S, M, L, XL, XXL), or, more commonly, the Fibonacci sequence. 

Ask the Oracle. Use a blind technique, like the Delphi method, to avoid anchoring biases such as the halo effect or bandwagon effect, or just plain stupid groupthink. 

Plan with Poker. Use Planning Poker to quickly estimate work that needs to be done.

Work Is a Story. Think first about who’ll be getting value from something, then about what it is, and then why they need it. Humans think in narratives, so give them one. As an X, I want Y, so that Z. 

Know Your Velocity. Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down. 

Velocity × Time = Delivery. Once you know how fast you’re going, you’ll know how soon you’ll get there. 

Set Audacious Goals. With Scrum, it is not that hard to double production or cut delivery time in half. If you do it in the right way, your revenue and stock price should double as well. 

It’s the Journey, Not the Destination. True happiness is found in the process, not the result. Often we only reward results, but what we really want to reward is people striving toward greatness. 

Happy Is the New Black. It helps you make smarter decisions. Plus, when you’re happy, you’re more creative, less likely to leave your job, and more likely to accomplish far more than you ever anticipated. 

Quantify Happiness. It’s not enough just to feel good; you need to measure that feeling and compare it to actual performance. Other metrics look backward. Happiness is a future-looking metric. 

Get Better Every Day—and Measure It. At the end of each Sprint, the team should pick one small improvement, or kaizen, that will make them happier. And that should become the most important thing they’ll accomplish in the next Sprint. 

Secrecy Is Poison. Nothing should be secret. Everyone should know everything, and that includes salaries and financials. Obfuscation only serves people who serve themselves. 

Make Work Visible. Have a board that shows all the work that needs to be done, what is being worked on, and what is actually done. Everyone should see it, and everyone should update it every day. 

Happiness Is Autonomy, Mastery, and Purpose. Everyone wants to control their own destiny, get better at what they do, and serve a purpose greater than themselves. 

Pop the Happy Bubble. Don’t get so happy that you start believing your own bullshit. Make sure happiness is measured against performance, and if there is a disconnect, be prepared to act. Complacency is the enemy of success.

Make a List. Check It Twice. Create a list of everything that could possibly be done on a project. Then prioritize it. Put the items with the highest value and lowest risk at the top of that Backlog, then the next, and then the next. 

A Leader Isn’t a Boss. A Product Owner sets out what needs to be done and why. How the team accomplishes it and who accomplishes it is up to the team. 

Observe, Orient, Decide, Act (OODA). See the whole strategic picture, but act tactically and quickly. 

Fear, Uncertainty, and Doubt. It’s better to give than to receive. Get inside your competition’s OODA loop and wrap them up in their own confusion. 

Get Your Money for Nothing and Your Change for Free. Create new things only as long as those new things deliver value. Be willing to swap them out for things that require equal effort. What in the beginning you thought you needed is never what is actually needed. 

ScrumAccelerates All Human Endeavors. The type of project or problem doesn’t matter—Scrum can be used in any endeavor to improve performance and results. 

Scrum for Schools. In the Netherlands, a growing number of teachers are using Scrum to teach high school. They see an almost immediate improvement in test scores of more than 10 percent. And they’re engaging all sorts of students, from vocational to gifted. 

Scrum for Poverty. In Uganda, the Grameen Foundation is using Scrum to deliver agricultural and market data to poor rural farmers. The result: double the yield and double the revenue for some of the poorest people on the planet. 

Rip Up Your Business Cards. Get rid of all titles, all managers, all structures. Give people the freedom to do what they think best and the responsibility to be accountable for it. You’ll be surprised at the results 

Conclusion

Scrum isn’t just a tool—it’s a new way to think about work, goals, and collaboration. It’s about breaking free from rigid plans, useless meetings, and invisible progress. Instead, you get a system where work feels lighter, faster, and more human.

The ideas in this book aren’t stuck in theory—they’re already being used to teach kids, fight poverty, and rebuild broken teams. And the best part? You don’t need permission to start using them. Just try one Sprint—and see what happens.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

Navigate between the many topics covered in this website:

Agile Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: