Agile development: a quick case for and against

In digital transformation, the debate on agile vs. waterfall still rages after all these years.   So what are the headline arguments for and against using agile? 

I tend to use it for Programmes that aren’t up against the clock; or resourced with big bucks budgets to meet a demanding deadline. My main arguments in its favour would be:

The business sees it all happening. You can check back in with your stakeholders every fortnight, giving them something new to chew on, test and examine. They will be highly-engaged in the evolving solution – and they’ll see tangible progress as you head for the finish line.

 It builds stakeholders’ confidence. Stakeholders see what’s happened in the project and know what is going to happen next. They understand the hurdles you’re clambering over and any tricky problems get on their radar early, so come as less of a shock. They also see a lot of problems solved within a fortnight, giving them further reassurance that it’s all going to be OK.

 he stakeholders can’t send it off track. People will often worry that agile delivery allows the stakeholders too much influence on the project. First I’d say, hey, these people are the customer, and we all know what the customer never is. They must be allowed to describe what they want and judge whether our efforts meet that need. But second, more pragmatically, you can mitigate any risk of mission-creep by using skilled business analysts, who translate between the business and the developers and who are drilled to Stay Focused On What’s Important at all times.

 The business benefits from being involved. Agile is well-known for making a lot of demands on the business, asking stakeholders to commit vast amounts of time to development solutions. And yes, you will undoubtedly have to ask for a lot of their time. But instead of resenting that, the business tends to see the benefits – they’re getting what they really want; they’re seeing opportunities to develop the organisation and streamline processes as they go; they understand the system and how it could be further evolved in future.  Sometimes, they even believe their IT is going to be a growth-enabler, Heaven forfend!

 It can keep going. In truly agile delivery, your changes can be in a state of permanently-continuing. It always gets better.   

 However…

Agile is easily misunderstood by the business. Because this type of development involves the business in seeing your workings-out, it can be misinterpreted and then can develop a reputation for being a solution made on the hoof.   You will need really good communication programmes to explain that we are not “making it up as we go along” or “launching before it’s ready” or “getting the business to solve all IT's problems”.