MoreAgile Manifesto

23 Dec, 2010

We encounter possibilities to focus more on effectiveness by working Agile and learning from that. Based upon our experience we value :
Teamwork & responsibility over Individuals and Interaction
Deliver Value over Working software
Partnership elaboration over Customer collaboration
Embrace change over Respond to Change
While we value the Agile Manifesto, we state that MoreAgile is more Agile.

Teamwork & responsibility over Individuals and Interaction
You need great individuals and the better they interact the better it is. But more important than having great individuals who interact brilliantly, is to have great Teams. A Team that really works together will be multiple times more effective than a set of individuals interacting. Give the Team as much responsibility as possible and stimulate Teams to fulfil that responsibility !
Deliver Value over Working software
Working software is great, and it’s definitely better than comprehensive documentation. In many cases working software adds to the real goal, but in fact it’s not about software. Software in itself has no value. It’s what you do with it : It’s about the value you create with this software. No, in fact it’s just all about creating value ! With or without software.
Partnership elaboration over Customer collaboration
Customer collaboration is a fine statement and it will always lead to a suboptimal situation. Collaboration is fine, it’s the customer part that indicates a demand-supplier relationship which holds an unbalanced relationship. Collaborating with your customer is important, but working on a partnership is better. Become together responsible for the result, no more demand suply, just one goal and a Team making it happen.
Embrace  change over Respond to Change
There will be change ! A lot of it. It’s good to respond to that change. It’s even stronger to create a setting where change is normal. Whatever happens is the only thing that could have….
MoreAgile organizations follow these principles.

Newest Most Voted
Inline Feedbacks
View all comments
Mr. Check-in
11 years ago

I’m tired of these nonsense of the agile world.
You talk talk and say nothing. They live in a Utopian way of working and thinking that everything can be done in the agile model.
Give me a break, will you?!

Olaf Lewitz
11 years ago

it seems to be manifesto time…
This is the most useful addition/modification/improvement of the agile manifesto I’ve seen so far.
It keeps the good stuff and positively strengthens areas of possible improvement.
A good thing to end an awesome year with!
Thank you, and …
Prettige kerstdagen en een gelukkig Nieuwjaar.ӬTake care,

11 years ago

Great post ! I fully agree with this finer/deeper definition of Agile 🙂
Be careful on the last one “prepare for change”, it could be misunderstood as “I have to anticipate changes so my software has to be very generic” (I know you don’t mean that)

Agile Scout
11 years ago

Ooo. Like these here. It may be the small nuances and wording differences but it definitely focuses in on some key points in business relationships.

Bob Badour
11 years ago

This is far, far, far superiour to the original Agile manifesto. Exactly as Agile Scout says, the small nuances are crucial. I honestly didn’t understand some parts of the other original, they were too confused between process and product. Yours is much clearer.
Thank you, Geert, and please blog some more on this …

Patrick Verheij
11 years ago

Looks like we’ve got the second iteration of agile with this. Good forward thinking. Such an upgraded manifesto might push the mindset a bit further.
A few thoughts for reflection though:
– It is a bold statement to say that teams are considered more important than individuals. Great teams are, but research shows that individual excellence far exceeds inferior team performance. Building great teams is still a challenge and a huge impediment for true agility. So I thoroughly agree with the value, but in practice we should be careful not to preach it as a silver bullet for it will be a long term investment for most companies. A value like this might make certain people think that agile is for the elite only. Which is good by the way, because business should excel 🙂
– Business value is quite a daunting term. Almost a buzz word. Working software is something technicians understand. You can link it with technical excellence and quality. Business value is much more fuzzy. I absolutely agree with the value though. What should be preached is that it is not always necessary to build software if you can get business value in different ways too. This way, you push agility from an IT perspective to a more worldly perspective.
This MoreAgile manifesto could work out brilliantly if coupled with a decent vision on how companies can apply it properly. And don’t forget the showcases of course. Excellent showcases. It is about time people realize that only the excellent will prevail in the end, so a shift in thinking and doing is really necessary.

Daniel James Gullo
11 years ago

Sweet. In a world saturated by the term “agile”, this post calls out the need to go beyond what some pundits promote with religious zeal and without thought to the bigger picture. Ultimately, the very essence of agile is change. Why shouldn’t the definition of agile itself evolve???

Chris Chandler
Chris Chandler
11 years ago

Business value over working software is great, because in most cases I think the highest business value will be in producing working software, so I think you could say that you’ve fulfilled the “more” part of your article’s promise.
I think the same could maybe be said of teams, since they are composed of individuals, but responsibility over interaction is thornier. I would like more clarification about how you can focus on responsibility to improve teams over time.
The last two just don’t quite work IMO, sorry. Businesses have customers, and calling them partners is soft and very trendy, but I don’t think you do enough to talk about what it means, and why it is necessarily better than customer. (and, as a word, collaboration is way stronger than elaboration, which I don’t even know what it means in this context)
And, frankly, I don’t see why valuing “preparing” is better or more agile than “responding” to change. I think responding to change is the tip of the spear — and the only way to learn to respond is to respond, if you know what I mean.

