Why Be Agile?

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.

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):

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.