What does the Agile Manifesto Really Mean?

Written by Paul D. Race for BreakThrough Communications, btcomm.com. Copyright © 2016 All Rights Reserved.

Throughout the 1980s and 1990s, software development consultants and managers experimented with different ways to overcome the problems inherent in 1970s-era development procedures. Because they were all working to overcome the same difficulties, many of their “unique solutions” actually overlapped.

In 2001, seventeen of these consultants and mangers attempted to identify the common ground in their approaches. Because they felt that their approaches were all more flexible and adaptable than old-school methodologies, they adopted the term “Agile” to describe the group as a whole.

Then they attempted to summarize the core values that they could all agree on. The result was the “Agile Manifesto”:

  • Valuing individuals and interactions over processes and tools
  • Valuing working software over comprehensive documentation
  • Valuing customer collaboration over contract negotiation
  • Valuing responding to change over following a plan

Unfortunately, that document, like most mission statements, doesn’t exactly provide a roadmap for how all of these high goals should be accomplished, or even attempted. What is less known is that the same group created another list that was a little more prescriptive:

  1. Satisfy the customer through early and continuous delivery.
  2. Welcome changing requirements.
  3. Deliver working software frequently.
  4. Users’ people and developers must work together daily.
  5. Build projects around motivated individuals.
  6. Use frequent face-to-face conversation.
  7. Measure progress by working software.
  8. Promote sustainable development.
  9. Promote technical excellence and good design.
  10. Keep things as simple as possible.
  11. Allow teams to self-organize.
  12. Reflect and adjust periodically.

It’s worth noting up front that each Agile approach emphasizes some of these principles more than others! But it’s also worth noting that each of these items represents some way of “acting out” one or more parts of the “Manifesto.”

“Valuing Individuals and Interactions” includes:

  • Build projects around motivated individuals. (So don’t do things that de-motivate people.)
  • Use frequent face-to-face conversation. (I.e. “standups”)
  • Allow teams to self-organize. (Give people a say in what they are going to work on next.)
  • Promote sustainable development. (That’s mostly a “code” for avoiding working conditions that eventually drive mistakes and turnover.)
  • Reflect and adjust periodically. (This is generally addressed to the team: meet at the end of each development cycle to congratulate each other for good work done and address things that could have been done better.)

“Valuing Working Software” includes:

  • Deliver working software frequently. (Short development cycles)
  • Promote technical excellence and good design. (Coding standards, code reviews, or at least comprehensive testing.)
  • Keep things as simple as possible. (So anyone on the team could troubleshoot the code if possible.)
  • Measure progress by working software (not “pages of specifications” or “lines of code” or any of the other metrics that can easily be manipulated by lazy but clever people).

“Valuing Customer Collaboration” includes:

  • Satisfy the customer through early and continuous delivery. (Let the customer see progress, even if it seems microscopic at first; it will build the customer’s confidence in your people and processes.)
  • Users’ people and developers must work together daily. (Keep the customer in the loop, to make certain that what you’re delivering is what the customer wants.)

“Valuing Responding to Change” includes:

  • Welcome changing requirements. (Establish a mechanism from the start for incorporating changed requirements into the development flow, so they’re part of the flow, not an interruption.)

When you break it out to this level you realize, that all of these “principles” are really “lessons learned” before the Agile Manifesto was created. You may also note that certain principles that are critical to some Agile methodologies are not listed at all, such as tracking progress visually.

Since the Manifesto was signed, most of the folks who signed it have tried to stay true to the second list as well as the first, with the result that some of the different methodologies are being implemented today in very similar ways, with very similar results. A few have stayed out of the mainstream, though, so if someone says they’re “using Agile,” it pays to ask which flavor of Agile they’re using.

Still, in most cases “using Agile” means that your organization plans to:

  • Increase customer engagement.
  • Improve team dynamics.
  • Reduce extensive up-front planning.
  • Release smaller updates, more frequently.
  • Monitor each feature’s progress through the cycle.

If you can adjust to this way of working, then you’re ready for Agile.