The Agile Tribe

'A Rose by any other name?'

on April 28, 2011

Author: Tony Ponton

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 checklist 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



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.

About Author: Tony is an Agile Coach, Trainer, practising Agilist and Certified Scrum Master.  He came to Agile as an IT Business Analyst on a web project over eight years ago and was infected by the sheer power and simplicity of Agile. To him, it just made sense and the flame was lit to what would become a lifetime passion.


4 responses to “'A Rose by any other name?'

  1. […] friend of mine recently posted an interesting blog promoting that agile does not require a compliance framework and asked for some review feedback. As I began my tirade back I realised that it wasn’t […]

  2. Todd Owen says:

    I whole-heartedly agree, but I am curious that you warn us to remain “pragmatists” not “evangelists”. I mean, sure, there’s no need to be self-righteous and dogmatic, but I thought the software community had already adopted the word “evangelist” to mean something a bit different to its original religious connotations. You see the job title “technology evangelist” popping up quite a bit these days, and I think it reflects the realization that new technologies need more than just technical excellence to succeed — they also need passionate supporters and advocates.

    By that definition, this blog itself would be an example of evangelism!

    • Tony Ponton says:

      Thanks for your comments Todd , much appreciated .

      I personally have concerns with evangelism and the use of the term .

      Agile was once the doyen of the software community , now however more than ever, non software teams are practicing Agile.

      Once particular stakeholder recently saw this word used in a coaching
      mission statement and immediately stated that he associated it with

      So the point I was attempting to  convey is to be sure we step outside
      the dogma of evangelising the perfect dot point adoption of Agile and
      be pragmatic about how we coach ,espouse and aid it’s adoption.

      I wrote this post after a number of these interactions with non software teams and being introduced to the

      “Oath of Non Allegiance” by Alistair Cockburn , which reads : 

      I promise not to exclude from consideration any idea based on its
      source, but to consider ideas across schools and heritages in order to
      find the ones that best suit the current situation.Hope thhis clarifies my intent and thoughts – Cheers

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s