In this blog post we will explore the Agile approach to software development, contrast it to the more traditional approach and try to summarise the pros and cons of each, so you can make up your own mind as to what is right for your project.  Check out our video.

A Note About Balance

Whilst I will try to make a fair argument, I do have strong opinions on the subject. I am not going to aim for some arbitrary balance. My conclusions are based on my personal experience over many years in the field and there is no point pretending that I don’t have a preference.

What are the Alternatives?

Traditional software development, sometimes called the Waterfall model, is a step-by-step process where each phase is completed one after the other:

• Planning
• Design
• Building
• Testing
• Acceptance
• Maintenance

This approach involves planning the desired outcome in detail before work begins and setting clear “acceptance criteria” for how those outcomes will be evaluated. It prioritises accountability and contractual compliance over flexibility in response to change.

In contrast, Agile software development is a more flexible, step-by-step approach. Where all the phases are compressed into short cycles, called sprints, typically 2 – 4 weeks in length.

With each sprint aiming to deliver a small, usable part of the software, which the client can test and provide feedback on. It prioritises flexibility and continuous improvement over rigid contractual compliance.

What are the Pros and Cons?

Before we dive into the Pros and Cons of these two approaches, we need to understand the goals of the people involved, because these are what the Pros and Cons will be judged on:

The Client’s Goals

The client comes to the project with an idea about what they want to achieve (Project Aims) and they have an expectation that a software project could help them achieve those aims.

The Client wants to know:

• How much will it cost?
• How long will it take?

The Developer’s Goals

The developer comes to the project with their understanding of what the Client wants (Project Aims) and needs to provide a quote for how long that would take to deliver, and how much it will cost.

The Developer wants to know:

• What skills and experience will be needed?
• How long will it take to build?

And this is where the fun and games begin …

How Can We Make Everyone Happy?

Now we understand the goals of the people involved, we know what is required to make everyone happy. All we need to do is ensure that both the Client and the Developer have the same understanding of the Project Aims:

• The Client knows what they are going to get
• The Developer knows what they need to deliver

Both approaches aim to reach the same happy place, where expectations are aligned, but they do it in very different ways, based on very different assumptions.

So How Do We Align Expectations?

The traditional approach aims to align expectations by putting in the work up-front to get everything down in writing:

• State what each expectation is (Project Requirements)
• Define how each expectation will be evaluated (Acceptance Criteria)
• State what the penalties are for missed expectations (Contractual Terms)

The temptation is to think that a rigid contractual process gives you more certainty and control over costs. This is great when the Client knows exactly what they want and can define clear acceptance criteria. The downside is that changes are harder to make and more costly once the project starts.

In practice, most Clients don’t really know what they want in sufficient detail for this approach to work well. In that case, it almost guarantees you will pay more overall for your project. The bigger the project, the worse this problem becomes.

What you actually get is not certainty about the overall cost, but certainty about who to blame when the cost starts to balloon. This is what exactly what happens in every single government IT project ever commissioned. Except in that case, they are very sloppy about defining the acceptance criteria, so you don’t even get the certainty of who to blame.

Is There a Better Way?

The Agile method is an attempt to overcome these problems. It aims to align expectations by a continual process of comparison and refinement. We start with only a rough sketch of the big picture aims, then:

• Plan in detail one small part of the whole
• Build that small part
• Assess how well it meets expectations

The outcome of that process could be any of the following:

• Accept this part and move on to the next part
• Refine this part to more closely match the expectations
• Modify the expectations to account for what we have learnt
• Modify the big picture

Repeat … Repeat … Repeat …

If you are not used to working in this way, it can be quite disconcerting. At first it seems like:

• I don’t know how long it will take
• I don’t know how much it will cost
• I don’t know what I’m going to get at the end
• I won’t know who to blame if it all goes pear-shaped

But the truth is, you don’t know those things either way. The traditional approach only gives the illusion of certainty. The Agile approach embraces the uncertainty. It says: I don’t know what will come out the other end, but I am confident I will be happy with it.

It requires trust between the Client and Developer, but that trust can be built up in small incremental steps. You are taking a risk, but it is a small risk initially. You are not committing to a huge amount of up-front work but to one short sprint at a time. You can see the progress at each stage, test it, refine it, adapt your own expectations as you go.

In the long run, the overall cost will be lower, because you haven’t wasted huge amounts of time planning and re-planning, building and re-building, etc.

A Hybrid Approach

What I have described here could be called the extremes of the two approaches.

For most Clients, there is a limit to the level of contractual compliance (legal fees) you are comfortable with. Just as, there is a limit to how much uncertainty you are willing to embrace. Many times, you need to justify the project budget to a manager, board of directors or funding body, etc.

In these cases, I would say most practical cases, you will start with a written brief and an estimate of the time and cost for the project. Because who wants to go to their boss and ask for an unlimited budget for an unspecified project?

My real advice, is that you need to understand the overall challenge: How to align expectations? That both approaches have pros and cons in relation to that aim. Then you can embrace elements from both approaches and steer the right course for your project.

A Final Note

For more about this topic and an (almost) true story of what a typical software development project looks like see: Will ChatGPT Replace Software Developers?

If you would like to speak with our software team and discuss this topic further contact us.