Bossuyt Geert
11 years ago

Hi Patrick,
Thanks again for your interesting feedback.
It’s still without any doubt very important to have good individuals and have them interact in an effective way. Even with brilliant individuals, 1 and 1 becomes more then 2 when they team-up. It’s not a silver bullet, and it definitely is a longtime investment, but it’s certainly worth the effort.
Business value is might be quite fuzzy for technical people, but it’s about time to really involve ( commit !) business in this story. For business it means something, and the partnership will make it mean something for everyone on the Team.
I.m very interested in your ideas on these showcases. Do you mean cases from real live that describe how Agile made the impossible possible ?
And Can you tell a bit more about the mindshift you mention in your last sentence ?
Looking forward to another nice thread 🙂

Patrick Verheij
11 years ago

Hi Geert,
Happy new year to you, with lots of great opportunities, whether or not related to agility.
As for teams, I cannot emphasize their importance myself. I have been part of great teams and I love them. I have also been part of teams that were not so great and this teached me that true team building is hard and quite exclusive. So continuously “requiring” great teams in order to be agile is not such a good idea in my opinion. I think “team building” should be a continuous effort as part of a greater journey towards more agility. This requires some activities which should be guided by agile coaches (or other people for that matter). besides that, I think “teams” are overrated with respect to agility. They are just a very good means of “being able to build better software”, not a goal in itself and also not always required to be agile. I think it fits the “more” agile idea quite well, and perhaps even as a value. But I am careful.
I certainly agree with involving the business. Just mentioning “business value” as being important is not enough, though. I have seen IT people that were very knowledgeable about their business and very committed to it. In all cases, these people were considers treasures. They were also very rare, though. Truly understanding businessvalue means being involved in that business for the long term. Then again, you need to “see” the true value in order to understand it. Many people I know, even in the business itself, don’t have a clue. So if we start promoting business value as a more agile value, let’s teach people what it truly is instead of just using the buzz word.
As for showcases, I mean real life examples where great teams were built. Real people endorsing their teams and explaining why they work so well. Or real people explaining real business value that was created by IT people being involved in that business. Not the usual or Google examples, but continuous examples, preferrably Dutch ones.
The real mindset behind agility is the ability to understand that true value is about delivering better than expected and being able to do that continuously. It is about “shipping art” instead of just doing your job. Companies that do not challenge the status quo and continue to deliver average work will cease to exist. People like Seth Godin blog about these things continuously and someone like Steve Denning has just written an entire book about it (even though you may question its innovative value). Radical management he calls it.
So far for another part of this threat 😉

Mike Sutton
Mike Sutton
11 years ago

This is indeed the previously unspoken next iteration on the Manifesto – well done for crafting it with passion and honesty.
It is less alienating than the iteration 1 and more inclusive of the wider world that we all operate in.
I would review ‘Prepare for Change’ – perhaps ‘Embrace Change’ may be better.
The former triggers images of a ‘Change Management Office’ and the latter, I hope, projects a sense of a more organic grassroots support for the change that will happen anyway.

Roger Gamage
Roger Gamage
11 years ago

I work in a world where a truly Agile approach sometimes cannot, or more often will not be adopted due to technical, organisational, cultural or other reasons.
This new manifesto, however, is equally applicable to all approaches except, perhaps, where an organisation goes out of its way to be bureaucratic and unresponsive (sadly these organisations do still exist).
I do agree with some of the posters that some refinement might be needed, but I’d be very happy to promote these principles to my clients, whether they embrace Agile or not.

11 years ago

Nifty done play with words. If you create a MoreAgile Manifesto, you must be More Agile. And if that’s ain’t ’nuff said, you have more! If you add teamwork and responsibility over interaction, you surely are responsible and your teams always work. If you say business value over working software, there is no way in hell you will create a software that has no business value. And to hell with collaboration. It’s useless anyway. Partnership sounds so “business”. Good choice again.

