In 1993 a West Point-educated fighter pilot and cancer researcher looked at how software was built and concluded that the entire industry was doing it wrong. The framework he and Ken Schwaber invented is now used by the majority of software teams in the world — and by organisations in fields its creators never anticipated.

The Central Argument


The way most teams work is broken — and most teams know it and do nothing.


The opening of Scrum is an indictment dressed as an observation. In the mid-2000s, the FBI embarked on its most ambitious technology modernisation project — the Sentinel programme, intended to replace a paper-based case management system that FBI agents had been using since the 1990s. The programme had been running for three years, spent $170 million, and delivered nothing. Not a system that was partially functional or suboptimal — nothing. When an audit concluded that completing Sentinel under the existing approach would require another six years and $350 million, the FBI pulled the project and tried something different. A team using Scrum completed the remaining work in twelve months, for $20 million. The full Sentinel system went live in 2012.


Sutherland uses the FBI story not as a sales pitch but as a diagnostic. The failure was not caused by incompetent people or insufficient funding. It was caused by a specific and almost universal approach to complex work that Sutherland calls the "waterfall" method: plan everything upfront, break it into sequential phases, hand work from one specialised team to another, measure progress by comparing what was done to what was planned, and discover at the end — when it is too late to change anything — whether the plan was right. In complex environments where requirements change, technology evolves, and user needs are understood more clearly as work proceeds, this approach produces the inevitable result that the FBI experienced: a perfect plan for a problem that no longer existed, executed by people who had been prevented from adapting.


The Scrum alternative is built around a different premise: in complex environments, you cannot plan your way to the right outcome. You can only work your way there — in short iterations, with constant feedback, adapting as you learn. The sprint — typically two weeks of focused work culminating in a demonstrable result — is not a convenience. It is a theory of how knowledge is produced in complex systems: you learn more about what you need to build by building something and showing it to people than by discussing it in meetings for months before anything exists.


"Waterfall assumes you can know in advance what you don't know yet. Scrum assumes you can't — and builds the learning process into the work itself."

JEFF SUTHERLAND — SCRUM


The productivity claim in the subtitle — twice the work in half the time — is not presented as a guarantee but as the documented result across multiple contexts where Sutherland and his collaborators have measured the difference between Scrum teams and waterfall teams working on comparable problems. The gains come not from working harder but from eliminating the specific categories of waste that conventional project management builds into the process: the waste of multi-tasking, the waste of sequential hand-offs, the waste of long planning cycles, and the waste of discovering problems late rather than early. Eliminating waste is where the time goes. The work itself takes roughly the same effort. The surrounding structure of how that work is organised is where the efficiency is won or lost.

The Origin Story


A fighter pilot, a cancer researcher, and a rugby metaphor that changed how the world builds things.


Jeff Sutherland's background is more eclectic than most management book authors. He graduated from West Point in 1964, flew combat missions in Vietnam in an RF-4C Phantom, earned a master's degree in statistics from Stanford, became a professor of mathematics at the Air Force Academy, then shifted to medicine — a PhD, a professorship of radiology and preventive medicine at the University of Colorado, co-founding the Center for Vitamins and Cancer Research with two-time Nobel laureate Linus Pauling. After that, software. He was VP of Engineering, CTO, or CEO at eleven technology companies over the following two decades.


The intellectual foundations of Scrum are drawn from this unusual range of experience. From his fighter pilot training, Sutherland took the OODA loop — the Observe, Orient, Decide, Act cycle developed by Air Force colonel John Boyd, which argues that in any competitive environment the party that cycles through observation and adaptation faster has the decisive advantage. From his cancer research, he took an understanding of how complex adaptive systems work — how cells and organisms respond to their environment through constant small adjustments rather than predetermined programmes. From the Toyota Production System, developed by Taiichi Ohno, he took the concept of flow and the systematic elimination of waste: the insight that most of the time a piece of work spends in a production system is not being worked on but waiting, and that the primary job of a production system is to maximise the ratio of value-adding time to waiting time.


