The birth of the manifesto

Recently, Per-Magnus Skoogh (co-founder of Agile Extreme) invited me to meet Arie van Bennekum. Arie is one of the co-authors of the Agile Manifesto that was written by 17 independent thinkers in February of 2001 at a ski resort in Utah, USA. 

What these people all had in common was their growing frustration with the way software was being developed. That’s why they came together to see if they could find some common ground on how to change that. The result was the Agile Manifesto, a set of 12 guiding principles for software development.

Agile as an umbrella

One key takeaway from meeting with Arie, and that we both agreed on, was that Agile is not a method. Instead it’s an umbrella term or mindset under which all agile methods can be grouped. That’s why Arie talks about being “Agile agnostic”. The Agile method or methods that your team chooses is less important than being disciplined in sticking to the underlying principles of Agile.

Agile coaches who religiously follow only one method, e.g. Scrum, XP, FDD, or DSDM, while launching one-sided critiques on other methods, such as ASD, Crystal or LSD, are limiting themselves and others.

What has happened since the manifesto?

Since that meeting in 2001, Agile ways of working have come a long way, and so has the field of innovation. A few examples are: 

  • In 2003 Clayton Christensen first introduced the term “Jobs-To-Be-Done” (JTBD) in his book The Innovator’s Solution
  • In 2005 Steve Blank published The Four Steps to the Epiphany where he introduces the concept of “customer development”. 
  • In 2010 Alexander Osterwalder and Yves Pigneur published Business Model Generation
  • In 2011 Eric Ries published The Lean Startup

Parallel to this we have also seen:

  • Design Thinking gaining widespread popularity within the business community with pioneers such as Tim Brown of IDEO and Thomas Lockwood of DMI having paved the way.
  • Outcome-Driven Innovation (ODI), pioneered by Tony Ulwick of Strategyn, and which heavily influenced Clayton in his own thinking around JTBD, has also begun to see more widespread adoption. 

The backlog is what has happened

So, what does all this mean? 

With the risk of oversimplifying, us old “agilists” that began working with defined agile methods in the mid 1990’s must admit one thing. We did not spend too much time trying to figure out how to build business-friendly backlogs (the job-to-be-done). We just assumed that the product owner and her magic would create wonderful products by picking things right out of her head.

Well, that was not, many times, good enough. The business and product owners were not always able to define the perfect product backlog – more help was needed. And … voilà – along came the lean startup, business modeling, and much more. These approaches help us figure out what should be in the backlog, and to verify faster if the assumptions that we are making are correct.


Re-examining the manifesto

Altogether, JTBD/ODI, Lean Startup, Business Modeling, and Design Thinking have started to merge, or at least borrow concepts and ways of working from each other. And that’s good – that’s the way it’s supposed to be. 

Methods should constantly be subject to refinement and adaptation to better fit current circumstances – be it cultural or organizational – while principles and underlying values should not change all the time. 

With almost 20 years since the Agile Manifesto was written, let’s now reexamine the 12 principles to see how they have stood the test of time.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The focus on software limits the potential to innovate and deliver customer value. Software should be discussed within the context of business models and the JTBD. Although software, or “high-tech”, has meant a great deal for scalability and measurability, there are instances where low-tech solutions can be superior in delivering customer value.

There’s also an important distinction to be made between “satisfied” and “loyal”. Customer loyalty is directly correlated with lower churn, while customer satisfaction perhaps is less so. Frederick Reichheld makes a powerful case for this in his book The Loyalty Effect published in 2001 (the same year the Agile Manifesto was published).


Proposed change: Our highest priority is to create loyal customers 

through early and continuous delivery of customer value.


  1. Welcome changing requirements, even late in development.

Yes, it’s better to “pivot” late than never to “pivot” and die. This has a lot to do with letting effectiveness (= doing the right thing) take precedence over efficiency (= doing the thing economically). Or as Alberto Savoia would say “It’s more important to build the right it than it is to build it right”.


Proposed change: None


  1. Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The focus on software limits the potential to innovate and deliver customer value. When we focus on software, which is a solution, we tend to forget about the problem or JTBD that we are solving for and if we’re addressing the right customer.

Proposed change: Remove since it has 

already been covered under point 1.


  1. Business people and developers must work together daily throughout the project.

Business people usually don’t know how to code or develop software so why are they needed here? Well, it’s to ensure that the software that’s being developed meets the purpose of the business and its customers, i.e. all stakeholders.

We’d also like to kill off the word “project”, now that there is overwhelming agreement that permanent teams are the way to go. We send temporary work to permanent teams; we don’t create project teams around temporary work. 

Proposed change: Developers, customers, and stakeholders 

must work together daily throughout delivery.


  1. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

Since the Millennials (a.k.a. Generation Y) started entering the workforce in 2000, the focus has shifted from doing what you are told to do, to understanding what the company stands for, it’s mission and values, and how that aligns with your own purpose in life.

