PM Articles > Alan S. Koch > Is the Agile Manifesto Dangerous?

Is the Agile Manifesto Dangerous?

by Alan S. Koch, PMP

Magdy Hanna recently asked me to read his "Close Look at the Agile Manifesto after 13 years" and give him my reactions to his analysis. Among the more provocative things he wrote was that he thinks the Agile Manifesto is "dangerous" because it encourages abuse and misuse of good engineering practice. In Magdy's words, "I hope our young software engineers do not see the Manifesto! If it were within my authority, I would have prevented those who are new to agile from reading it."

Magdy, everything you write about Agile methods is true. Many people abuse the concepts, misunderstand their responsibilities, and end up hacking rather than engineering software. As you point out, the same thing happened with RAD. And in fact, the same thing has happened with every method, model, framework and approach that we have ever devised -- including structured project approaches and the CMMI.

Agile methods are abused by people looking for an easy way to do something that is inherently hard: developing good software.

But the problems cannot be blamed on the methods; they are the result of human foibles, not methodological failures. Agile methods are abused by precisely the same people who would abuse RAD, RUP, Structured methods, CMMI or anything else. These people are looking for an easy way to do something that is inherently hard: developing good software.

There is also a lot of truth that Magdy omits in his analysis -- that Agile (and RAD and CMMI and Structured approaches) have all been implemented as intended in many organizations, and in those cases, each has provided real value by helping those organizations to improve their projects and the software that comes out of them.

The successes naturally must be attributed partly to the good practices that each of these approaches promotes. Agile practices (done as intended) provide great value, as do RAD, CMMI, Structured and any other practices. But the "done as intended" part points to the other success factor -- that these successful organizations approached whichever model, method, approach or framework they were referencing in a disciplined way.

No approach forces discipline, so none can guarantee success. But at the same time, with discipline, some degree of success can be achieved using any of them. With the requisite discipline, the degree to which an organization is successful with a particular approach is dependent on how well the practices of that specific approach fit with the organization. (That, by the way is the premise of my book, Agile Software Development: Evaluating the Methods for Your Organization -- that by critically looking at your organizational context and the types of projects you undertake, you can determine which Agile practices would be most valuable for you.)

The Agile Manifesto is not at all "dangerous" (as Magdy states). Its statements are entirely appropriate if you read what it actually says and suppress any knee-jerk reaction to the way it is written. (It is written in a rather provocative way, to be sure.)

In order to properly frame the Manifesto, you must focus on the postscript, "While there is value in the items on the right, we value the items on the left more." With that statement as our guide, we will interpret the Manifesto to be saying:

  • We value processes and tools.
  • We value comprehensive documentation.
  • We value contract negotiation.
  • We value following a plan.

But because those things are only the means by which we achieve more important ends:

  • We place higher value on individuals and interactions.
  • We place higher value on working software.
  • We place higher value on customer collaboration.
  • We place higher value on responding to change.

In other words, you are not Agile if you don't put a high value on individuals and interactions, working software, customer collaboration, and responding to change. But you aren't truly Agile if you don't also value processes and tools, comprehensive documentation, contract negotiation, and following a plan.

In his foreword to my book, Kent Beck (author of Extreme Programming Explained) wrote, "Agility in software requires iron discipline -- absolutely fixed time schedules; rigid and high quality goals; and a devotion to collaboration and communication."

And in another foreword, Mark Paulk (Lead of the SEI team that created the original CMM) wrote, "I have had the pleasure of seeing the Software CMM® become a de facto standard for the software community -- and I have seen it abused in ways that astonished and saddened me ... The agile methodologists are concerned that some adopting these new ideas do not really understand what an agile methodology is -- and it is not ad hoc, chaotic programming ... The cruel reality in using any model or method is that they have to be applied with common sense and good professional judgement."

Magdy specifically highlighted documentation as an issue with Agile methods -- and yes, that is a common abuse point. But successful Agile teams do document what they discuss.

Face-to-face communication is in fact the most effective and efficient method of communication. (This is long established and well-documented in communication theory.) The downside is that it is fleeting and people's memories are subject to relatively quick decay, which is why face-to-face communication needs to be captured in some durable form for future reference. Successful Agile teams do that.

On the flip side, teams that are using more traditional (non-Agile) approaches are often guilty of not documenting anything. But what is even more wasteful is the many traditional teams that I have had contact with who spent hundreds or thousands of person-hours writing documents that were ultimately ignored and unmaintained. Requirement and Design specifications that didn't keep up with changes, so the final product didn't even resemble what was documented. Project plans that were inaccurate forecasts, never adapted to what actually happened on the project. Even test plans that documented good intentions that never materialized due to time crunches.

The enemy here is ignorance of good practice and what is required to implement it.

The Agile Manifesto really isn't the culprit here, Magdy, so it isn't an appropriate target for our angst. The enemy here is ignorance -- ignorance of good practice (traditional, Agile, or whatever) and ignorance about what is required to implement it. You and I (and many others) have dedicated our careers to educating, training, and guiding software professionals toward good practice. That is the best we can do.

Kent Beck ended his forward to my book with an insightful statement: "In the end, agility is simply a measure of software development. How agile is yours? Not very, taking years to respond to change? Very, responding in hours or days? Your software development lives somewhere on the continuum already. You don't get to pick 'agile' or 'not agile'. The question is, is your agility enough for your organization and if not, what are you going to do about it?"

Helping organizations to figure out what they should "do about it" and how to do it is exciting work!

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.