‘A Rose by any other name?’

That’s not Agile!

You haven’t dotted the I’s, crossed the T’s and conformed to this checklist! You’re not following dot point 27 of document three! Agile is only for software development! Every time I hear statements like this it perturbs me greatly, they are usually repeated with such conviction that I know I have to set about demystifying these rumours lest they continue to grow.

Agile is not an ISO standard or a check list to be followed blindly for the sake of it.

It’s simply a framework, if you like an umbrella term for a set of values and principles that have been shown to improve efficiency, productivity, and quality. Agile is not just a software development methodology though, it’s a way of working that builds on a set of values and principles to deliver business value and manage risks.


Agile methods are adaptive; they have frequent checkpoints and feedback loops that are used to manage and reduce risk. It’s pragmatic; if something doesn’t work it can and should be adapted.

Agile can be used for all sorts of teams and environments as well as being able to be used at the governance level for portfolio management and at the project level for delivery.Its’ strengths lie in the core values and principles and we should take time to remember them.

The Values:

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.

(Source: www.agilemanifesto.org)


The full set as well as the values is clearly expressed for you in the Agile Manifesto . There are twelve of these, here are just a few.

  • The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Working software is the primary measure of progress.
  • Agile teams welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

There it is, nothing more, nothing less, then if that’s the case, why choose to use Agile?

I believe that we as Agilists choose to use it because:

We want to support teams as they learn to ‘do more with less’

We want to enable competitive advantage through innovative solutions

We want to improve the speed of delivery and the quality of deliverables

We want to deliver solutions our customers want

We want to be value added partners at the table

We want to work in a safe to fail environment

We want of celebrate our successes ,no matter the size

As Agilists we shouldn’t become swept up in the dogma of process (again remember the manifesto value: ‘Individuals and interactions over processes and tools’) and remain Agile pragmatists, not evangelists.