Thursday, July 14, 2005

On agile development

I will be changing jobs in a couple of weeks. This wouldn't be anything to brag about if it weren't for the huge contrast between them. From managing IT in a state agency in a EU country to helping to let the whole world talk for free (that's Skype for the unknowing amongst you). From a strictly regulated and rigid environment that has been very successful in terms of delivering software to a free-flowing and agile environment that has also a shining success to present. Thinking of it, a question rose:

When doesn't it make sense to go agile?

By agile development I mean production of software according to the Manifesto for Agile Software Development and no I don't think there is something like purely agile or rigid methodology. Don't get me wrong, I am a huge fan of XP and I have been trying to implement things like small iterations and release planning but we ended up with something rather contrary to the Manifesto. Surprisingly enough, it works.

Could it be enforced specifications?
Working for a state agency in a EU country means that lot of the development resources go towards creating software that is either supporting a centrally agreed upon business process or has to talk to similar software in other member countris. In both cases you usually get delivered a pile of binders full of functional specifications and test scenario that have to be meticulously followed. Hence, no user stories, no tight customer envolvment (and sometimes it's all chinese for them, too) and no change. By the way, the purists among you should actually try to read 300 pages of functional test cases to understand what a system does :)
On the other hand, you get the best acceptance tests you can imagine and they sometimes even come with automation tools. Also, getting to know the system together can really draw the team together so customer envolvment can be achieved. The specifications usually do not cover how the system should look upon the screen and there are always things that are either not needed or have to act a bit differently because of the legal environment so there could actually be room for some change after all. Ergo, the enforced specifications alone can not be the reason not to do agile development.

Could it be the sourcing model?
As a state agency you are not free to choose whom you work with or how you choose them. Instead, you have to follow the procurement laws that tend to come bite your ass as soon you don't pay attention. Ever seen a deadline closing on your 1 mln euro project while a crappy CMM level 1 company is protesting your whole tender dossier in court? Also, unless you want to start arguing with all kinds of enforcement agencies ("what do you mean, collaboration over contracts?"), you have to be able to specify the whole project (including time schedule and budget estimates) in the Terms of Reference and, even worse, stick to it.
Even if you do the whole thing in-house you still have to live with the people you have. State officials are rather well protected (at least around here) and rather badly paid so assembling a good team might prove difficult.
Doesn't sound too promising for agile development does it? Actually, it could be done. There are ways to get a long-term framework contract going so you can build trust that feeds the collaboration, people can be trained and it is usually possible to shield the individuals and interactions from the cold breath of the tender process.
Once again, this can't be it.

What else?
As developing good tax and customs software has not been an easy task, there are lot of other difficulties that could be used to argue against the use of agile methologies in state agencies. However, if inspected closely, most of them turn out to be of purely technical manner or could be overcome with some well-directed effort. Hence, the answer must lie somewhere else.
It seems that it all comes down to the organizational culture. Governmental agencies usually have rather high centralization and/or formalization (google Roger Harrison to get an idea what i'm talking about) creating a mostly role or power based culture while agile development assumes orientation towards achievment and support (low centralization/formalization). So we end up with a rather worn-out statement that you should always choose the right tools for the right task. In our case, choose the development methodology to mach your organizational culture and, to answer the question stated in the beginning, it does not make sense to do agile development unless your whole culture supports that kind of thinking. Simple isn't it?

No comments: