tiero - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Agile Manifesto: Both timeless and outdated?

The Agile Manifesto changed the way we look at the software development process. Today, the Manifesto is outdated in some ways and timeless in others.

When the Agile Manifesto emerged in 2001, it mattered. I would argue that it changed software development forever. I'm not saying it solved the daunting challenge of developing good software. We're still working on that.

The Agile Manifesto took a troubled, backroom operation and proclaimed to the business and tech world that the accepted approach to developing software did not work. The process was broken. It took too long. It cost too much. Too often, it delivered products that didn't do what they were supposed to do.

But what about today? Does the Agile Manifesto matter anymore? Or are the ideas it put forth out of date? I recently mulled over those questions with Derwyn Harris, a co-founder of Jama Software, which sells software for managing the development process. "I love the Agile Manifesto," he told me. "So much innovation and change occurred as a result of the principles [it put forth]." But, he said, it is out of sync with the realities software development pros face today. "We need to rethink it," he said.

Here are some ways in which the Agile Manifesto is outdated -- and some ways in which it remains more relevant than ever.

Software development is much more complex today

When the Agile Manifesto authors took pen to paper in 2001, software development was already a complicated undertaking; but not by the standards of 2015. Mobile apps weren't a factor and social media as we know it today didn't exist. "Nothing lived in the cloud and 'dropbox' was something you did by accident if you were clumsy," said Harris.

The volume of software being developed today dramatically outpaces that of 2001 and the Agile Manifesto doesn't address that reality, he said. "There is a notion in the Manifesto that we're trying to move away from planning, away from negotiation," he said, referring one of its four core values, Responding to change, over following a plan.

[In 2001] 'dropbox' was something you did by accident if you were clumsy.
Derwyn HarrisCo-founder, Jama Software

"But the need for planning [software projects] in today's world is real and you cannot ignore that," Harris said. "The business is saying 'I want a budget for the next year, a roadmap for our customers.'"

In the same vein, some of the Manifesto's 12 principles seem out of sync with the large scope of many software projects today. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," one principle reads. But the face-to-face approach doesn't really fly when development managers are asked to oversee large projects with multiple, geographically distributed teams, Harris said. "They panic and they wonder how they are going to scale it."

Here's my take: When it comes to managing projects -- going with the flow instead of following a plan -- the Agile Manifesto is outdated. The ideas it puts forth on this topic sound naïve in the current context of software development.

The customers are more vocal today

The Agile Manifesto has much to say about the customer, and what it says remains relevant today. "Customer collaboration over contract negotiation" is one of the core values. And "our highest priority is to satisfy the customer" is first among its 12 principles.

What the Manifesto's authors could not have predicted was just how vocal customers are today. Posting on social media and other websites, they generate a steady stream of comments, complaints and the occasional rant about a company's products and policies. "And all that noise is associated with your [software] product," Harris said.

The challenge, then, is to tap into the noise in a meaningful way, analyzing feedback to build software that better satisfies the customer. That task is daunting, but "social media offers opportunities for customer collaboration" that simply weren't there when the Agile Manifesto emerged, Harris noted. "That is what we should focus on."

Here's my take: the Agile Manifesto nailed importance of customer collaboration. And that's as relevant today as it was in 2001.

The role of the business stakeholder

Here's another principle the Agile Manifesto has right: "Business people and developers must work together daily throughout the project." That's been harder to accomplish than the Manifesto authors -- or any of us, for that matter -- anticipated. But they were dead-on about the importance of the business stakeholder role. I don't think anyone would dispute that successful engagement of business stakeholders is crucial to software development success. But that doesn't mean it's going to be easy, Harris said. "You are taking on chaos. There's more dialog, more meetings, more communication. The goal is build the right product, and that's never easy."

The Agile Manifesto has a lot of things right in terms of helping software teams build the right product. It set us on a course that we're still charting. Successful software development is a work in progress, and if nothing else, the Manifesto steered us in the right direction. It still matters.

What do you think? Does the Agile Manifesto still matter? Let me know.

Next Steps

Adopt an Agile mind-set to cash in on timeless Agile benefits

Context-driven testing (CDT) may provide an Agile alternative

Take a look at Agile ALM

Gain insights from some Agile Manifesto signatories

Explore some reasons for Agile backlash

