Are Agile projects a blank cheque?

Agile budgets are becoming more popular because they allow organisations to make steady progress whilst adapting to the changing world around them. But is this a good thing?

No guarantees of anything

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 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?

Why does anyone buy agile?

The world changes faster than you can build software. Don't believe me, think about this:

• Has your organisation changed any of its priorities recently?
• Have any competitors launched new products or services?
• Have your customers changed any of their habits or behaviours?
• Has your organisation changed any internal processes or working methods?
• Has the economic climate changed?
• Have any new laws been passed that affect your industry?
• Has cybersecurity just become a concern? 
• Has technology changed? Perhaps a new model of the smartphone on the market? Or a new operating system update? 

The list goes on. There's a lot of change out there. It turns out that software projects have to adapt to change too. This is so that they fit the world they exist in, and your changing industry.

To cope with change, you need a process that allows you to adapt to change as you go. 

Another reason to buy an agile process is that organisations build software 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.

But I just want certainty

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 the waterfall model. It works for projects with few unknowns. Business transformation projects aren’t usually like that.

Is it really a blank cheque?

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 a lose-lose.

How does agile address the blank-cheque risk?

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 react to new insights. Here are some of those feedback loops:

• High levels of communication between you and the developer
• Avoiding unnecessary work by a constant focus on what brings value to the business
• Learning from progress, and feeding that new knowledge into the product
• Seeing budget consumed vs actual progress, and feeding that into next steps

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.

 

Doesn’t this require a lot of trust?

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

Risks for your developer

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.

Your choice

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 phase 2.