Agile Manifesto: Incredible Success and Time to Move On

April 4, 2012 — Posted by Al Shalloway

I have incredible respect for the signatories of the Agile Manifesto. I believe it to be a great document. I say this for several reasons – the greatest being it created a new space for effective development to take place. It started a movement that has changed the lives of millions.

That said, I believe manifestos, by their very nature when they are effective, tend to be time dependent. In the case of the Agile manifesto, this is particularly so – it's very success has created a vacuum.

The Agile Manifesto's success has created opportunity for Agile to manifest (pun intended) throughout the organization. However, because it focused on the development organization, it has left a vacuum.

Some people have challenged me about my assertion that the Agile Manifesto focuses on the development team. A twittervation with Derek Neighbors (@dneighborsr) prompted me to make the following table about the Agile Manifesto – showing what it mentions by role/area:


Which Area / Role Is Referred to




Developers / Software / Project


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


Explicitly Mentioned

Explicitly Mentioned


Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.


Explicitly Mentioned

Explicitly Mentioned


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


Explicitly Mentioned


Business people and developers must work together daily throughout the project

Explicitly Mentioned


Explicitly Mentioned twice


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



Mentioned 4 times


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


Explicitly Mentioned


Working software is the primary measure of progress.


Explicitly Mentioned


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

Explicitly Mentioned


Explicitly Mentioned

Explicitly Mentioned


Continuous attention to technical excellence and good design enhances agility


Explicitly Mentioned


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


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



Mentioned 3 times



At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.




Total Times Mentioned





I am sorry if I can't see how the numbers on that last row don't make my case. However, be very clear, that this actually is evidence that the Agile Manifesto was great and worked! So no one should take this as an attack on it. By working so well, we have expanded Agile into a space outside of where the Agile Manifesto originally existed. I can't think of a greater testament to it than that.

Agile is now as much, or more, about the enterprise as it is about teams. We don't need a new manifesto, we just need to be open to expanding what we are going after.

Alan Shalloway
CEO, Net Objectives


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



Given that The Agile *Software* Manifesto was produced by a group of software practitioners is it surprising that it makes scant reference to management?

Rather than discuss the obvious point that the Agile Manifesto doesn't address *every* function involved in software delivery in an enterprise context, why not discuss why others haven't stepped up to the plate and created a manifesto of their own?

Like all historic documents, the Agile manifesto was a product of its time. The signatories were attempting to provide leadership. They clearly felt that providing a lead was needed since the people who should be leading (i.e. the Managers) clearly were not.

Is it any surprise that they chose to ignore management? Is it any surprise that the only Leadership Manifesto we have today is from the practitioners themselves?

And what has changed in the meanwhile? Has management got any better? Are managers stepping up to the plate and filling the leadership vacuum the Agile Manifesto tried to fill for them?

Or is able leadership in our industry still a rare a sight as it was when the Agile Manifesto was first penned?

I have long said that the agile manifesto was a point in time. but many don't hold it that way. While it is not at all surprising that the AM has a developer bias, it is held by most devs as truth and all encompassing. that's the issue. And, my experience is the % of good managers is about the same as the % of good developers. Most devs and managers are not very effective yet hold themselves to be so.

I agree. The AM resonated with many developers, as is clearly shown by the many developers who signed it.

In contrast the response from the management community was moot. I would go as far as to say that most IT Managers haven't even read it.

So my question is why is that? Why does it appeal to developers and what does the management community have to say in response?

"And, my experience is the % of good managers is about the same as the % of good developers."

This is a real indictment :) Managers are in a position of responsibility with a huge ability to impact outcomes. They are in control of decision making, and the decisions they make are crucial (I know this from my own time in Management). If organisations aren't making the investment needed to ensure that at least their IT leaders are of highest caliber then what hope is there?

I agree with you about the point in time. I agree with you that the AM isn't the whole story. It is a big piece of the story though, one that has resonated with a large number of practitioners...

As I said before. The more interesting point isn't that a bunch of software development practitioners found themselves having to take the lead...

It's a shame that 14 years later the leadership community still hasn't come up with a coherent response of their own. My guess is they never will!

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban