Agile projects often make executives nervous. This isn’t surprising because an agile project has no fixed deliverable and no fixed cost, which means a lot of risk.
It’s like going into a restaurant and being asked to pay £50 without any guarantee you’ll get a nice meal or your two glasses of wine. Who in their right mind would buy that?
Because agile projects have no fixed scope, it makes it difficult for development teams to commit to a time and cost. So you don’t know what your product will look like at the end of the journey, how long that journey will take or what it’s going to cost.
Why would you agree to that?
People usually build software because they want to innovate. Innovation is R&D. If you try and plan a 6-month innovation project where the scope and budget are nailed down in the first month, you’re going to struggle to let new insights and understanding influence the outcome. R&D involves repeating a design-build-measure-learn loop. And each insight can cause a change in the plan that makes the project bigger or smaller, more expensive or less expensive.
People buy agile projects because the positives outweigh the negatives for their own situation. They buy them because they roughly know where they need to get to with their software project, but haven’t learnt enough to know all the answers. They need to learn on the job. They want to avoid committing to their first guess and finding out it wasn’t quite right. They need flexibility.
If you want the certainty of cost and time, then you also need to be able to communicate exactly what you want upfront.
The thing with creating business-changing products is that you have to sweat the details. And being certain about all those details is very difficult, mainly because you’re probably entering new territory in your business.
So you can end up spending months or years specifying what you want and trying to get a developer to give you a guaranteed cost. During all that time, you haven’t delivered anything or reaped any rewards. This isn’t how leading businesses are transforming themselves.
This approach is called waterfall. It works for projects with few unknowns. Business transformation projects aren’t usually like that.
No, everyone needs a project estimate to put into their budget. And most agile teams can come up with an estimate based on an initial rough scope of work. A collaborative best first guess at what will do the trick, if you like.
The scope will change and so will the cost. But at least you have a sensible target to aim for, ideally produced by a seasoned team of experts who know how to estimate.
When you get this budget approved by the board, your developer knows it’s in their interest to make sure you get results within that budget. Otherwise, you’ll take your business elsewhere and there will be no success stories to shout about. It’s lose-lose.
It doesn’t make the risk disappear, but it does mitigate it adequately.
Agile only works because it contains a few very important feedback loops. These feedback loops put the customer in control of spending and, to a large degree, project success. They embrace frequent change and reacting to new insights. Here are some of those feedback loops:
It’s fly-by-wire, not fire-and-forget. And all this leads to you making more informed decisions, and therefore increasing your chances of success.
Conversely, a fixed scope/fixed price contract seldom requires this, because all the thinking has been done upfront and therefore you only need to see progress to make sure things are on schedule. If you don’t need to do innovate and have it all worked out, then you don’t need agile.
Yes. To get all this flexibility and know that you won’t be led up the garden path, you need to trust that your developer will protect your interests. You need to trust that they have the people and processes in place to safeguard your budget, give you complete transparency and focus on things that actually benefit your business. And you also need a team that understands the premise of agile, starting simple, communicating regularly and
There is a risk for your developer too. Selling this agile approach is difficult.
It’s much easier to promise you a fixed scope and fixed price, knowing that you’ll be racking up the “change requests” in no time which can send costs north. So by even trying to sell you agile, the developer is going to have a harder time winning your business.
Naturally, you can buy what you’re comfortable with.
Do you want a developer that is optimised for the real nature of a digital transformation project?
Or do you want the questionable safety blanket of a fixed cost and scope, with the risk of falling into costly the “change request” trap as soon as you realise you made a bad decision. Or even worse, build a fixed price project that doesn’t quite work, and not have the budget to fix it in a phase 2.