Am I on an Agile project? – A litmus test

You may be sponsoring or involved in a project that is calling itself an 'Agile' project. In this post I talk about the misunderstandings and confusion that often seems to surround the use of the word Agile in projects and I propose a quick litmus test for trying to work out whether your project really is 'Agile'.

Doubt on what constitutes an Agile project

I had a dawning realisation half way through a recent conversation. I was talking with someone else, let’s call them Jill, about the technical and management practices that were being used in a project and the relevance of them to the problems they were facing.

The conversation was going perfectly well with both of us believing that we were on the same page and, to be fair, in the most part we were. I realised however that while I was talking about practices and how they were being applied independently to solve problems, and that all of the practices we were talking about were practices used by agile teams in an agile context, the project itself was definitely not what I would define as Agile. And yes, the capital 'A' was intentional. Yet at the same time, Jill was talking as if the reason all of these practices were being used was to have an 'Agile' project and that she was in fact already operating within the context of one. There was clearly some doubt as to what constituted an Agile project.

The Agile project litmus test

I would therefore like to propose a simple litmus test (and this is just one option, there are plenty of others that I or someone else could come up with, but I like this one because it’s simple). The test is as follows:

If everyone on the project team left at an arbitrary point in the project’s planned life cycle, would there be something in use by (and of value to) end-users, at that point?

If the answer to that question is ‘yes’, then I would wholeheartedly agree that the project was an Agile one. The clue is in the name. In my opinion, it’s called Agile for a reason, which is that it provides agility to an organisation. Now I admit, the litmus test above is pretty black-and-white. If the answer is yes, then the project, and the organisation running it, has true agility. Continuous Delivery as a methodology, where, as the name suggests, value through software is continuously being delivered to the end-user, would pass this litmus test.

Shades of grey

There are shades of grey though, or purple I suppose, since it’s a litmus test.

There could for example be an initial 'start-up' period, during which there would be no value to end-users, but after the start-up period it could be stopped at any point and it would still have value. This would still provide the organisation with agility with respect to the project, albeit to a lesser degree than the litmus test.

Another example might be a project team using Scrum. Scrum is one of many Agile methodologies and seems to be the most popular at present, so let’s put it to the test. Scrum as a process again provides agility to an organisation in that at the end of every sprint (regular 1 to 4 week period) the organisation could choose to terminate the project and still have a useful, useable end product. This is obviously less agile than being able to terminate at any point since the organisation only has whatever was delivered at the end of the previous sprint, so they could waste up to a sprint’s worth of work, but it’s still significantly more agile than waiting until the end of a project to deliver anything.

Business agility

Whatever the project structure and set up however, is it 'Agile' if there isn’t the business intent for agility? I think the answer is that ‘yes’ a project can be agile to varying degrees in that its setup can enable business agility, though one might argue that there’s no point trying to if the business are not in a position to take advantage of that capability.

Agile technical practices and better management ≠ business agility

Business agility has nothing to do with which technical practices or methodologies are being used on the project, nor does it have anything to do with whether the project team is being managed well. An awful lot has been included under the Agile umbrella that frankly is just either better management or more competent technical capability, more on this in my next post.

You can definitely set up a project and a team to make it incredibly hard to be agile, but the opposite doesn’t magically imbue your business with agility. That’s a business need and a business problem. Even if your project passes the litmus test in this post at any point in its life-cycle, if the business isn’t using that flexibility inherent to your project, by stopping it early once sufficient value has been delivered, or by re-prioritising and experimenting with different features, then the business itself doesn’t get any more agile as a result of your project being an “Agile” one. In that respect we, as IT professionals, are just the enabler.