The sources that shaped the Scrum framework


Scrum was not invented in a vacuum. The framework synthesises ideas from several distinct traditions — each contributing a specific element to the overall architecture. Understanding where each element came from helps clarify why it is there and what it is designed to produce.


  • Takeuchi and Nonaka (1986): The name "Scrum" itself comes from a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka titled "The New New Product Development Game," which studied how the most successful product development teams operated — specifically noting the superiority of cross-functional, overlapping, and self-directing team structures over the conventional sequential relay approach. Sutherland took both the name and the structural insight directly from this paper.


  • John Boyd's OODA Loop: The fighter pilot doctrine of continuous rapid cycling — Observe, Orient, Decide, Act — is the operational model for the sprint. Each sprint is an OODA cycle: observe the current state of the work, orient to what has changed and what has been learned, decide what to do in the next cycle, act. The team that completes this cycle faster than its competitors — or its own past performance — wins.


  • Toyota Production System / Kanban: Taiichi Ohno's systematic elimination of the seven forms of waste (overproduction, waiting, transportation, overprocessing, inventory, motion, and defects) provided the waste-identification framework that explains most of Scrum's specific design choices. The Daily Standup, for example, is a direct response to the waste of waiting: it ensures that impediments are identified daily rather than allowed to block work undetected for days or weeks.


The formal co-creation of Scrum began at Easel Corporation in 1993, where Sutherland worked with John Scumniotales and Jeff McKenna to build the first Scrum team. He then partnered with Ken Schwaber, who had developed similar ideas at Advanced Development Methods, and together they presented Scrum at the OOPSLA Conference in 1995 — the first public formal presentation of the framework. In 2001, Sutherland and Schwaber were among the seventeen signatories of the Agile Manifesto, the founding document of the agile software development movement. Today, Sutherland's son J.J. Sutherland leads Scrum Inc., and the framework is used by an estimated 66% of all agile teams globally.

THe Framework


Three numbers that contain everything Scrum is made of.


The Scrum framework is intentionally minimal. It defines exactly three roles, five events, and three artifacts — and nothing more. This minimalism is deliberate: Scrum is a framework for producing work, not a methodology that prescribes how the work itself is done. The rules are simple enough to fit in a document shorter than this section. The practice of operating within them well enough to produce the framework's promised results is considerably more complex.


  • 3 Roles:
  • Product Owner
  • Scrum Master
  • Developers


  • 5 Events:
  • The Sprint
  • Spring Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective


  • 3 Artifacts:
  • Product Backlog
  • Spring Backlog
  • Increment


The three pillars that hold the framework together — and that must be present for the framework to function — are Transparency (everyone can see the current state of the work), Inspection (the work and the way work is being done are regularly and honestly examined), and Adaptation (when inspection reveals that the work is not proceeding as expected, the plan is changed). Remove any one of the three and the framework breaks down: without transparency, inspection is impossible; without inspection, adaptation is blind; without adaptation, the sprint cycle is merely a reporting format rather than a learning system.

The Three Roles


Three accountabilities, one team — and why the distinctions matter.


One of the most common mistakes in Scrum implementation is blurring or combining the three roles. Each role has a specific accountability that the others do not share, and the combination or confusion of roles produces predictable and well-documented failure modes. The Product Owner who also acts as Scrum Master has a conflict of interest that undermines both accountabilities. The Scrum Master who assigns tasks has become a project manager and has stopped being a Scrum Master. The team that allows the Product Owner to decide how work is done has lost its self-organisation and its ability to estimate.


(Role 1) Product Owner — The What and the Why


The Product Owner is accountable for maximising the value of the work the team produces. They own the Product Backlog — the ordered list of everything the product needs — and are solely responsible for its prioritisation. They are the voice of the stakeholder and the customer, translating business and user needs into a prioritised sequence of work. They decide what gets built in what order. They do not decide how the work is done — that is the team's responsibility. The Product Owner is the person who will be held accountable for whether the product succeeds; they bear the commercial and strategic risk of the decisions they make about priority. Crucially, this accountability cannot be delegated to a committee: one person must have the authority to make the final call on what is most important, or the backlog becomes a negotiation rather than a strategy.


