Agile Manifesto 2.1 – “MoreAgile Manifesto”

An interesting article by Geert Bossuyt caught our eye recently about a fresh way to look at the Agile Manifesto, or what he is calling “MoreAgile Manifesto.” We wrote about Agile Manifesto 2.0 before, and we really like the spin that Geert put together, in sum:

  • Teamwork & responsibility over Individuals and Interaction – You need great individuals and the better they interact the better it is.
  • Business Value over Working software – Software in itself has no value. It’s what you do with it.
  • Partnership elaboration over Customer collaboration – Collaborating with your customer is important, but working on a partnership is better.
  • Prepare for change over Respond to Change – It’s even stronger to create a setting where change is normal.

So, after 10 years of Agile, is it time to re-look at the manifesto? Read the Agile Scout manifesto here.

[HT: Xebia]

Author: peter

Peter Saddington is an Organizational Scientist and Certified Scrum Trainer. You can find him at

29 thoughts on “Agile Manifesto 2.1 – “MoreAgile Manifesto””

  1. The only point I think I can find as a potential improvement is the first one since it emphasizes teamwork and responsibility (to the team I presume).

    The Agile Manifesto is targeted for software development. Perhaps we could have some over-arching manifesto, but de-emphasizing the software development is causing things like the software craftsmanship movement which has the potential to pull business and IT back apart as we begin focusing on different areas again. The Manifesto starts with “We are uncovering better ways of developing software…” If we want to change that to something else (growing the business for example), then changing the below four points makes more sense. I also look as software development holistically, meaning it could be implementation of a commercial package; it’s still software.

    While I agree in principle with the second point, I don’t think it should be a part of teams that determine the business value, only that the working software is meeting the expected value of the goals that were provided to the team. That’s why the Agile software development team exists; the Manifesto is targeted for providing the principles on how the Agile team should operate.

    Partnership elaboration sounds too vague IMHO. I suppose a good definition could be set-up, but the idea is engage customers. Through engagement we meet and hopefully exceed expectations.

    The last one I really dislike, sounds like starting to get more towards too much additional planning around what changes may occur. This needs to remain implicit. Too much proactivity can be wasteful (I prepared for this possible change, but it never occurred). Proactivity should be evidence-based, which means we are looking for leading indicators perhaps, which means it is a response.

    Appreciate you picking up on these things, so keep’em coming!


    1. I agree. The Agile manifesto was originally for the software development community. If people would like to put together a “business manifesto for value” or something like that then thats good. Dicing words together sometimes makes what was “good” to just “diluted.”

    2. Hi Paul,

      The MoreAgile manifesto starts with “We encounter possibilities to focus more on effectiveness by working Agile and learning from that. Based upon our experience we value : …”.
      Working Agile for 10 years has learned us a lot, it’s time to do something with these lessons and take the next step.

      There was a lot of comment on the last statement. ‘Prepare for change’ is meant to mean something like ‘organize yourself so whatever change comes along you’ll be able to handle it’. This could be implemented by doing big design up front and all other stuff that is really not good.
      Therefor the last statement has been improved to ‘Embrace change over Respond to change’.

      Partnership is the definitely the upcoming movement. The only real customer is the one that is using the software, it’s not the one who’s paying for the software. The one building and the one paying should partner to deliver real value for the customer – end user.

      More on this here :

      1. Sigh… because I forgot to fill in my name and email, lost what I had typed…


        Thanks for the clarification my friend. I’d like to think of yours as the Agile Organizational Manifesto. You want to be Agile? Then your take is almost exactly what I would shoot for… Your’re talking organizational culture (embracing change), partnerships and business value (how many of us see the CIO-COO tug of war?), and joint ownership (teamwork and responsibility). I just wouldn’t apply it to the software development side where the original Manifesto till works IMHO.

        Thanks for the great thoughts!


      1. Of course improvement over time, just not lumping changes into numbered version buckets. Does Wikipedia have version numbers? No. Does it change with agility? Yes.

        1. All depends on how the app is deployed. We still support apps that get deployed to clients, so version numbers are very important, even though we are using Agile practices to develop them.

          For our web apps though, versioning is less important.

          Question: what did this have to do with the original post? Just curious how your train of thought to the track to versioning?

          1. My train of thought was that I’ve recently been hearing a lot about continuous deployment aka continuous delivery. And one of the hallmarks of such a process is the lack of version numbers (or at least the lack of importance of such numbering schemes). I think of such continuous improvement processes as the essence of agile.

            So when I came across this post, the first thing that struck me was the incongruity of the version numbers.

Leave a Reply

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