Agile is not a goal

(first published on December 18th 2017 under a different name, migrated from my LinkedIn articles)

The belief that “agile” is the goal of a transformation or other improvement initiative can manifest as an explicit declaration — “Our goal is to be agile!” — or implicit, i.e. behaving/operating as if it is — “We do daily stand-ups because that’s what you’re supposed to do in agile”.

The word “agile” when used in the term “agile software development” was intended as an adjective (like the English word) to describe an approach to software development consistent with the Manifesto for Agile Software Development.

Unfortunately (at least in some respects), “Agile” became a thing. More accurately (and confusingly) it became lots of things to lots of people. As such, having a goal of “we’re being (more)”, “we’re doing” or “we’re scaling” Agile is fraught with problems.

We often make assumptions and jump to conclusions around why we are even talking about agile software development in a particular context, and what we’re trying to achieve. It’s important to recognise there are two primary high level use cases for agile software development:

Use case #1 is operational — to improve the way we develop software (as an individual, team or organisation)

Use case #2 is centred around a particular delivery objective — more specifically the continuous delivery of valuable software for a particular customer in a particular project/context

If your current context is the first use case (or at least it is the primary driver for Agile being thrust upon your situation), this desire for improvement must be coming from somewhere. Perhaps you (or your team, or organisation) create lots of defects, which creates lots of failure demand (such as support calls, time spent fixing said defects, etc.)? Perhaps you are consistently slow to deliver to market or particular customers, causing you to lose or piss off these customers, not gain as many new ones as you would like, miss deadlines, lose trust or lose ground to competitors?

If this belief resonates with you or someone (or team/organisation) you know, read on for my suggestions on how to proceed.

What to do?

1 — Identify the correct use case from the two options above

2 — If it’s improvement (use case #1):

• Identify what area of software development is primarily driving the need to improve (e.g. quality, time to market, poor responsiveness to change, etc.)
• Identify process metrics (things in your process which you can directly change) and output metrics (things you can use to measure the impact of those changes)
• Use a continuous improvement framework such as Toyota Kata to improve the thing you want to improve (via PDCA in small experiments)

3 — If it’s a specific deliverable (use case #2), in a similar, experimental vein to the approach above:

• Identify the actual objectives of the deliverable (i.e. what would constitute a valuable, beneficial outcome for the business once time/money runs out?) — you can do this by having an inception workshop, building a Lean Canvas or an Impact Map, or simply having conversations with the project sponsor and key stakeholders
• Identify high level options for achieving those objectives centred around capabilities which (you believe) will solve customer problems — user story mapping can help greatly with this
• Identify the option with the smallest, simplest, quickest path to delivering valueto a customer (story slicing/narrowing/thinning/splitting techniques will help with this) — your user story mapping activities should result in this first thin slice/increment
• Deliver the capability, and assess its impact via talking to users, getting direct feedback if possible, and observing changes to key metrics — did they shift in the direction you would expect if you were correct in your assumptions about the customer/problem/value?
• Rinse and repeat — constantly deliver customer value while assessing if what you are delivering is having the desired impact on the overall business objectives

To achieve any goal requires knowing what the goal is, why it exists and a means of gauging if you are getting closer to it. “Agile” is way too broad in its interpretation, and far reaching in its scope, to be used as a meaningful goal, but I encounter it often when helping teams and businesses.

Me: “Why are you doing X?”

Team: “Because it’s the agile process!”

or

Me: “Why are you adopting agile?”

Organisation: “Because we need the teams to be more agile!”

With Agile as the goal, you/your team/your organisation will have little hope of gauging whether any delivery or operational activities are being successful, so you will end up measuring what is far easier to measure — output (tasks/stories/requirements/use of practices/processes/etc).

I hope this article helps you get on track with establishing such concrete operational or delivery goals rather than “Agile”, which will leave everyone confused and unable to know if they are heading (and having an impact) in the right direction.

Thanks for reading! If you are looking for help with your software or product delivery, I provide agile coaching, public training (both theory and practical) up to executive management level, and more. As well as public events, I can also run training internally in your organisation for a massively reduced cost, so please ✍ get in touch.