I am increasing concerned about the projects that people are calling Agile. I encountered an “XP” project that took eighteen months to deliver the first release, and nine months for the second. Even worse, the project was the flagship Agile project for the organisation. I encountered a project that has yet to deliver a single release after two years that claims to be Agile because they are using Scrum. I think anyone involved in Agile would agree with me that these projects are NOT agile.
Whilst defining an Agile test would result in endless discussion and debate, I think we can all agree on a test to demonstrate that a project is NOT Agile.
Here goes. As a minimum, an Agile project…
- Delivers demonstrable value each iteration.
- Sustainably delivers a high quality product.
- Releases in short iterations.
All three are needed because any two can be gamed. e.g. You can deliver value quickly but not high quality or sustainably.
A project is NOT Agile if it does not do all three. Doing all three does not mean that the project is Agile.
Some more detail on what these mean…
Delivers demonstrable value each iteration
Each iteration delivers value to the end customer or the business. A stakeholder (not necessarily the product owner) can see the value delivered. Delivering software is not enough, especially if it does not deliver value to anyone.
Sustainably delivers a high quality product
High quality means high quality code (with no bugs) that performs according to user needs and has no user experience bugs. Sustainable means the teams are not sprinting and collapsing, but rather have a sustainable pace that they can maintain indefinitely.
Releases in short iterations
The project delivers value in short iterations. Each iteration is a month or less. I choose one month because that was considered best practice over a decade ago and should not be considered a difficult goal by any stretch of the imagination. In reality, many organisations deliver value several times a day.
The key measure for the iterations is the lead time rather than the time between releases.
So there you go. A test to show things are NOT agile, rather a test to show things are Agile. Note that there is no mention of Scrum, XP, Safe or Kanban, or any of the Agile practices. It is the qualities of the project that determine whether it is Agile, not the practices ( Hat tip to Alistair Cockburn ).
This thinking is not mine, it is the result of many hours of discussion, especially with Marina Oliviera, Tony Grout, Alan Hawrylyshen, Paul Hammond and many others.
The IT Risk Manager 
December 25th, 2014 at 4:50 am
Hey Chris,
Thanks for sharing your (Not) Agile Test. I wanted to offer up a couple of thoughts, potentially caveats.
First of all, I always see red flags when teams act as if their ultimate goal is “to be agile”. What their goal should be is written all over your test, but I think it’s worth mentioning that your test is really reinforcing what teams should be focusing on, and you’ve couched it in terms of whether the team is agile or not to get people’s attention and have them focus on those things.
Second, Monthly releases (or more frequently) is certainly desirable. I have run across some times that release less frequently than monthly not because they don’t think they can, but rather because their stakeholders don’t want to accept change that frequently. Granted, most of my experience is in internal IT situations where stakeholders can sometimes put up (artificial) obstacles to change, mainly in the form of having to change processes and create training. If teams find themselves in that situation, they may have to release less frequently in the short term, but also start looking for ways to help their stakeholders absorb change more frequently.
Kent
December 25th, 2014 at 7:35 am
Hi Kent
Thank you for mentioning these points.
I could not agree more with all your comments. It is the user’s option to release monthly that is important. Not a commitment on the users.
Have a great Christmas!
Chris
April 12th, 2015 at 9:21 am
[…] can be used to manage all three categories of risk better, but only if it is applied properly. A Scrum or Kanban project that only releases once a year is not managing risk (and is not really a […]
May 30th, 2016 at 3:46 pm
[…] an Agile development. If an IT Investment does not satisfy these criteria, it should be considered NOT Agile and thus managed under the existing SDLC. These categories […]