"Agile is expensive" - discuss...

I was surprised recently when I was told that "Agile's ok, but it's expensive". That was a first for me. I'd never heard anybody say that before. What could possibly have possessed them?

It's the sort of statement that sets my mind racing. What could I have missed? Is it perhaps true? After all, many say that perception is reality. It was no good, I was going to have to think about this further.

So, here I am, thinking... is Agile expensive?

First, let's understand the basic premise - "I thought 'it' was going to cost X, but 'it' ended up costing X+Y and I got less (of 'it') than I expected.". If indeed that is your reality then I can certainly sympathise. However, can you attribute that failure to being Agile? Isn't this just a classic example of project overspend, de-scoping and, quite probably, time overrun?

Perhaps being Agile has somehow exacerbated the situation? Perhaps the innate ability to embrace and respond to change has been so successful that the only logical conclusion is project failure?

Let's walk through a simple example. Assume at the start of the project I want 5 features delivered and the estimate is 5 person weeks of effort. The team diligently produces the first 3 features, expending 3 person weeks, which are then presented for feedback. Naturally some changes are discussed and prioritised. Being Agile, the team responds. After a further 2 person weeks of effort (reaching the original budget), the team presents the 4th feature, plus the prioritised changes. More changes are approved and the team then expends 1 further person week to complete those...

STOP! Look at what just happened. Because we responded to the changing requirements, we only got 4 out of 5 features delivered for a cost of 6 rather than 5 person weeks. At the micro level, the team took the appropriate direction and delivered the most important features, but at the macro level we have (perceived) overspend and de-scoping.

In my experience, at the iteration-to-iteration micro level, this type of occurrence happens all the time. So, if you're not rolling that up and communicating appropriately at the macro level, it's no wonder that Agile can be perceived as being expensive - "I'm getting less and it's costing me more" screams out, even though what you're actually getting is what you want, not what you originally thought you wanted.

No doubt my example is one of many reasons that might explain the 'expensive' comment. However, I can definitely relate my own experience to that example and, I think, it is an important reminder that managing all stakeholders and their expectations is every bit as important as being Agile in the first place.

Delivering More for Less

How many times have you been asked to 'deliver more for less'? Plenty, I would guess. For many of us, given the current economic conditions, we are being asked to do this yet again.

Reviewing and optimising the cost base continues to make good sense, but is that enough? Are we sure that is what we're really being asked for?

In my experience, one of the key areas where IT can demonstrably make a difference is on project delivery. Completing a project late, over budget and with reduced scope can be the norm for some organisations. Even failing on only one of these factors can result in IT being given a black mark. The better we are at producing the right solution, at the right time, for the right cost, then the more likely we are to be deemed successful and, compared to our previous track record, seen to be delivering more for less.

Some areas where hidden costs can start to occur include:

• Having bottlenecks in the development process
• Working around architectural constraints
• Misunderstanding requirements and/or their business value
• Delivering a poor quality solution into test
• Adding too many 'bells & whistles'

Tackling these issues, perhaps as part of a broader transformation programme, will ultimately improve your delivery capability, your track record and your contribution to the bottom line.