In 2009 Daniel Pink published Drive where he spoke about the importance of purpose, mastery, and autonomy as key factors of high-performing teams. 

That same year Simon Sinek published Start with Why – How Great Leaders Inspire Everyone to Take Action, where he talks about the importance of inspiring people by a sense of purpose, or “Why”, before communicating the “What” and “How”.

“Motivation” used to be extrinsically forced upon us to become something that is intrinsically discovered and understood.

A consequence of this is that trust must go hand-in-hand with accountability. The more empowered that we become, the more responsibility we must accept. 

Furthermore, transparency is a two-way street – teams need to be transparent and accountable to their surroundings, with stakeholders and supporting structures responding in kind.

Proposed change: Build teams with a shared purpose.  

Give them the environment and support that they need. 

Trust them and hold them accountable to get the job done.


  1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

If the aim is high performing teams it helps if we can have them physically in the same room. When teams grow and time zones become stretched, this can pose a challenge. Although modern communication technologies have helped to alleviate some of these challenges, co-locating people from different time zones to sit together is often a great way to boost productivity.

Proposed change: None.


  1. Working software is the primary measure of progress.

Software is just a means to an end. If we focus too much on the means we may lose sight of what really matters. Hasn’t that been, and to some extent still is, the biggest weakness of some “Agile” teams?

Let’s not forget the wise words by Theodore Levitt:

“The purpose of a business is to get and keep a customer. Without customers, no amount of engineering wizardry, clever financing, or operations expertise can keep a company going.”


“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.”

We can also take this one step further by considering that software through IoT and Ai will have a serious environmental impact by controlling the inputs and outputs of the physical world beyond our understanding. 

More time should be spent on discussing the values, ethics, and actions that maximize human well-being, and less on how to achieve ever greater efficiencies, economic growth, and profit maximization. Let’s not forget what our true North star looks like or should look like.


Proposed change: A working product, solving real customer needs,

 is the primary measure of progress.


  1. Agile processes promote sustainable development. The sponsor, developers, and users should be able to maintain a constant pace indefinitely.

In the Agile Manifesto “sustainable development” mainly referred to not over-working your people and keeping to a 40-hour workweek, thereby enabling teams to “maintain a constant pace”.

Increasingly over the years sustainable development has taken on a new meaning, perhaps best defined in the Brundtland Report as “meeting the needs of the present without compromising the ability of future generations to meet their own needs”.

Proposed change: Agile processes promote sustainable development. 

The sponsor, developers, and users should be able to maintain a constant

team-friendly pace indefinitely, without compromising the ability of 

future generations to meet their own needs.

  1. Continuous attention to technical excellence and good design enhances agility.

This has to do with reducing delays. If what we develop is filled with bugs, or is poorly designed, the result will be delayed during testing, deployment, and adoption. And without adoption, there can be no innovation. But we should also not forget that a great product must merge with a successful business model.

Proposed change: Continuous attention to technical excellence and 

good design of the product and it’s supporting business model 

enhances agility.


  1. Simplicity—the art of maximizing the amount of work not done—is essential.

“Maximizing the amount of work not done” combined with “failing smart” is the essence of “lean”. Control that backlog and focus on a few priorities at a time.


Proposed change: None


  1. The best architectures, requirements, and designs emerge from self-organizing teams.

This is as true today as it was back in 2001. When we try to build architecture on the enterprise level, more coordination is needed. It is not sensible for the customer or the company to allow teams to create architecture without first having considered the full picture.

Proposed change: The best architectures, requirements, 

and designs emerge from self-organizing teams that have 

found a balance between focusing on its own universe

and understanding the larger enterprise that they are part of.


  1. Regularly, the team reflects on how to become more effective and adjusts accordingly.

How many of you have run poor retrospectives or even skipped them altogether? Just as we are learning about the needs of the customer and what our value proposition should look like, we must also continuously learn about how we can best work together as a team, or team of teams.

Proposed change: None



  • “Agile” is no longer only about software or the reserved domain of software developers. Instead, all domains can and should benefit from a more agile mindset.

● Agile is no longer just about teams – we now do agile in large organizations.

● Agile in 2001 assumed that the product owner or customer could define the product backlog. This is not easy! Thankfully, we now have several frameworks for innovation and business modeling that can help the product owner with her job.

Therefore, we need to continue to frame our discussions under the banner of organisational agility with software agility forming a subset of that.

New frameworks such as Modern Agile, created by Joshua Kerievsky in 2015, and the Scaled Agile Framework (SAFe) are clearly moving in this direction. 

A final observation is that the Agile Manifesto was written by 17 men. We guess that if it had been written today it would have been slightly more gender-balanced. At least we hope so.

By Andy Cars and Per-Magnus Skoogh