How do you know when to use agile?

This is a really interesting question. Knowing the reasons for taking an agile approach can really help you to understand what agile is and why it recommends many of the things that it does.

To answer it, we have to take a look back at the roots of agile. For most of the 20th century, especially after the end of World War Two, the world of projects and getting stuff done was very much shaped by the work of people like Frederick Winslow Taylor and his Principles of Scientific Management. This popularised the idea that things got done better if processes were standardised and people made to follow these processes. For Taylor, there was often 'one best way' of doing things, and this could be discovered, documented and followed.

To go alongside this, the idea spread that not only could processes be standardised and enforced, but that plans for getting things done could be specified up front, with the workers then being made to follow the plan. This led to what is often called 'waterfall' project management, where plans and processes are decided up front, and then followed. So if the plan or the process fails, this is obviusly because people were following them closely enough, or there wasn't enough planning or process standardisation, right?

Well, no. Often the problem turned out to be that standardising plans and processes then sticking to them no matter what doesn't take account of the external reality. A reality where things often change, where new information emerges as the work goes along, where unexpected events occur. When these things happen, you can often find that your plan and / or process no longer works as you expected it to, and sticking to it without taking into account the new reality can cause large amounts of harm.

This is where agile comes in. Agile, as first brough together in the agile manifesto, is all about ideas like prioritising 'responding to change over following a plan' and focussing on 'individuals and interactions over processes and tools'.

So in many ways, agile is a response to complexity and uncertainty, where you can't know up front what the right thing is to build and you can't even be sure of the right way to build it. So instead of trying to decide both of these things at the start and stick to your decisions no matter what, you instead take an approach that continously test and learns, or as agile people often say 'inspects and adapts'.

So if you're wondering when the right time is to use agile, it's likely to be in those instances where you can't be sure what the right thing is to build, or what the best way is of building it. How you decide which areas of your work that applies to is up to you, but the chances are that anything you do could likely benefit from a mindset of continous curiosity, where you're constantly looking to gain feedback and make changes based on experience.

With this in mind, sometimes the best way to decide when to use agile is to do what agile recommends, and try it out, see what happens, and use the experience to decide what to do next.