The NOT Agile Test

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.

About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

4 responses to “The NOT Agile Test

  • KentMcDonald

    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.


    • theitriskmanager

      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!


  • Risk Adjusted ROI of Agile versus Waterfall | The IT Risk Manager

    […] 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 […]

  • An Agile Risk Management Framework | The IT Risk Manager

    […] 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 […]

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 )

Facebook photo

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

Connecting to %s

%d bloggers like this: