Agile is not a binary state

I was on one of the LinkedIn groups the other day, reading through one of the discussions around testing and one of the contributors stated that Agile “mandates specific practices” and that if the “real world” precludes you from “doing agile”, then don’t pretend you’re doing agile. I was sorely tempted to comment, but the discussion had already become a little heated, as measured by the length of each successive comment. So instead of further stoking the flames of argument, I sat back and had a think about it, reading through all of the opinions in the discussion as it got further and further off-topic.

The argument boiled down to what each person’s perception was of the nature of “Agile”. Some see it as a collection of practices, which are, in an ideal world, inter-related. I did write a while ago about this, saying that “the processes work best as a whole”. But, if you do not have the infrastructure, the software architecture or the tools to be able to implement continuous integration for example, does that mean you are not agile and should come up with a new name for whatever it is that you are doing? Interestingly this same fella also said that Scrum is more of a management/planning framework than a practice framework, which almost made me choke on my lunch.

So, I am stating my opinion here quite clearly – “Agile”, as defined by the Agile Manifesto, does not mandate any practices at all. It does, however, provide guiding principles. Mandating practices is in the arena of Agile Methods, of which Scrum, Kanban, and DSDM are but a few. Even then, most practices are strongly encouraged, but hardly mandated. Perhaps the exception to this is XP, which is heavily defined by a few (very good) practices.

It is my belief, that “Agile” is not a binary state. One cannot say that a person or an organisation is or is not Agile, but only how Agile they are/are not; how far they are along their agile journey.

I believe that at the root of all that is Agile, there is just one fundamental defining necessity – frequent feedback. Most of the accepted agile practices are there to promote feedback. Think of stand-ups, user stories, sprints (iterations), retrospectives, pairing, continuous integration, etc – all exist in order to promote feedback. We can think of this question of our ‘Agile-ness’ as being defined by how good we are at obtaining and acting on feedback. Feedback gained through iterative development, collaboration with the customer, frequent integration, automated testing, etc etc. So, if you don’t have a fully-engaged Product Owner available whenever you need her, does that mean you’re not Agile? What if you don’t use user stories?

If, to be considered Agile, one had to implement (and be good at) all of these practices at once, transition would fail a lot more frequently. In fact, trying to do so may be the reason for some failures in agile adoption. The important thing is to understand why Agile works and use those practices that can successfully be adopted in order to further your ‘agility’, progressively and at a pace that the organisation can cope with. And to constantly strive to do better.

About these ads

About aterny

Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
This entry was posted in Agile. Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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