Agile principles don’t always appeal to a client who wants a fixed price project, but they should, because the end result will be a better product.
When I first started writing software back in the early 90’s the approach used for managing the projects was the Waterfall Method (https://en.wikipedia.org/wiki/Waterfall_model). It’s a reassuringly structured process involving lots of documents and a series of well-defined stages defining a pathway which starts with the requirements. When one stage has been completed the project moves on to the next stage. It was likened to a waterfall because there’s no way to go back to a previous stage.
I had heard of and read about Scrum and Extreme Programming (XP) throughout the noughties but it wasn’t until I took a contract at Man Investments in the City of London in early 2008 (bad timing) that I first worked in an agile team. Until then I had assumed that Agile processes only worked for small teams working on small, non-critical systems. But here was a £100M turnover hedge fund with 100+ developers over multiple teams running software projects without a fixed plan.
The basic principles of Agile are that requirements are expressed as stories – and there are dozens even hundreds of them. ‘Stories’ are given an estimated size (time taken to deliver) and a business benefit or value. These 2 factors allow the stakeholder (not the developer) to prioritise them. The stories are worked on by developers in priority order, for a fixed period of 2 to 4 weeks. The product is then delivered as usable software. The process repeats. New requirements can be added into the project at any time and existing ones re-prioritised or discarded.
When I’m speaking with new clients about projects, they have two main concerns: they get a system that works for them, and it comes in on budget i.e. there’s a price and it’s fixed.
There are a few problems with this mindset however…
The client and the supplier are immediately in opposition because the client wants as much as they can get for their money, whereas the supplier is inclined to deliver the exact requirements, or at least their interpretation of them, and no more. This divergence of goals can’t foster a collaborative approach.
I’ve worked in dozens of teams on scores of projects over the last 25 years and one thing I’ve learned is that many requirements are emergent and can’t be nailed down at the start of the project journey.
So the additional requirements that become clear during the process have to be additionally charged for and that leaves a bad taste. The corollary of this is that there will always be some features which seemed like a good idea at the start of the project but are never used.
So what is the answer to this conundrum? Well if the client is in a fixed-price mindset there aren’t many!
First of all, to give a fixed price I need to estimate the minimum and maximum number of days that I expect the project to take given initial requirements. Multiply the maximum figure by my day rate and get to a price which is not optimal for my client but which will minimise my risk.
An Agile figure CAN still be fixed price but would be a fixed number of days too. So, I would estimate the number of days on the basis of a guesstimate around the amount of effort the initial requirements will take me to fulfil, with a bit of flex to allow for change.
Fundamentally though I would be encouraging my client to shift to an Agile process offering both of us greater fluidity and flexibility to deal with change.
Author: Ian Bate is a Salesforce Consultant and Developer with over 25 years experience of working in IT.