In 2004, I was working for a company where the developers talked a strange language – about Scrum and XP – and it was nothing to do with Rugby Union or Windows but it did have something to do with sprints…
That was my first encounter with Agile software development methodologies. Not being a coder, I haven’t done a huge amount of agile development, with the infrastructure projects I’ve been involved in generally being run using a traditional “waterfall” approach.
These days, things are different. There’s a huge push for Agile projects and the UK Government Digital Service’s Service Manual even says:
“You must use the agile approach to project management to build and run government digital services.
Agile methods encourage teams to build quickly, test what they’ve built and iterate their work based on regular feedback.”
Agile and government services: an introduction
There’s also a lot of confusion in the marketplace. Colleagues and clients alike are using the word “agile” in different ways. And there’s an undertone that agile is the one true way and waterfall is bad.
No!
Agile/agile/agility
Let’s start off by comparing uses of the word “agile” (in IT) and what they mean:
- Agile (big A) often relates to a methodology – for example APMG International’s AgilePM project management methodology or the AgileBA approach to business analysis – but really they have their roots in Agile software development, with the Agile Manifesto, written in 2001.
- When we talk about being agile (small a), it’s a mindset: the approach taken. Literally, being able to adapt to change and to move quickly. We might use Agile (big A) approaches to help increase our agility (small a).
- Agility is about reaction to change. Many business want to be agile. That doesn’t mean they only run projects with Agile approaches. It means they want the ability to flex and change in line with business requirements.
- And then there’s the UK public sector. Specifically Police, who for some reason refer to what the rest of us consider to be remote/mobile working as agile working. That’s just an anomaly.
So that’s Agile/agile/agility sorted then. There are Agile frameworks/methodologies/approaches to delivering outcomes in a more agile manner, to increase organisational agility.
Agile=good, waterfall=bad?
Now waterfall. If Agile, is the one true way, waterfall must be old hat and avoided at all costs, right?
Not at all.
Agile projects work well for quickly creating a minimum viable product (MVP) and iterating development – for example as a series of sprints. They are great when there is a known problem but the requirements are less clear. The solution can evolve in line with the definition of the requirements. The requirements may change as the solution develops: respond to market changes; adapt to new requirements; fail fast.
But some projects are less defined. In a 2018 blog post, Matt Ballantine (@ballantine70) uses a fantastic 2×2 diagram to chart problems (x-axis) and solutions (y-axis). In the diagram (not reproduced here for intellectual property reasons – i.e. it’s not ours to publish!), Matt:
- Refers to Unknown Problems with Unknown Solutions as tinkering. That seems fair – if you don’t know what the issue is, then you can’t have a solution!
- As for Unknown Problems with a Known Solution. That’s nonsense.
- Agile fits in the Known Problem, Unknown Solution box – create a minimum viable product (MVP) and iterate until you find the answer,
- You’ll see though, that there is a place for waterfall project management. Waterfall works when there is a Known Problem and a Known Solution. Instead of constantly iterating towards an end, work out the steps to go straight there. It will almost certainly be more efficient. Waterfall projects are based on the golden triangle of time/cost/quality (which together define scope). A known deliverable (scope) bounded by how fast/cheap/good you want it to be – and there’s always a trade-off.
So there we have it. Agile is not a silver bullet and there is still a place for waterfall projects.
What to use, when?
In my line of work, Cloud Transformation might appear to use a combination of Agile and Waterfall approaches. We might create a virtual datacentre in Azure or AWS and take an iterative approach to migrating workloads but that’s still really just Waterfall with incremental delivery – even if a Kanban approach is used to inject some urgency! Similarly migrating batches of mailboxes to the cloud is just iteration, as is a programme that’s adopting Office 365 workloads one by one. An Agile approach comes into its own when we think about Business Transformation, or Digital Transformation, where we can define an MVP and then use sprints to iterate development of a set of new business processes or the digital tools to deliver those processes in a new way.
Further reading
For a clear definition of Cloud, Business and Digital Transformation, see my blog post from last year: “Digital Transformation – it’s not about the Technology“.
[This is an edited version of a post that was originally published at markwilson.it]
