When not to use agile
This is the third of a series of blog posts introducing agile to people who haven’t worked in this way before. It’s based on my last three years of reading, learning and practising agile ways of working. I’m no expert, but I’ve got a few ideas that may help get you started.
Let’s recap. In a previous article, I said:
Responding to change is the definition of agile. Our base assumption when working in this way is that change will happen. That what we’re working on is inherently uncertain, unknown or unknowable.
Agile ways of working are great when we don’t know for sure what we’re going to deliver, how long it will take or how much it will cost.
But in some cases, we have a clear idea of what we’re expecting to deliver. If it’s been done many times before, then we may be able to give confident estimates of time and cost. When this is the case, there’s little value to taking an agile approach — we’re not expecting to have to respond to change.
There are a few examples when agile ways of working can be downright irresponsible. As Jonathan Kerr points out:
There are bits of your organisation that have to run in a DevOps fashion, with long-living teams that are given budget to free-wheel, create as they want, and bin 90% of their attempts. There are also bits that need to produce the same thing 99.999966% of the time.
There are functions that we expect to deliver the same thing, to a fixed standard, over and over again. They’re not novel — there are little uncertainty and few unknowns. The scope of delivery is fixed. When we’re talking payroll, banking, energy and other things we take for granted — we have little tolerance for things going wrong. Processes, governance, strong contractual relationships and clear documentation are very important.
This isn’t an excuse for treating people badly. Toyota aims to achieve uniform product quality. Their Andon system empowers any worker to stop production when a defect is found. That’s a huge amount of trust and respect for people, their skills and judgement.
It also isn’t an excuse to avoid change to established processes or products. Fintech companies like Starling Bank show you can use agile ways of working to create and improve even the most regulated processes. The outcome of using appropriate methods can be some of the best user experiences in the industry.
Using appropriate methods is one of Simon Wardley’s universal doctrines — and one of the first he suggests to adopt. The best method depends on the stage of activity. A system can have things in different stages of activity and so different methods can be applied.
So before rushing to apply agile ways of working to absolutely everything, first think about what you’re expecting.
Use agile ways of working if you:
- Expect to deal with uncertainty or the unknown
- Want to invest a fixed amount of time and money
- Need to learn and change rapidly
Use alternatives like Six Sigma or Lean if you:
- Expect to deliver the same thing, many times
- Have a strict standard,
- Can confidently estimate the time and cost
This is part of a series of blog posts introducing agile to people who haven’t worked in this way before.
