Innovation Deliver

Agile, Scrum, and SAFe

Agile, Scrum, and SAFe are iterative ways of building software and digital products, from a single-team practice to a scaled system.

The questionWhen a client says it wants to go agile, which constraint is it trying to remove, and what is the smallest structure that removes it?

SAFe stands for Scaled Agile Framework.

Process · Manifesto authors, Schwaber, Sutherland, Leffingwell, 1995 to 2011

Agile Values and principles, no set meetings or roles
Scrum A framework for one team, in Sprints
SAFe A framework for coordinating many teams

Simplified view of the three things people mean by agile.

When to use it

A client says we need to go agile and cannot say what problem that would solve.
A product team ships late and has high rework because requirements change after delivery has started.
Several teams depend on each other's work, releases keep colliding, and someone has proposed a coordination structure.
Daily meetings and sprints are running but nothing about how decisions get made has changed.

When to avoid it

The work is repeatable and well understood, such as a maintenance rota or a fixed-scope compliance deliverable. Flow-based work management or plain project management fits better.
A contract or regulation fixes scope and approval gates, and nobody with authority will change either. Teams can work iteratively inside the gates, but do not promise the client adaptiveness.
The client wants SAFe because a large company should have a scaled framework, and no single team yet delivers well on its own. Scaling the problem will not remove it.
The unresolved question is what to build and whether anyone wants it. Use Lean Startup or Design Thinking first.

Overview

“Agile” covers three different things: the values of the 2001 Agile Manifesto, a team-level framework called Scrum, and a scaled framework for coordinating many teams, of which SAFe is the best known. A consultant uses this page when a client asks for agile, to find out which of the three it wants and whether that is the right fix for its delivery problem.

The common failure is adopting the vocabulary and meetings without changing who decides priorities, budgets, and scope. A team can run sprints and still wait weeks for approvals. SAFe in particular is criticized as heavy and process-centered, so introduce it only for dependencies you have observed across teams, not because the organization is large.

Three things people mean by agile

Agile

A set of values and principles, not a method. The 2001 manifesto favors people and conversation over process and tools, working software over thick documentation, collaboration with the customer over contract terms, and responding to change over holding to a plan. Its authors say the items they rank lower still have value. The twelve principles add early and frequent delivery, daily work between business people and developers, motivated teams, a sustainable pace, and regular reflection. It prescribes no meetings or roles.

Scrum

A framework for one team, defined in the Scrum Guide. Work happens in Sprints of one month or less. A Scrum Team has a Product Owner, who is accountable for the value of the product and for the Product Backlog, a Scrum Master, who is accountable for the team's effectiveness and for Scrum being understood, and Developers, who build a usable increment each Sprint. Its events are Sprint Planning, the Daily Scrum, the Sprint Review with stakeholders, and the Sprint Retrospective.

SAFe

A framework from Scaled Agile, Inc. for coordinating many teams. Teams are grouped into long-lived units that plan together on a shared cadence, and further layers handle large solutions and portfolio-level funding. Critics find it heavy and centered on process, and say it brings back planning and approval layers that agile teams were meant to shed. Many adopters take its roles and events without changing who decides priorities and budgets.

What it is not

A synonym for Scrum or for two-week sprints. Scrum is one framework consistent with the manifesto's values, and others, such as Kanban, exist.
A rule against planning or documentation. The manifesto says the items it ranks lower still have value, and Scrum plans every Sprint and keeps a backlog.
SAFe as Scrum with more teams. SAFe adds planning, budgeting, and governance structures that Scrum does not have.

The steps

Ask what agile would fix

Get the client to describe the problem in terms of a recent delivery that went badly, not in terms of a framework. Listen for which of the three it means. Output: a one-sentence problem statement and the examples behind it.
Trace where work waits

Take a handful of recent items from idea to use and mark the time spent working against the time spent waiting. Note which decisions are holding the work: approvals, shared environments, handoffs, or sign-off on requirements. That is the constraint.
Choose the smallest structure that addresses it

Often this is a cross-functional team with one person who sets priorities, short cycles, and a working increment reviewed with users. Scrum is one way to run that. Decide which decisions move to the team and from whom, and stop if no decision rights move.
Set the inspection cadence

Decide when working output is shown to real users, when the team reviews its own process, and who has the authority to remove the impediments that come up. Put leaders in the review. Output: a calendar, named attendees, and an owner for each impediment.
Decide whether scale is needed

Only after teams deliver on their own, map the dependencies between them. If they are few, a light sync will do. If they are many and persistent, consider a scaled framework such as SAFe, and take from it what addresses the dependencies you observed, not all of it.

In practice

The CIO's brief was one sentence: move the digital division of about two hundred people to SAFe by January. The consultant began with the delays instead. She took ten recent late releases and traced each from request to launch, marking the days when someone was working and the days when the work was waiting.

The waiting had two causes. Every change to scope went to a monthly steering committee, and two teams shared one test environment that was booked weeks ahead. Neither was a problem that a scaled framework would solve. The recommendation was to set up three cross-functional product teams on Scrum, give each product owner authority to reorder priorities within an agreed budget, and fix the test environments. Coordination across the teams would be reviewed after two quarters, once their real dependencies had shown up.

What you leave with

A one-sentence statement of the problem agile is meant to solve, with recent delivery examples behind it.
A map of where work waits and which decisions cause the waiting.
The chosen team structure, the decisions each role now owns, and the decisions that moved from elsewhere.
A review and retrospective cadence with named attendees and an owner for impediments.
A scale decision, with the dependency evidence behind it.

Failure points

Ceremonies without decision rights

The meetings, backlog, and sprints are installed, but the product owner cannot change priority because the budget was set for the year. The team's cycle gets shorter while the queue in front of it stays the same length.

A product owner in name only

The role goes to a committee or to a part-time proxy. Developers wait for answers, and the backlog becomes a list of stakeholder requests that nobody ranks.

Velocity as a target

Velocity is a team's own planning tool. Once management compares or rewards it across teams, estimates inflate and the number stops meaning anything.

Scaling before one team works

SAFe is rolled out across the organization to fix dependencies with structure. The training and the new roles absorb the budget, and the original constraint is untouched.

Retrospectives that cannot change anything

The team identifies impediments, but the people who could remove them are not in the room and are not asked. After a few cycles the team stops raising problems.

The failures above are usually Leverage & IP: it was used once, and nothing was left that makes the next engagement easier.

Origin

Seventeen software practitioners wrote the Manifesto for Agile Software Development in 2001. Ken Schwaber and Jeff Sutherland were among them. It has four value statements and twelve principles, and its authors permit it to be copied freely only in its entirety. Scrum predates it. Schwaber used an early form in the early 1990s, Sutherland and colleagues developed something similar at another company, and the two presented Scrum at the OOPSLA conference in 1995. The name comes from a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka, which compared product development to a rugby team. Schwaber and Sutherland maintain the Scrum Guide. The current version is dated November 2020, and it replaced the word roles with accountabilities and the Development Team with Developers.

SAFe, the Scaled Agile Framework, was created by Dean Leffingwell and is published by Scaled Agile, Inc., which also sells training and certification. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc., and its content and diagrams are copyrighted and need permission to modify. It has gone through several major versions and offers configurations of different sizes. This note describes it at a high level only and does not reproduce its diagrams.