Agile: Transformative or tragic

Agile. That wonderful promise of a brighter way to deliver. “Let’s do Agile – everything will be faster and cheaper, and we can change everything and still have a better product at the end of the day!”

Too often the promises made around ‘doing agile’ are the very coffin nails that will see it out of the door months later as a fad and a failure. So let’s start by saying what agile does not promise on the tin:

Agile delivers a faster solution: A complex solution will still probably take a long time to deliver. It probably won’t be delivered faster.

Agile gives you a cheaper solution: Talented people and useful software still costs as much as if you were using any other methodology. It probably won’t cost less.

Agile is easy: As a process it can be adopted easily enough, as a culture you’re going to have to work at it. It’s not as easy as ‘just letting the IT guys get on with it’.

What senior management need to know about Agile

Agile is a way to bring ALL interested parties together during the course of a delivery, to help prioritise effort based on the business value that will be achieved by investing the effort to build something. The more layers you put between you and the building, the more likely you’re not going to be happy with the output – in terms of costs incurred, functionality delivered and the time it has taken.

From and IT perspective, delivering a solution according to agile principles means that the IT team will work closely and regularly with the business to build the product. It’s a partnership, in which the business is very engaged and committed to the solution. This commitment is made by providing an empowered Product Owner from the business to join the delivery team. The Product Owner is there to represent the interests of the business, prioritise the features according to the value that they deliver to the business and provide clarity to the development team when required. They are not the only people involved from the business.

One of the awesome parts of delivering in an agile way is the ability to regularly see what has been delivered and to provide early feedback. You don’t have to wait until the whole solution has been built before having your say – at which point months of effort will already have been spent. You’ll get the opportunity to see progress every couple of weeks or so.

This means you can get a very good idea of a few key metrics:

How well the solution fits your idea of what should be built;

How quickly the team is working;

What the level of quality is like; and therefore

Gives you an idea of costs – in money and timescale terms.

Now don’t misunderstand me – you’re not going to attend the first demo and know that the solution will cost x-amount of dollars and be completed in y-number of months. But after the fifth, tenth, fifteenth demo you will have a better idea of where the costs are heading. And estimating costs for IT solutions is often a best guess, so having a good idea is a great result.

Who should be involved?

The best answer I can suggest here, is anyone who has an interest in the outcomes of the project. If you’re using this solution to underpin a key part of your strategy, then you’ll probably want your very senior management involved. How often should they be involved – well, that goes back to the first point we raised. The longer they step away from the delivery the more likely they will be surprised in some way at how it progresses – whether in terms of functionality, costs or timescales.

It’s a judgement call on your own time and the value of this project.

So is Agile better than Waterfall for us?

That’s about as useful as asking whether fruit is better at filling you up than chocolate. It depends on your organisation’s appetite for either.

I would argue that Agile is great if you want to remove the mystery of IT delivery. It gives you every opportunity to understand what has to happen to fulfil the needs of the business. Additionally, it correctly places the ownership of defining the costs and benefit of spending effort on the business area that is asking for the solution/ product.

Too often I’ve heard that IT is to blame for over spending and running late. That seems an easy way to blame IT as some external party who should have known all the facts up front – including the changes that the business came up with during the delivery, the re-prioritising that happened along the way, the delays in getting questions answered, the changes in procurement, the changes in third-party components…

Let me just say it here: Giving any sense of costs and timescales for an IT delivery of any complexity at the outset is a ‘best guess’. Agile just seems better equipped to deal with the reality that this is a guess, than waterfall. However, if you like big documents being created up-front and paying via change control, Waterfall could be just the thing for you.