(Role 2) Scrum Master — The How and the Health


The Scrum Master is accountable for the effectiveness of the Scrum process. They are not a project manager, not a team lead, and not a representative of management. They are a servant-leader whose specific job is to ensure the framework is understood and practiced correctly, to facilitate the Scrum events, and to identify and remove the impediments that prevent the team from working effectively. The Scrum Master protects the team from external interruptions and organisational dysfunction. They coach the team on Scrum theory and practice, and coach the organisation on working with a Scrum team. The role is most commonly mis-implemented when it is combined with the Product Owner role (creating a conflict between what to build and how to build it) or when the Scrum Master begins directing the team's work rather than facilitating the team's self-organisation.


(Role 3) Developers — The How and the Doing


The Developers — in the 2020 Scrum Guide update, no longer called the "Development Team" — are the people who do the work of creating the product increment each sprint. They are cross-functional: together they have all the skills required to complete the work without external dependencies. They are self-organising: they decide how to do the work the Product Owner has prioritised. They own the Sprint Backlog — the plan for the sprint — and are accountable for creating a working increment that meets the Definition of Done by the end of each sprint. The team should ideally be between three and ten people. Smaller than three and there is insufficient diversity of skill and perspective for meaningful self-organisation. Larger than ten and communication overhead begins to reduce rather than enhance the team's effectiveness.

The Five Events


The spring cycle  — what happens in what order, and why each event exists.


