Extending the Agile Manifesto – 2018

Think outside of the boxSince 2001 we’ve applied the ideas captured in the Agile Manifesto and have learned from our experiences doing so. What we’ve learned has motivated us to suggest changes to the manifesto to reflect the enterprise situations in which we have applied agile and lean strategies. Because the original authors of the Agile Manifesto have decided not to evolve the Manifesto, a decision that we fully respect, we have decided to move forward on our own.
The Disciplined Agile Manifesto is an evolution of the original Manifesto for Agile Software written in 2001. We first published it in the book Disciplined Agile Delivery (DAD) in 2012, evolved it again in 2014 here on this website, and just recently evolved it yet again in our forthcoming book Choose Your WoW!

We believe that the changes we’re suggesting are straightforward:

  1. Solutions , not just software. Where the original manifesto focused on software development, a term which too many people have understood to mean only software development, DA suggests that we should focus on solution delivery. In short, we prefer solutions (software + hardware + supporting documentation + business process + organization structure) over just software. We also believe those solutions should be consumable (provide valuable working functionality + be usable + be desirable) rather than just be working.
  2. Stakeholders, not just customers. Where the original manifesto focused on customers, a word that for too many people appears to imply only end users, DA suggests that we focus on the full range of stakeholders instead. We prefer stakeholders – end users, operations people, sustainment people, audit, finance, and many more – over just customers. See Chapter XX for a more detailed discussion of this.
  3. Teams, not projects. Where the original manifesto talked about projects, we believe it is more accurate to talk about teams.
  4. Organizations, not just teams. Where the original manifesto focused on development teams, DA suggests that the overall organization and its improvement be explicitly taken into consideration.
  5. We’ve learned a lot since 2001, so let’s make that explicit. The original manifesto focused on the understanding of, and observations about, software development at the time. But we’ve learned a lot since then, particularly around continuous delivery and testing strategies that are embraced by DAD.
  6. Feedback, not just change. As Neil Killick and Dan North both point out, being agile is more about responding to feedback than it is to responding to change. This is an important nuance because it underlines the importance of working closely with our stakeholders. Additionally, it is more accurate to say that requirements emerge rather than requirements change as we develop a better understanding of the true needs.
  7. Lean and agile, not just agile. We have learned from the lean community. The Disciplined Agile Manifesto incorporates lean principles, in particular considering the whole, visualizing workflow, and minimizing work in progress (WIP).

The original manifesto principles were crafted to reflect the environment in the ‘90s when it was an accomplishment to have a demonstrable increment of a solution even every month. In modern times the bar is significantly higher. As such, if you compare the wording of the updated principles as we describe them to the original, you will observe that they reflect a lean philosophy of a continuous, just-in-time, experimental, and emergent approach to everything we do. What we have written may be perceived as heresy to some agile religious puritans but we believe it is time to move on to reflect modern realities and capabilities.

We’d love to hear your feedback.

Good things to know

  1. This blog posting has been modified from Chapter 2 of the book Choose Your WoW!
  2. We’ll be working with the translators of the DA Manifesto to get the translations pages up to date.  We expect this to take a month or so.
  3. Dan North’s Agile Revisited talk from 2015 provides some very interesting insights.

Have any Question or Comment?

9 comments on “Extending the Agile Manifesto – 2018

Randy Worrell

I personally see nothing wrong with an evolving outline of agile. Since it’s still essentially a set of concepts, it can be tailored to fit many scenarios, both IT-related and non it-related. It’s not like you’re re-writing the Bible, Torah or Koran, so I say let’s make it be more relatable to today’s environment.


We have really moved from Agile to Lean-Agile. Every Scaling Framework uses Lean-Agile. Team level Agile is a thing of past. That changes the picture much. As a wild thought, why say “Extending” manifesto? Why not say ” Rewriting” it? I feel, if all the authors of manifesto meet again, they’ll “rewrite” it and if they do, that precisely is the sign of Agility. Yes, we’ve come a long way. It’s not about only iterations anymore, it’s about flow…continuous delivery, not frequent delivery. Well, some would say, consider the ” software” in the manifesto as metaphor. Smart point, but what’s the reason for not being explicit and current? I agree that all the values haven’t become obsolete or irrelevant, e.g. Individuals and Interactions are still valuable. But let’s accept the changed scenario and “respond to change”!


Hmmmmm…. rewrite might be a better term. Need to think about that.

Agree that it should be more about continuous delivery than frequent delivery.

Definitely agree about being explicit about solutions, not just software. Too many people think in black and white terms, so not being explicit is risky.

Valentin Tudor Mocanu

Responding to change it is from Requirement-side ( what the world want from software development)
Responding to feedback it is a Solution-side (what development do to respond to what the world want)

It is not an extension – it is something else. It is one of the fundamental ways to respond to the changes. Another way is to get the feedback more often (small releases, iterations etc)

Evangelos Mavrogiannakis

Personally I have 2 minor concerns on the extended content.
1. Solutions , not just software. I understand why we add this . As the title is simplified, it may looks that is against on agile key principal to deliver the code in very small pieces – artifacts. I would have chosen a different title to express that. Kind of – Agile artifacts deliver business solutions no just software.
2. Teams, not projects and Organizations, not just teams. Personally I would think that those two can merge to one principal as -Organizations not just project teams. –


The challenge with the word artifacts is it is often used to refer to documentation, or to non-executing stuff.
I disagree about combining organizations and teams as a principle. I think it’s the same issue as Prashant brings up, one of clarity. It’s important to make it clear that agile can be applied at both the team and organization level.

Evangelos Mavrogiannakis

In my definition artifacts is everything code and no executed stuff. This makes my argument stronger that every deliverable in Agile contributes to a business solution and not just software.
Same applies to my definition for organization. Teams are part of it.
However I understand why you want leave them as they are.
Good luck and I look forward to translate the new extended manifest to Greek as I did the original.

Bret Mogilefsky

Scott, maybe you want to try to funnel some energy/visibility toward this?

There’s a lot of alignment between what you’re saying here and the bolded items on that page.


Thanks. I will check it out.


Leave a Reply

Your email address will not be published. Required fields are marked *