You’re probably not agile after all.  I know.  Shocking isn’t it.  But please read on before you jump to a conclusion.

Oh, and of course if none of what follows applies to you then – well – good luck. Perhaps you’ll be prepared to post a comment and tell us what part of Utopia you work in.

1. For starters – we live in a world with budgets

Obvious perhaps, but it seems to be alien to many in the Agile movement. They seem to think that money for the project appears by magic with no preconditions, and we start with a blank canvas. The reality is nothing of the sort. Don’t get too depressed though – there are occasions where this happens. Unfortunately it is all too rare.

How a project is run is down mostly to how the finances operate.

Project budgets and finance is often allocated a considerable time in advance,  and it usually revolves around financial years. We cannot possibly know the detail of what we are going to build so far ahead – even if we have a rough idea. So we must treat this entire ‘budget’ situation with considerable caution. Operating this way seems to me to be rather nonsensical in the modern world where continual change and adaptation is expected.  The budgeting process seems to impose exactly the opposite.

If you are in an organisation that operates like this, you’re really dealing with Waterfall financial management. That being so I don’t really see how you can consider what comes later in terms of projects as ‘Agile’.  What I have just described is about as far from agile as you can get. We need to recognise that how the money got allocated and the preconditions that go with it, is the key, and is responsible for many problems.

Having established the fundamental ground rule that the “allocating-the-money-to-financial-years- isn’t-agile”, we then need to explore this further from the perspective of how the money gets approved in the first place.

2. Technology and compromise – how the refrigerator got its hum

Having established that funding for a project doesn’t come out of thin air or by accident,  we need to recognise that as part of the process expectations will have been set, deliverables negotiated and so on. The question is by who? Can it seriously relate to what will eventually be built? Were the project teams even involved with the discussions?  If not, why?

Much of what goes on to get the project off the ground in financial terms will not involve you. It will have gone on in secret. Bear that in mind.

With the money comes ‘strings’. The people funding the project are (not unreasonably) going to demand a statement or definition in advance of what they will get.  This in turn leads to various different ‘up front’ analysis, design and definition tasks to provide such a statement. The agile movement gets very stressed about this. But whether we like it or not it is a necessity of getting the project off the ground.  This in turn leads to a cycle of ‘definition’, ‘design’, ‘get the funding’, ‘build’, ‘deliver’ which is really the basis of waterfall. This in turn is the object of so much of the agile movement’s criticism.

Negotiating the project’s funding can lead to compromises and design flaws.  I have written previously in these pages about an extreme example of this – the launch of the Challenger Space Shuttle in 1986.  This disaster revealed a number of quite separate – and seemingly insignificant – factors which collectively caused the disaster.  It emerged that the Shuttle itself had been designed in a way that was at odds with its stated aim of being a scientific programme.  The department of defence – a key stakeholder in the funding – wanted a way of launching secret military satellites via the shuttle. It pushed for a bigger shuttle needed to accommodate such satellites. This prompted design modifications which in effect undermined the shuttle’s safety.  If it had been designed from a purely scientific non-military perspective (as most citizens thought it had been) the Shuttle would be designed to be smaller and designed differently. Crucially, there would have been no need to use the type of booster technologies that eventually failed causing the disaster itself. Inabilities to deal with problems that emerged, were down to a combination of trade-offs between technology and funding, a unwillingness to be seen to report ‘bad news’ to stakeholders from which further funding was being sought, and an intimidation of the engineers from customers.

All familiar scenarios to an IT project, really.

Few in the Agile movement seem to recognise that a project isn’t a pot of money to do with as we see fit.   We can’t make it up as we go along.

If the ground rules and expectations of the project have been set at the start in order to please Finance people, introducing ‘agile’ techniques into a fundamentally non-agile environment later on is pretty futile. It is simply window-dressing a situation. The die is already cast. The decisions made.  The stakeholders have been told what to expect.  Their assumption is that they can sit back and wait for the miracles to happen.

3. Beware the ‘value for money’ fantasists

We live in times where people seem to expect everything to be turned into a science, and where our ability to deal with the unpredictable or unexpected or even just adapt as new facts emerge, seems to be diminishing, not increasing.  ‘Value for Money’ is one of those ideas that have crept into public consciousness as if it is science and something we can prove without a shadow of a doubt.  We are somehow expected to predict the outcome and effect of a software project in the way we can predict what happens if we put two chemicals together.  This is nonsense, and mostly originates (in my experience) from Finance departments that expect nicely boxed, predicable outcomes to everything. This is rarely possible:  People assess value for money the way they assess everything else:  Through the filtering lense of an individual world view. It isn’t science.