Jama Software may be easier to use than you think

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you think the Agile Manifesto is timeless or outdated?
Hi Jennifer, Your post is a good point to start a discussion about something written almost 15 years ago. And, well, 15 years is a really long period! I think we are mixing two different aspects: values and principles with methodologies. Values and principles as expressed in the Agile Manifesto are still valid (and I think will remain until next disruptive 'people vs machines' intuition).
The Agile Manifesto doesn't say we have to move away from planning or negotiation, but only that we PREFER responding (promptly) to change over following (slavishly) a plan.
We need plans for various reasons (budgets, stakeholder communications, large project or programme management, etc), but these plans should be adaptable and should add value to a project, not constraints.
About customers presence in the project, in my opinion, the Agile Manifesto, 15 years ago, was already a prediction on what would have happened with Social Network: your customer is inside your project and directly connected with you, he is the entire world and you have to find a way to offer them real value and you have to be prepared to hear all of their vocals.

So, if the Manifesto is timeless where should we upgrade the know-how to face changes in our project?

We have to do that in methodologies!

If you look at first version of Scrum and try to apply it on a today large project (that maybe comprehends mobile app, web site, social, SEM and marketing campaigns, etc) the project will most probably fail. And that's exactly what Derwyn says.

Nowadays you have to use SAFe or Enterprise Scrum or DSDM for programme management, in conjunction with BDD, TDD and XP for the development aspects. You have to consider Lean and Cynefin as tools to manage Socials and Communities issues. And these are only some of the innovative methodologies available.

Our challenge is to face changes (technological, social and personal) with the adoption of innovative Agile methodologies capable to manage large project in respect of Agile Manifesto values and principles.

Ernesto Amato
The Agile Manifesto had a good approach when it first arrived, but this has changed with current software development. Our budget and priorities are much different now than they used to be.
This writeup was definately something different from that of the usual pro-agile writeups.
But i beg to disagree with your views here.
Foremost reason being, agile has defined the set of rules for you to follow. How you do it is definately left to us. Not all projects can fit into single methodology be it scrum, kanban etc.
Its upto us; on how we implement the rules that suits us best.

I disagree with the notion that Agile means less planning. Scrum, the most widely adopted agile framework relies on 5 levels of planning. This is actually more planning that most waterfall approaches account for.

Agile isn't about less planning but it is about being responsive (even seeking out) those inevitable changes that occur during a project.
Briefly no.  People still don't understand what Agile is.... make excuses when they try and fit their structured view onto an agile idea, and then blame the idea they never fully bought into for the failure.   I'm convinced that the ideas in agile help bridge the communication barriers and improve development processes, and the value of what is produced.
Wow, 15 years. I believe it is mostly still relevant. I don't necessarily agree that software development is more complex. Yes, mobile and social development is big right now. So what? There always have been and always will be emerging trends and new technologies affecting software development. 

Also, I work on a distributed team and it is a fact of life, but I firmly still believe that  "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation". In fact, I probably believe that now more than ever. Remote communication, with technology snags, time zone, and language barriers, always adds some amount of difficulty. 
While I appreciate the devil's advocate perspective about Agile, I don't agree with the assessment that it is better to follow a plan than adapt to change. Although Agile is 15 years old, the Waterfall methodology--which is the most likely alternative--is 45 years old. I'd much rather follow a post-Internet methodology than one that was created in 1970. Furthermore, the more complex the project is, the less useful upfront planning becomes, because the number of unknowable variables increases exponentially. Therefore, Agile is more relevant now than ever precisely BECAUSE software is more complex. Finally, it is worth noting that Jama software produces requirements management software, so it's not a surprise the writer has a negative perspective on Agile. I think the argument can be considered on its own merit, but the writer's background is a salient consideration in the discussion.
I work for a large multinational IT company that for cost reasons have offshored to low cost countries much development work. We have people working in the UK, in Europe and in South Asia. It doesn't work! The quality of our software products is abysmal, commuication is weakened, management more difficult.

I worked on one military project where the entire development team all resided in a single room, a large open plan office.  Even then because one developer was on the other side of the room hidden behind a desk partition and not within earshot of the team, that caused big problems.

The idea that you can run an agile project across countries is flawed.  You could do it (just about) with a waterfall life cycle project where you have captured and written up all the requirements up front, you can then send the requirements document out to the separate development teams for implementation. But an agile project? It's going to be highly problematic.

JakeBenn, I agree with much of what you have said which justifies the need for agile, but what I disagree with is the idea that you would prefer an agile methodology over and above the waterfall approach because waterfall is old.

I worked on a multi-billion dollar project in recent years which was implemented using the waterfall appraoch and it was a highly successful project.  Waterfall has its uses.

