The Evolution of Agile: From the Manifesto to Modern Agile and the Scaling Debate

Version note: This post is based on sources published as of November 2026: modernagile.org, Alistair Cockburn's Heart of Agile writing, the 2018 update of the Agile Fluency Model, SAFe 6.0 on framework.scaledagile.com, less.works, Scrum.org's Nexus guide and Henrik Kniberg's 2015 note on the Spotify model.

Guess First

Bookstore has grown: six teams, about 45 people, one product. Teams wait for each other, sprint reviews have turned into six separate meetings, and getting a feature to production requires three teams to finish the same work in the same sprint. Management has found a solution: a scaling framework will be bought, consultants will come, and "enterprise agility" will be achieved within a quarter.

Guess: will buying the framework solve the waiting problem between teams? Or is the problem, whichever framework is chosen, in how the teams are split?

After 2001: The World That Grew Around the Manifesto

After the Snowbird meeting, the Agile Alliance was founded as a non-profit organization at the end of 2001 and, with its annual conferences, became the meeting point of the Agile community. The following twenty-five years brought two movements in opposite directions. On one side Agile became institutionalized: the market for certifications, frameworks, tools and consulting grew. On the other, as a reaction to that growth, simplification proposals appeared that tried to return to the essence of the manifesto.

In this period two big currents merged with Agile. The DevOps movement that started in 2009 extended the development loop Agile had shortened all the way to production; that story is in the fifth post of the SDLC (Software Development Life Cycle) series. Scrum published its first official Scrum Guide in 2010; the Guide was updated in 2011, 2013, 2016, 2017 and 2020, and in June 2025 Ralph Jocham, John Coleman and Jeff Sutherland released the Scrum Guide Expansion Pack as an optional companion. That evolution of Scrum is the subject of the last post of the Scrum series.

The Simplification Wave: Heart of Agile and Modern Agile

Around 2015-2016, Alistair Cockburn, one of the authors of the manifesto, introduced Heart of Agile, which reduces Agile to four words: Collaborate, Deliver, Reflect, Improve. The idea is to make visible again the essence lost under frameworks and certifications: work together, deliver in small pieces, look at the results, improve. According to Cockburn, each can be explored in more depth, but the starting point is these four words.

At the Agile conference in 2016 Joshua Kerievsky presented Modern Agile with four guiding principles: Make People Awesome, Make Safety a Prerequisite, Experiment & Learn Rapidly and Deliver Value Continuously. Modern Agile's most visible difference from the manifesto is that it makes psychological safety an explicit prerequisite, and puts making people awesome, both users and the team, at the center instead of "customer satisfaction".

Dave Thomas's "agility" proposal, which we saw in the fourth post of the series, is part of the same wave. What the three have in common is describing Agile as a set of habits rather than a process package.

The Agile Fluency Model: A Choice, Not Maturity

The Agile Fluency Model, published by James Shore and Diana Larsen in 2012 and substantially updated in 2018, groups the benefits teams expect from Agile into four zones. A team in the Focusing zone makes its work visible in terms of business value and adapts quickly when redirected. A team in the Delivering zone can release frequently, whenever it wants, with a low defect rate. A team in the Optimizing zone makes its own product decisions and changes direction as it learns from the market. The Strengthening zone is about what teams learn being reflected in how the organization makes decisions.

The model's most important emphasis is that it is not a maturity model. Each zone is a complete and valid choice on its own; a team can consciously choose to stay in Focusing. Each zone also has a price: Delivering requires the team to accept being temporarily slower while it gains skills and to bring testing and operations skills into the team; Optimizing requires the organization to give the team business expertise and real decision-making authority. Management saying "all of you be Optimizing" is asking for the result of that zone without making its investment.

The Scaling Debate

It is clear that Agile was designed for small teams; the manifesto says nothing about scale. For situations where more than one team works on the same product, several frameworks came to the fore in the 2010s.

SAFe (Scaled Agile Framework) was developed by Dean Leffingwell; its first version came out in 2011, and framework.scaledagile.com still shows SAFe 6.0, introduced in March 2023, as the current version. SAFe groups multiple teams under an ART (Agile Release Train), and these teams plan together at regular intervals. It is a comprehensive framework that defines roles, events and artifacts from the team up to the portfolio. Its criticism comes from that same scope: many roles and layers, a top-down way of adoption, and a tight link with the consulting ecosystem Fowler calls the "Agile Industrial Complex".

LeSS (Large-Scale Scrum) grew out of the work of Craig Larman and Bas Vodde. Basic LeSS is designed for 2-8 teams, LeSS Huge for more than eight. Its approach is the opposite of SAFe's: instead of adding new roles and layers, simplify the organization. One product, one Product Owner, one Product Backlog, and teams that build features end to end. Its criticism is that it demands deep structural change in the organization; for many organizations that is much harder than buying a framework.

