The key benefits and costs to Agile software development

Equinox IT has delivered many New Zealand software development projects. Over the last four years we have used agile approaches for software development and we have found this a very successful way of working. In our experience using agile has many benefits and some costs and we summarise some of the key ones here:

Benefit: being responsive and flexible to change

Normally when you set up a software development project, you get funding, sign contracts, prepare a detailed project plan and set everything up. Once these are in place change becomes hard because you’ve got to change everything.

Using an agile software development approach, you still need to do all the same things you would on a traditional project, especially planning. Agile does not mean you don’t plan, it means that you plan in smaller chunks of time, which is more practical. It’s easier to do accurate planning when you are only planning for say a two week horizon from where you are. And every two weeks you get the opportunity to re-plan without having to restructure an entire plan for whole project. This allows projects to be much more flexible and accommodate change.

Benefit: owning the outcome

Often what happens in traditional projects is that the team who actually writes the code, tests the software and produces the end outcome is not necessarily involved at the time of planning, estimating, scheduling, and sequencing. They don’t get to have their input. They don’t get to say that it doesn’t make sense to develop component A before component B. They don’t get to apply to the planning process the benefits to their experience or what they learned on the project. Ultimately they become consumable resources as opposed to genuine contributors.

Using agile the team who is implementing the software is intimately involved in planning, including the planning of each sprint or iteration. They are more in control and contribute to how the work is done. This helps with people’s motivation and they feel they have a greater stake in what they are doing. They own the work and the outcome that is being delivered.

Benefit: delivering greater value to the business

Agile approaches encourage regular contribution during software development from the business, and this involvement influences the way that development goes. For example, when it comes down to a choice between feature A and feature B, then the product owner, representing the business, gets to choose which is more valuable for them. In this way, agile software development approaches create greater opportunities to take business value into account.

Furthermore, as stated earlier the ability to accommodate change using agile approaches often results in a software solution that is better aligned to what the business needs. In traditional software development projects you quite often end up developing features that are not used or are of a low value because you said you would in the plan, and you stick to the plan even when more important things come up. Even if your plan was perfect and you implement things at the rate that the plan said, all the way through, if other things come up during the project, then you can’t incorporate those without either dropping something else or extending the budget and timeframe. With agile you can insert new requirements into the backlog and if these deliver greater business value you can prioritise them ahead of other requirements or stories at next sprint, which for many agile projects is no more than two weeks away.

Cost: reduced sense of certainty

If you are starting a new project with a new team using agile you don’t know how fast the team will work and how many sprints or iterations it’s going to take them to achieve the functionality. The approach is foreign to the team and so often project teams need to do a sprint or two before they can tell the business how long it’s going to take to complete the whole project.

With this level of uncertainty, how do you convince the people providing the cash, (i.e the client or your senior management) that they are going to get what they want for the money they are spending? It’s pretty hard to do.

Often in this situation traditional fixed price approaches will be applied to create certainty (though it is debatable how much certainty you get when you expect to have to use change control to be responsive). This puts all of the risks onto the project team by saying “okay here is the budget we are going to give you and there’s no room to change”. The problem is that cynically, this motivates the development team to do the least amount of work possible to meet the stated requirements, regardless of quality and whether or not this actually delivers the required business value. Similarly, it motivates the client or the business to try and sneak in new features for the same fixed price, especially if the requirements are high-level or vague. These are just the wrong motivations.

With agile projects it is ideal to have a contractual structure that drives the right behaviour - to deliver the most business value for the money that is available. This may require a change in mind-set for many decision makers who are used to expecting to know exactly what they will get for the investment made.