Yes, overall it has been discredited as it has inherent weaknesses, but on some projects it is the most suitable methodology.

And do not forget, agile is NOT the cheapest way to get a the job done: waterfall is. But where some projects may fail in waterfall, they will succeed in agile.

And I can still see a need for that 1990's methodology of RAD, rapid application development and building a prototype first.

Interesting post: it's a good point to start a discussion about something written almost 15 years ago.
I think we are mixing two different aspects: values and principles with methodologies.
Values and principles as expressed in the Agile Manifesto are still valid (and I think will remain until next disruptive 'people vs machines' intuition).
Read the rest of my reply here: https://itknowledgeexchange.techtarget.com/discussions/discussion/do-you-think-the-agile-manifesto-is-timeless-or-outdated/
Wow what an interesting article, and I couldn't disagree more.  Agile doesn't say you shouldn't plan, it says you should do it more often, and in discrete increments.  Plan smaller changes as much as possible, (and nothing stops you from considering long term architectural needs at the same time.)  As far as face-face conversation goes, A lot of tacit communication can still be lost because you don't sit near the people you work with, but software like Skype, Google hangouts, and Lync not to mention web conferencing software of many kinds, go a long way to helping bridge that problem for teams that are remote.  To the point that I'd argue if you're having troubles communicating via remote, then the issue is deeper than the tech available.

Are there still issues company have with Agile.  Yes, but most of them, I think are issues with the company... not the Agile principles.
I do not think the problem is that the manifesto is outdated, I think the problem is that the common and accepted interpretations are outdated because the interpretations themselves are not agile. I have to agree with Veretax that it doesn’t mean don’t plan, it means plan and adjust that plan as necessary to respond to change, which is quite different from going with the flow. Remember that the manifesto says that we are uncovering better ways, not that it present the best way. We need to keep that in mind, and examine what it says in light of the context of the current state of software development. If we do that, then the manifest will remain timeless. 
Let me put it this way: I don't think the Manifesto is going out of style anytime soon. Its core elements remain accurate and useful.
The model is still relevant and will continue to evolve. Collaboration and coding tools have greatly improved since 2001. Someday we'll collaborate and code by voice dictation and this will be considered a natural next phase of agile.
As earlier commentators have mentioned or suggested, Agile presents principles or values. As to how these principles or values are to be implemented is up to the IT Shop. And so, I think the principles and values it recommends are timeless.
LordLionO - this argument sounds similar to that for most religious texts. Even if times have changed since they were first created, they can be adapted and applied in different ways (for good or ill). And to some, I guess Agile is a kind of religion...
“The volume of software being developed today dramatically outpaces that of 2001 and the Agile Manifesto doesn't address that reality. There is a notion in the Manifesto that we're trying to move away from planning, away from negotiation.”

The author only criticizes that we value responding to change more than following a plan. However, she is only criticizing a straw man. Valuing responding to change doesn't mean we avoid planning—a disclaimer right at the bottom of the manifesto itself clarifies this! Responsible Agile teams plan much, perhaps even more than in traditional software development. Agile planning needs to happen throughout product development and to accommodate the more important value of responding to change.

The Agile Manifesto “doesn’t address the reality” of how to plan for complex, fast-moving projects because it was never meant to address it. The Manifesto doesn’t try to give us “values” that we can apply to address every trend and movement of how software is made—it simply provides four values that historically have been secondary and makes them primary. You can—and often should—uphold other values that the manifesto didn’t anticipate.

If the author means to criticize some naive "Agile" teams for failure to plan, then that is fair game. I would join him!
"There is a notion in the Manifesto that we're trying to move away from planning, away from negotiation,..."
This statement is not correct; it confuses plans with planning. In agile methodologies there are five levels of planning.
The agile values are timeless. I started using them in 1979 before they were formalized in the Manifesto.
The largest project to date I've worked on is 1091 function points in a worldwide system that had to incorporate 291 pages of policies, rules and regulations.
In the 1960s there was a "cloud" of sorts. It was called timesharing.
The manifesto and principles are even more valid today as software complexity and sources of input for product design grow. The manifesto never said that we don't value planning. We still plan, sometimes at the macro level to just understand interactions within a larger context or at a very detail level when minute details might have huge impacts on other systems or parts of systems. The overall fact that we value responding to change more still holds. This world changes even faster - especially due to the number and variety of inputs to design criteria, and if we situate ourselves into 'following a plan' we miss opportunities to react more quickly. It is more a way to poise ourselves for success than run any specific part of a product build. Long live agility!