To my major surprise people actually read my blog and I actually get some feedback :) One of the most useful ones was by Asko who pointed out that the Project Triangle of Death is in fact a rectangle. The corner I was missing is Quality. My first thought was to object as this aspect is included in the Functionality but after I while I got the point. Come to think of it, how often have you seen people actually considering what quality the delivered product could be? Everybody want's créme de la créme, does not want to pay for it and ends up with something rather less splendid. But this whole process of determining functional quality is rarely implicit. Yes, sure, people to project quality management all the time and even agree if you tell them that patching something together is cheaper than building anything solid. However, quality seldom participates in critical decision-making and hence deserves a place in the Project Rectangel of Death.
P.S. anybody having a suggestion for a less morbid name for this thing, please feel free to e-mail me :)
Monday, July 18, 2005
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?
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?
Monday, July 11, 2005
MTB: Haanja marathon
It was a while back (19th of June, to be precise) but I haven't come around to writing about it. The most prominent feature of this race was a total ascent of 785 m which is aproximately twice as much as an ordinary Estonian MTB marathon. for example:
In terms of organization and track preparation everything was excellent. The track combined steep slopes and woodland with gravel roads giving anough oportunities to rest. There is nothing much else to say about the race as there were no specifically dangerous sections and anyway, I was too busy pedalling uphill to note anything :)
| Race | TA |
| Haanja | 785 |
| Tallinn (Kõrve) | 415 |
| Mulgi | 525 |
In terms of organization and track preparation everything was excellent. The track combined steep slopes and woodland with gravel roads giving anough oportunities to rest. There is nothing much else to say about the race as there were no specifically dangerous sections and anyway, I was too busy pedalling uphill to note anything :)
Subscribe to:
Posts (Atom)