Answer: Because you can’t predict the future.

Being agile is not about “doing agile things.” It’s not a checklist of activities, pair programming, stand-up meetings, or having a scrum board. Being agile is embracing a set of values, and demonstrating those values through your actions.

The values of agile development are defined within the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Authors

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
© 2001, the above authors
This declaration may be freely copied in any form, but only in its entirety through this notice.

Again, notice there’s no mention of planning poker, retros, TDD, or continuous integration. As developers, the things we do are not what makes us agile, but instead we are agile because of the reasons we do them.

Time for some introspection:

  • Do you have stand-up meetings because that’s your process? (no)
  • If not, can you explain why you do them? Can the whole team explain why you do them? (yes)
  • Is “how the code is written” more important than writing functional and maintainable code? (no)
  • Do stakeholders (i.e. clients) attend your stand-ups? (yes)
  • Do you have “face-to-face” communication with the stakeholder multiple times per week, if not daily? (yes)
  • Do “project managers” determine when a feature will be done? (no)
  • Do testers determine when a feature is done? (yes)
  • Do you allow stakeholders to determine a feature is not done? (yes)
  • Do you demonstrate progress to stakeholder, even when development is incomplete? (yes)
  • Can stakeholders interact with the system under development at any time? (yes)
  • Do you resist changing requirements? (no)
  • Does the phrase “Change Order” get used? (no)
  • Does there exist an overall development “plan” that must always be considered when talking about changes? (no)
  • Do changes to “the plan” affect some arbitrary timeline? (no)

The answers in parenthesis are likely responses if your team behaves in a manner which embraces the values of agile. So why does it matter?

There are some universal truths that exist when it comes to software development (and in life):

  • Things will change
  • You won’t know everything upfront
  • Users (people) are unpredictable
  • Developers (people) are generally optimistic about what they can achieve short-term, and pessimistic about what they can achieve long-term

These truths are the reasons you should be agile. They represent known volatility in every project (software or otherwise). Ignore these at your project’s own peril! Don’t be agile, don't be flexible, and don't be open to change... and you allow these truths to wreak havoc on your ability to successfully drive projects to completion.

Asking “why be agile?” is like asking, “why aim for success?” Agree? Disagree? Think I'm crazy? Let me know @tyriker or @WeWriteCode #WhyBeAgile

Comment