The five events of Scrum are not meetings that happen around the work. They are the structure of the work itself — the recurring pattern of action and reflection that produces both the output (the increment) and the learning (the team's improving capacity to produce future increments). The most common implementation failure is treating the events as procedural overhead — the standup that becomes a status report, the retrospective that gets cancelled when the team is busy, the sprint review that is a presentation rather than a working session. Each event has a specific purpose that is undermined by each of these adaptations.


  • (Container) The Sprint: 1–4 weeks, fixed length. All other events happen inside it. No changes that endanger the Sprint Goal. Quality standards never decrease. One Sprint ends; the next begins immediately. The Sprint is the heartbeat of Scrum.


  • (Start of Sprint) Sprint Planning: Up to 8 hrs for a 4-week sprint. Three questions: Why is this sprint valuable? What can be done? How will the work be done? Output: the Sprint Backlog and a Sprint Goal. Team decides how much to take on — not the Product Owner.


  • (Every Day) Daily Scrum: 15 minutes. Stand up. Three questions: What did I do yesterday? What will I do today? Is anything blocking me? Not a status report for a manager — a coordination event for the team. Inspect and adapt the Sprint Backlog daily.


  • (End of Spirit) Sprint Review: Up to 4 hrs for a 4-week sprint. Show working product to stakeholders. Get feedback. The Product Backlog may be adjusted. Not a presentation — a working session. Only completed work is shown. "Almost done" is not done.


  • (After Review) Retrospective: Up to 3 hrs for a 4-week sprint. Inspect the team, process, and tools. What went well? What could improve? What do we commit to changing? The most skipped event. Also the primary mechanism for continuous improvement. Non-optional.


The retrospective deserves specific attention because it is simultaneously the most important event for long-term performance and the one most frequently eliminated when teams are under pressure. The argument for skipping it is always the same: we are too busy to have a retrospective right now. Sutherland's response is equally consistent: the purpose of the retrospective is to make the next sprint faster and less wasteful. The team that is too busy to have a retrospective is demonstrating precisely why it needs one — it is consuming time on process problems that a retrospective would have identified and fixed. The retrospective is not a reward for a good sprint. It is the mechanism that makes good sprints possible.


"If you are too busy to improve how you work, you will never have time to improve how you work. The retrospective is how you get faster. Skipping it is how you stay slow."

JEFF SUTHERLAND — SCRUM
The Three Artifacts


What the team tracks, how they know where they are, and what "done" actually means.


Each artifact makes the work and its progress visible to everyone — the team, the Product Owner, and the stakeholders. Each artifact has a specific commitment that makes its purpose concrete and prevents the artifact from becoming a formality. The commitments are the most important addition in the 2020 revision of the Scrum Guide: they clarify that these documents are not administrative records but the primary instruments of transparency, inspection, and adaptation.


Product Backlog — Commitment: Product Goal


The ordered list of everything the product might need. Managed and prioritised solely by the Product Owner. Never complete — it evolves as the product and its users are better understood. Items at the top are more specific and smaller; items further down are larger and less defined. The Product Backlog is the single source of truth for what the team will work on. It is constantly being refined: items are broken down, re-estimated, re-prioritised, and occasionally removed as new information changes what matters. The commitment — the Product Goal — is the long-term objective that gives the backlog coherence and provides the team with a direction beyond the current sprint.


Sprint Backlog — Commitment: Sprint Goal


The plan for the current sprint: the Sprint Goal, the Product Backlog items selected for the sprint, and the plan for delivering them. Created by the Developers during Sprint Planning. Belongs exclusively to the Developers — only they can change it during the sprint. It is a living document: updated daily as the team learns what the work actually requires. The Sprint Goal is the single objective for the sprint — the specific value it will produce. A Sprint Backlog without a Sprint Goal is a to-do list. With one, it is a commitment to a specific outcome that gives the team the flexibility to negotiate scope while maintaining direction.


Increment — Commitment: Definition of Done


The sum of all completed Product Backlog items during the sprint plus the value of all previous sprints — a step toward the Product Goal. An Increment must be usable and meet the Definition of Done. The Definition of Done is the formal description of what "complete" means: the specific quality standards and criteria that must be met for any work to count as finished. Without a clear, shared Definition of Done, teams have perpetually incomplete work, and "almost done" becomes a permanent state. The Definition of Done is the single most commonly missing element in teams that struggle to ship working product reliably at the end of each sprint.

What Scrum Is Against


The specific forms of waste that conventional project management bakes in by design.


Sutherland's critique of conventional project management is not general — it is specific. The book identifies particular failure patterns that appear so consistently across organisations and industries that they can be treated as structural features of the conventional approach rather than unfortunate coincidences. Understanding these failure patterns is the prerequisite for understanding why Scrum's specific design choices exist.


The specific inefficiencies that the Spring cycle is designed to eliminate


  • Multitasking — Research consistently shows that task-switching reduces cognitive performance significantly — Sutherland cites studies showing that switching between tasks reduces effective output by 20% for two tasks, 40% for three, and continues degrading beyond that. Conventional project management routinely assigns people to multiple concurrent projects. Scrum assigns people to one sprint commitment at a time, protecting the focus that complex cognitive work requires.


  • Unrealistic Planning — The psychological phenomenon known as the planning fallacy — the persistent tendency to underestimate the time, cost, and difficulty of future tasks — produces project plans that fail consistently and reliably. Story points and velocity-based estimation in Scrum are designed to address this by grounding estimation in the team's actual demonstrated capacity rather than in optimistic projections about what the team should theoretically be able to achieve.


  • Sequential Hand-Offs — The waterfall model passes work from one specialised function to another in sequence: design to development to testing to deployment. Each hand-off introduces delay, information loss, and the inability to use what is learned in later stages to improve work done in earlier ones. The cross-functional Scrum team eliminates hand-offs by having all required capabilities present in the same team at the same time.


  • Long Feedback Cycles — In a waterfall project, the first time a user encounters the product is often after months or years of development. By then, the original requirements have changed, the technology landscape has evolved, and the team has made thousands of decisions based on assumptions about what users wanted — many of which are wrong. The sprint review at the end of each two-week sprint compresses this feedback cycle from months to weeks, enabling the kind of continuous course correction that complex product development requires.


  • Heroism Culture — Conventional project management, when behind schedule, responds by demanding that individual contributors work longer hours — the "crunch" that the games industry pioneered and that has spread to most knowledge work sectors. Sutherland's research on sustainable pace suggests that teams working at a sustainable rhythm consistently outperform teams that alternate between regular work and crunch, because fatigue compounds over time and cognitive performance degrades in ways that accumulate across a project's duration.


  • Status Meetings Instead of Working Demos — The conventional project status report — a slide deck showing percentage completion, budget spent, and projected completion date — tells stakeholders almost nothing about the actual state of the product. It tells them about the state of the plan. The Sprint Review, by contrast, shows a working product increment that stakeholders can actually use or evaluate. The gap between these two things is often larger than any status report would suggest.


  • Unresolved Impediments — Every team has impediments — things that slow the work, create friction, require workarounds. Conventional project management surfaces these in weekly status meetings, by which point they have been blocking progress for days. The Daily Standup's specific question — "Is anything blocking me?" — creates a daily obligation to surface impediments and a daily opportunity to address them. The Scrum Master's specific accountability for removing impediments ensures that surfaced problems are acted upon rather than noted and deferred.
Honest Assessment


What Scrum does brilliantly, where it shows its limits, and what the book overstates.


Five genuine limitations worth understanding before implementing


  • The book's productivity claims are larger than the reproducible evidence — The claim that Scrum teams produce results "twice as fast" or at "1,200% productivity gains" is drawn from specific case studies and cherry-picked implementations rather than from rigorous controlled comparisons. Teams that implement Scrum well typically do outperform comparable waterfall teams on speed and quality measures. The magnitude of that outperformance depends heavily on what the team was doing before, how well Scrum is implemented, and how suitable the work is for iterative delivery. The headline numbers in the book are real examples, not average outcomes.


  • Scrum works best for complex work where requirements evolve — and less well for work that doesn't fit this description — For genuinely simple, well-understood, repetitive work, Scrum introduces overhead without providing the adaptive benefits that justify it. For work with very long-cycle feedback (scientific research, hardware development with physical prototyping constraints, regulatory processes), the two-week sprint model requires significant adaptation. Sutherland presents Scrum as a universal approach in the book's final chapters; the practitioner literature is more nuanced about contexts where other approaches (Kanban, Waterfall, or hybrid models) are more appropriate.


  • The cultural change required is underestimated — Scrum's design assumes a specific kind of organisation: one where cross-functional teams have genuine autonomy over how they do their work, where Product Owners have real authority to prioritise without committee interference, and where leaders are willing to manage by outcome rather than by activity. Most organisations that attempt to implement Scrum without addressing these underlying cultural requirements end up with "Scrum in name" — the meetings and titles without the self-organisation and transparency that make them functional. The book acknowledges that this is a real problem but underestimates how common and how stubborn it is.


  • The transition from software to non-software context requires more work than the book suggests — Sutherland devotes chapters to Scrum outside software — the FBI, poverty reduction, construction, education, personal productivity. The principles transfer. The specific mechanics require careful translation. What is the "increment" in a creative project? What is the "Definition of Done" for a photography commission or a brand strategy document? What is the appropriate sprint length for work that does not produce shippable output every two weeks? The book tends to make these translations look easier than they are in practice.


  • The book is evangelism as much as education — Sutherland is the co-creator of Scrum and the founder of Scrum Inc., and his enthusiastic advocacy for the framework occasionally crowds out honest engagement with its limitations. The research literature on agile methods is more mixed than the book implies — several large-scale studies have found that the relationship between agile implementation and project outcomes is more complicated and more context-dependent than Sutherland's case studies suggest. This does not mean Scrum doesn't work. It means that the conditions under which it works best are more specific than "everything, everywhere, always."


The honest summary: Scrum is one of the most practically useful frameworks for managing complex, evolving work that has ever been developed and documented. Its core insights — short iterations, working demos, cross-functional teams, transparent backlogs, and the retrospective as the engine of continuous improvement — are supported by substantial real-world evidence and coherent theory. The framework is more powerful in software and product development than in many adjacent contexts, and more powerful in genuinely complex environments than in routine ones. The book is the most accessible entry point to the framework and is better read as an argument for a set of principles than as a precise implementation guide.

For Your Studio


The Scrum questions worth asking in a creative business context.


  1. What is the equivalent of a two-week sprint for your studio — and what would "done" look like at the end of it? — The sprint's value lies not in its length but in its rhythm: a fixed period with a defined goal, ending with a demonstrable result and a structured reflection. For a creative studio, this might be a two-week client project cycle, a monthly iteration on an ongoing campaign, or a four-week cycle through a defined phase of a larger project. The question that unlocks the translation is: what could we produce in this period that would be genuinely evaluable by the people it is being made for? The answer defines both the sprint and the review. If nothing evaluable can be produced in two weeks, the sprint may need to be longer. If something can be shown every week, it probably should be.
  2. Does your studio have a Product Backlog — and is one person genuinely responsible for its prioritisation? — The Product Backlog for a creative business is the ordered list of work that matters most to the business's development: the projects in progress, the business development activities, the capability-building investments, the infrastructure improvements. Most studios have a version of this somewhere — a to-do list, a Notion database, a project management board — but few have someone with genuine authority to decide its order. The chaos that results when everyone has implicit authority to reprioritise, or when the list grows without ever being pruned, is the characteristic studio equivalent of the backlog problem. One person — typically the owner — needs to own the sequence. Everyone else should trust that sequence unless they have new information that changes what matters most.
  3. What would a fifteen-minute Daily Standup tell you that you don't currently know — and what would you do with it? — The daily standup is the most easily adopted Scrum practice and the one most commonly done poorly. The value is not in the format — three questions, fifteen minutes, standing up — but in the daily surfacing of two things: the specific commitment for today and the specific obstacle blocking it. For a studio of two or three people, this might be a daily message rather than a physical meeting. For a larger team, the standing format and the fifteen-minute limit are worth maintaining because they prevent the standup from becoming a status meeting and keep the focus on coordination rather than reporting. The test: is someone acting on the obstacles that are surfaced, the same day they are surfaced?
  4. When did you last show a client genuinely unfinished work for feedback — and what did you learn from it? — The Sprint Review's core insight — that showing working work to the people it is being made for, before it is finished, produces better outcomes than presenting completed work for approval — is one of the most transferable ideas in the book for creative businesses. Most creative professionals show clients polished work rather than in-progress work because the vulnerability of sharing something unfinished feels professionally risky. Sutherland's argument is that this risk is smaller than the risk of discovering at the end that the direction was wrong. The client who sees three rough directions at 40% done and says "none of these" has saved you from producing a perfect version of the wrong thing.
  5. Is your studio having retrospectives — and are they producing actual changes to how you work? — The retrospective is the most underused tool in creative studio management. Most studios have some equivalent of a post-project review — an informal conversation about what went well and what didn't — but few treat this with the seriousness and regularity that Scrum prescribes. The question is not whether you are having the conversation but whether the conversation is producing commitments that change the next project's execution. A retrospective that produces good conversation and no changed behaviour is a therapy session. A retrospective that produces one specific changed practice — a new brief format, a different approval process, a changed timing for when concepts are shown — is a Scrum retrospective. The one change per retrospective, applied consistently, is how the studio improves.
  6. What is your studio's Definition of Done — and does everyone share it? — The Definition of Done is the single concept from Scrum most immediately applicable to the specific failure mode of creative businesses: the perpetually incomplete deliverable. "Almost done" is a chronic condition in creative work because the definition of done is often implicit, individual, and inconsistent — different people on the team have different standards for when something is ready to show, ready to deliver, or ready to bill. Making the Definition of Done explicit — "work is done when it has been reviewed by the creative director, exported in all required formats, delivered to the client's specified channel, and a project summary has been filed" — converts "almost done" from a permanent state into a trackable binary. Either the work meets the definition or it doesn't. If it doesn't, the work is not done.