What is Agile?

Two weeks into 2013 and I’ve not blogged, in fact my last blog entry was a month ago. What’s happening? Well partly Christmas, New Year and then flu took a lot of my time. Plus, pre-Christmas my writing energies have been going into writing up Xanpan.

At first I thought my notes on Xanpan would be similar to my “Agile Reader” mini-book, then I thought Xanpan would be a replacement for the Agile Reader series, now I’m seeing it as a book format collection of writing that goes beyond Agile Reader and includes new material on Xanpan specifically. At the moment my working title is “Xanpan - and other notes on Agile & Lean Software Development”.

If you are interested in seeing this project complete please goto the LeanPub Xanpan page and register your interest. Otherwise its likely to be pushed to the bottom of my to do list.

One of the things I’d like to do in Xanpan is define what Agile is, and maybe what Agile is not. In other words, I’d like to answer the question: “What is Agile?”

After much thinking I have concluded there there is no single, short, concise, answer to this question. Rather how you define Agile depends a lot on who you are and why you are asking. With that in mind there are several perspectives you might take in answering the question. The perspectives I see are….

The Historic perspective: Agile is defined by the a manifesto and 12 principles written in 2001. As I’ve said before, the manifesto is now a historic document, it was written at a time when heavy-weight development processes (e.g. SSADM and V-Model, and most things which were ISO-9001 or CMM approved) ruled software thinking. The term “Agile” was coined to group the “light weight” methodologies.

The manifesto is like the US Constitution, and like the constitution we can read all sorts of meaning into it, depending on who you are you read different things. But there is no Supreme Court to arbitrate on whats-what. So Agile is what I say it is - or maybe, like art (“art is what artists do”), Agile is what Agile advocates say it is.

The Not the Waterfall perspective: traditional software development was largely rooted in a mindset which said “Define what you want, design it, build it, testing it and deliver it, in sequence with little or no feedback from later stages.” While (in my experience) we didn’t usually manage to follow that model we tried and when we didn’t we considered it a failure.

I think a lot of the time “Agile” is defined colloquially as “anything other than the waterfall model” but Agile is more than “not not the waterfall”. Indeed, as Laurent Bossavit described in The Leprechauns of Software Engineering, Royce’s Waterfall model wasn’t even discussed in literature much until Barry Boehm started using it as a counter example to his Spiral Model.

The Agile as Better Perspective: Similar to the The Not the Waterfall Perspective, people who hold this view want a improvement over their current (usually poor) development processes and techniques. The motivation is simply to have fewer late projects, fewer unhappy users, fewer bugs and so on.

On the one hand this view is cynical, it holds limited promise; on the other hand this is perhaps the most work-a-day view. People holding this view are looking to make their lives better and their company’s use of IT better.

In some cases Agile as Better links the Historical perspective and the Not the Waterfall perspective. I’ve seen companies that have tried hard to apply traditional waterfall based heavy-weight development approaches. In doing so companies tie themselves in knots trying to enforce a development model which doesn’t match the problems they are trying to address. For these companies the year is still 2001; just adopting a mindset which is not Waterfall based is itself a massive improvement.

The next three perspectives are best explained together, in this diagram: The State of Agile Perspective, The Methods Perspective and The Toolkit Perspective

I often find that when I talk to developers and testers in an company they implicitly view Agile as a toolkit of techniques which might be applied - The Toolkit Perspective. Ask them “Are you Agile?” and they will answer by referencing the practices which they use or don’t use.

Conversely, talk to managers - especially senior managers - and they are concerned with company Agility. Their perspective is the end result, - The State of Agile Perspective - they don’t care whether a team do stand-up meetings, iterations or not, they care about the Agility of the company. Indeed, some Agile practices - e.g. Test Driven Development - may appear downright unAgile to them.

How you define the “state of Agile” depends on what the company is trying to do. In general it is something about being responsive to customers - which implies you actually know what customers want in the first place so that must be included too. It is something about delivering fast and generally being quick on your feet.

Talk to another group of people - middle managers mainly - and The Method Perspective appears. Those who take the Methods view are concerned with which Agile Method (Scrum, XP, DSDM, etc.) the company is following. These methods are largely composition from the toolkit, ready made combinations of tools. According to this view following one of the methods will deliver the state of Agile.

(I touched on the these three themes in my Objective Agility presentation (PDF) (Objective Agility on SlideShare) a few years ago and a piece of the same name in Modern Analyst - Objective Agility: What does it take to be an Agile company?)

Almost last but definitely not least there is The Learning Perspective of Agile: I continue to believe that Agile is fundamentally an implementation of Organizational Learning concepts. The idea that all teams, departments, companies learn and those who are able to harness positive learning and change in technology/solution, problem/business and process domains will succeed. He who learns fastest wins.

Organizational Learning is present in one form or another in all Agile and Lean approaches but it is seldom front of stage. Indeed to bring it too far forward would be self-defeating. In working with clients I find that taking the learning perspective of Agile allows me understand and approach the most difficult issues.

For me organisational learning provides the theory and underpinnings of Agile. I should stop there, I could carry on but I’d need a book to do this perspective justice - fortunately I wrote just such a book a few years ago: Changing Software Development: Learning to be Agile.

Given these different perspectives the question we need to ask is: “what is not Agile?”

In many ways this is a more difficult question to answer because while any self-appointed authority can define what is Agile nobody has the authority to declare things unAgile, there is no Supreme Court of Agile. Personally I find it hard to see how business process re-engineering, CRM and ERP systems, virtualisation technology and domain specific languages can be regard as Agile but I have seen all of these cited as Agile tools or enablers.

Which perhaps leads us to the final and most cynical perspective on Agile: The Marketing Perspective.

Agile has grown and changed since it first appeared nearly 12 years ago. It has grown and changed in that time, and with no-one to police the brand it has become all encompassing. Come up with a good idea now and marketing demands you brand it Agile and put it under the umbrella.

There is no one right answer to the question “What is Agile?”. Each of these seven perspectives are good answers and they are not, on the whole, incompatible.

My advice is: when someone says they want to “be Agile” or “adopt Agile” or anything else “Agile” it pays to look beyond the label and ask: “what is Agile to you?” and “what are you looking to achieve?” Unless you know the context “Agile” is meaningless.