At this point it is important to remind ourselves that on a project we are dealing with large amounts of other people’s money.  We can and should justify this expenditure.  We can use business cases and other techniques to help, but only up to a point. Different people will have different interpretations and perspectives of the worth (or not) of a particular project or initiative.

So ‘Value for money’ exists, but only if people think it exists and it doesn’t if they don’t.  It is no more scientific a judgement than a film review or a ‘good’ meal.  If beauty is in the eye of the beholder, then ‘value for money’ certainly is. There comes a point where we must take the plunge and decide to invest because we know it is the right thing to do.

Back in the 90s I spent a lot of my time trying to convince reluctant customers that having a web site was becoming a necessity.  At the time, all manner of phrases were fired back at me to justify a ‘no’ decision: from a simple ‘we can’t afford it’ to more intellectual explanations of ‘no’.  Later, the same people that said ‘we can’t afford it’ seemed to be conjuring enormous amounts of money out of thin air to do exactly the things that earlier they supposedly couldn’t.  What changed their minds won’t have been that they started writing miraculous business plans, but a simple  acknowledgment that it is the right thing to do.  Nowadays of course, such a discussion would be preposterous, yet the basic scenarios are still being played out.  We’ve just moved on to arguing about whether we can justify an iPad app or not.  The overblown and over-intellectualised ‘Value for money’ arguments are as alive as ever, mores the pity.

4. Waterfall is as much about finance as it is about organising a project

The Agile movement have major issues with Waterfall.  Many of those who align themselves to Agile seem to think Waterfall was invented as some kind of deliberate act of sabotage to undermine the IT industry and cause projects to fail.  The reality of course is that all Waterfall is doing is reflecting how the finances work.  The basic cycle of ‘definition’, ‘design’, ‘get the funding’, ‘build’ and ‘deliver’ that I described earlier is how much of the world works.  It exists in every walk of life.  It is how kitchens get installed, bridges built, companies started.   So it is not unreasonable that people will try to apply it to IT, and furthermore it isn’t always the failure that people seem to make out.

Personally, I have every sympathy with Waterfall. I know why it is there.  It really isn’t out of vindictiveness or conspiracy.  I’m not disputing there are better ways, but that isn’t the point.

5. Rigging up a Kanban Board does not an Agile project make

If we are going to change project organisation and approach, we need to fundamentally challenge the way finances operate.  What I have described places a stranglehold on projects which is at odds with the way the world now operates.   What has brought this about are the Finance profession with their techniques which to me seem more and more outdated.   We still live in a world revolving around financial years.  We have rules like the ridiculous nonsense of having to spend all your money before the end of the financial year otherwise you lose it.  Why?  Why not just carry it over to the next financial year and use it to invest in your project?  Who benefits from practices this?   It is Christmas as I write this and it’s ironic that a version of Dickens’ A Christmas Carol was on TV earlier, because the world of finance doesn’t seem to have moved on much since the era of Scrooge & Marley.  One would hope that the new generation of students studying finance (god help them) are challenging this sort of rubbish, but sadly I doubt it.

Conclusions

I am inclined to go further in this post and suggest that most ‘Agile’ projects are actually nothing of the sort.  They are really waterfall projects dressed up with some ‘Agile’ techniques. Even then it mainly amounts to different ways of reporting progress.  If you’re blighted by lack of customer involvement during the project – something the Agile movement bemoan at some length – it’s hardly surprising when you think about it.  The customers have already been told what they will get. The budget has been set.  Why not just wait for it to arrive?

But also, what I am describing isn’t the world I would have created – and certainly not one I agree with particularly. But it is the world we’re stuck with.

There is alot about the Agile movement which is very idealistic and quite naive, frankly. But don’t get me wrong, I am all for some idealism. Much – possibly most – I agree with. I also think there is a genuine battle to be had around what I have described.  Unfortunately, the ‘Agile’ debate has so far collapsed into squabbles between different factions of the IT industry, especially around Waterfall. This is the wrong battle. We ought to be challenging the underlying causes of the issues, and the forces outside of IT such as the Finance profession, who are dictating a culture that goes against modern software development. For IT, there  is little point in the team adopting new rules and tactics if the other team, the referee and officials, plus the governing body are still playing by the old ones.

***

This will probably be my last posting of 2010.  I wish you a happy remainder of Christmas and a happier and successful new year.

Mike Dorey