Nexus was introduced by Ken Schwaber and Scrum.org in 2015 and adds a thin layer on top of Scrum for 3-9 Scrum teams working on the same product. Its most visible addition is the Nexus Integration Team, responsible for integration problems between teams. Its approach is faithful to Scrum and light; its criticism is that it doesn't address needs outside Scrum, such as portfolio management.

The "Spotify model", on the other hand, is not actually a framework. In 2012 Henrik Kniberg and Anders Ivarsson published a paper describing Spotify's organization at the time with the concepts of squads, tribes, chapters and guilds. In a 2015 note Kniberg wrote that it was not designed as a generic framework or model, only as an example of how one company worked at a particular moment. Joakim Sundén, an Agile coach who worked at Spotify, also said in 2020 that the model was no longer practiced at Spotify. Copying a company's snapshot doesn't mean copying the culture and the practice of experimentation that produced it.

Buying a Framework Is Not Becoming Agile

Let's go back to the question at the start. Bookstore's six teams wait for each other because the teams are split by layer: a frontend team, two backend teams, a database team, a test team and a platform team. Every feature has to pass through three teams. Whichever scaling framework is chosen, the need for coordination doesn't go away in this structure; the framework only adds meetings and roles to manage that coordination.

A more effective first step is to reorganize the teams so they can build features end to end: a checkout team, a catalog team, an orders and returns team. This is LeSS's feature team idea and the main theme of the Introduction to Architecture series post "Conway's Law: How Team Structure Shapes Architecture": team structure and architecture shape each other. If coordination between teams is still needed after reducing dependencies, a light layer like Nexus or a comprehensive framework like SAFe can be considered then.

A Short Self-Check for Your Team

These questions, inspired by the zones of the Agile Fluency Model, are not an assessment tool but a conversation starter inside the team. Answer each question as a team with "yes", "partly" or "no":

• Focusing: Can the team say which business value each piece of its work serves, and can it change direction within a week when priorities change?
• Focusing: Does the team show its work to the business side at regular intervals and reflect the feedback it gets in its plan?
• Delivering: Is the main branch releasable at any moment, and is getting to production done through a single automated pipeline?
• Delivering: Is the number of bugs found in production low enough not to disrupt the team's plans?
• Optimizing: Can the team decide for itself which feature to build by looking at user data?
• Strengthening: Is what the team learns reflected in other teams and in how the organization works?

The answers are a starting point for discussing which zone's investment is worth making. A team that answers "no" to the Delivering questions needs basic engineering practices such as CI (Continuous Integration), test automation and a deployment pipeline before a scaling framework; their counterpart is the XP (Extreme Programming) practices in the third post of the series.

Production Notes

Simplify before you scale. Put the dependencies between teams into a table: which team waits for which team, and how often? If most dependencies come from team boundaries drawn in the wrong place, the solution is reorganization, not a coordination layer.

If a framework is going to be chosen, start it as an experiment. In a single product area, with a measurable goal (for example halving change lead time) and a fixed evaluation date. Rolling the framework out to the whole organization at once is the exact opposite of the small-step loop Dave Thomas describes.

Let the team choose its fluency zone. Management's role is to make the investment for the zone the team chose: time, training, authority.

Common Pitfalls

Confusing buying a framework with becoming Agile is the most common pitfall. Setting up the framework's roles and events without changing team structure and engineering practices is the scaled version of the cargo cult from the fourth post of the series.

The second is copying another company's model. Spotify's 2012 snapshot was a transitional state even for Spotify itself.

The third is using the Agile Fluency Model as a maturity ladder and ranking teams by their zones. The model explicitly rejects this.

The fourth is turning the simplification proposals into new frameworks of their own. Heart of Agile's four words are not a process; turning them into a certified program as well would repeat what they were reacting to.

A Small Experiment

★☆☆ Take the four words of Heart of Agile (Collaborate, Deliver, Reflect, Improve) and find an example of each in your team's last sprint. For which one was it hard to find an example?

★★☆ Fill in the self-check list together with your team. On which question did your answers differ most, and why?

★★★ Put the dependencies between teams in your organization into a table: in each row the waiting team, the team waited on, and how many times it waited in the last month. Would you propose a team structure that halves the dependencies, or is a coordination framework needed?

The Agile Mindset series ends here: the manifesto's four values, the 12 principles, XP's engineering practices, common myths, friction with the real world and the evolution from 2001 to today. To see how these values turn into a way of working in an everyday team, the next step is the Scrum and Kanban series; both build the "how" on top of the "why" laid out here.