Overall, I feel you took a standard and played with words around it to make it more pleasing and trendy.
Here is why:
1) Teamwork & Reponsibility over Individuals and Interaction
Individuals + Interaction = Team Building. Good Team Building produces Teamwork. Also, if you value your programmers, they’ll value you, via you, their boss and employer they will value your company. And with this comes valuing your customers and their products users. Contrasting these you make Agile Manifesto seem like it was about good fun without any responsibility. That’s misleading. Also – interaction between individuals means responsibility. If I promise you I’ll deliver the software, I’m responsible for delivery. If I promise you my team will deliver software, question arises who am I and can I promise this in the name of my whole team. Interaction between teams happens via individual folks, if you choose responsibility instead, I wish you luck. No team will be willing to shoulder responsibility if there is no interaction between them and clients. Responsibility is cold and weights a ton and if not fullfilled costs you. Even when you try to be responsible it may well be you won’t (3rd party subcontractor goes bankrupt – good luck with responsibility). Interaction is about talking. Is about communicating. Responsibility very often is about being guilty or having to reward customer for failing the deadline. After all, they pay they demand and frankly lots of them likes to demand the impossible | your head if you fail to deliver | that you implement the thing they wanted three weeks ago and changed their mind about thrice since.
So yes, choose responsibility for your programmers over interaction. Managers will love your MoreAgile way. Sales folks too.
2) Business Value over Working software […] in fact it’s just all about creating value! With or without software.
Good luck with that, creating value in software development, without software. And how is working software delivered for my client without value, if we collaborated since day one? And if we didn’t (because he was busy or I didn’t care), I have equally good chance on getting business value if I focus on working software well done, in agreement with domain model and current priority list, as if I focus on business value.
Business value is a buzz word. If you have a programmer, who’s doing Haskell-style correction in your code when you have 80% Must Haves pending and deadline fast approaching, you either failed with interaction in the team and he doesn’t realize what’s priority or he doesn’t realize what’s priority anyway and you should suggest him another job if he can’t overcome this.
3) Partnership over Collaboration
What’s wrong with collaboration? Actually I like it more than partnership. It has this “mutual” feel to it.
4) Prepare for change over Respond to Change
Nifty play with words still, but this one actually is least problematic to swallow. Still, respond to change also had (for me at least) clear feeling that said change WILL happen INEVITABLY. If I focus on interactions and collaborate, work in iterations to deliver often and quickly, prioritize with MoSCoW and WITH client, what else should I do to be prepared?
No to mention that extensive preparation still may NOT include the change, that will happen. And are resource consuming. For how many changes you are preparing instead of actually working on deliver that business value you so want to focus on? No client will be happy, when you will have advanced DR environment ready “just in case”, yet fail to deliver must haves you promised you will.
I realized I was harsh in my comments. Yet even now, after waiting few weeks after I read this, I still feel this is wrong.


[…] vor Weihnachten veröffentlichte Geert Bossuyt auf dem Xebia Blog das MoreAgile Manifesto. Ich war begeistert… Please […]

11 years ago

Good stuff … hard to tell precisely what your intention is with #4 – I don’t take it to mean “Encourage Change” – but making change normal I still think is a problem of sorts… Not that we shouldn’t be able to respond to it or that we should fear it. But I’d angle more toward clearly defining the high-level “why?” i.e. clear goals .. and elaborate everything below that just-in-time. Therefore, unless you’re changing the business goal (which shouldn’t be *too* common, if the cycle is appropriately short) – you’re not actually *changing*anything. You’re deferring decisions until the point that change is no longer likely to happen.
So, yes – ability to change is good – but allowing the business to evolve and elaborate at a natural (non-artificial) rate is the underlying purpose.

Bossuyt Geert
11 years ago

MoreAgile is now also available in Russian and German


[…] Het MoreAgile Manifesto geschreven door Geert Bossuyt spreekt mij ontzettend aan: Teamwork & responsibility over Individuals and Interaction (over processes and tools) Deliver Value over Working software (over comprehensive documentation) Partnership elaboration over Customer collaboration (over contract negotiation) Embrace change over Respond to Change (over following a plan) […]

Laurens Bonnema
11 years ago

Reads a lot like Kent Beck’s revision of the Agile Manifesto that I’ve been using as an add-on to the original. See
I think the first three additions are best described in this manifesto; the fourth addition “embrace change” is very, very similar to “responding to change” and thus, imho, not a great addition. Kent talks about “initiating change” over “responding to change”, which I feel is more of an addition.

10 years ago

When are you taking the PMI ACP Agile Exam?

Andriy Mudryy
10 years ago

I was a leader of groups that were interpreting Agile Manifesto 1.0 to a group of Slavic languages. So I was wonderin if we can translate this one too. I’m a Project Manager in the leading software consulting and software outsourcong company in Europe: softserve.
I’m interested in more details of this v. 2.0 agile manifesto. Please contact me if you are interested on spreading the idea, cos I lke it ))

Laurence Fabel
Laurence Fabel
9 years ago

This seems really neat! When are you planning to release it?

8 years ago

I do consider all of the ideas you’ve presented on your post. They’re really convincing and will definitely work. Still, the posts are too brief for beginners. Could you please extend them a bit from subsequent time? Thank you for the post.

Explore related posts