Government should extend agile development for IT A report from the Institute for Government calls for a new approach to the way the government spends £16bn each year on technology. In its report, titled "System Error: Fixing the Flaws in Government IT", the cross-party think tank says that ending the "big business IT contracts" that lock government in will require a new dual …
Agile development practices are just as much of a lock-in as pre-planned specifications. It's about picking the right approach for each project.
Private businesses love the agile development philosophy because it blurs the finish line for project delivery, and allows for on-going billing of time to clients. Agile development has positive attributes for handling highly dynamic projects so it definitely has a place in some scenarios. Just not all scenarios.
"All departments should review governance, project approval processes and legal arrangements to ensure that they can be made to work with agile projects."
This will be a standup meeting right? or a nice weekly meeting for several hours eating cake and biscuits?
Dont think I've seen much evidence of Agile public sector working. They judge performance on the number of meetings they can hold.
I'm far to busy to make a decision I've got meetings to attend.
Please learn large IT project management lesson number one: large IT projects almost always fail. Only when this is fully understood can any progress be made.
Break projects down, try to stage the development, aim to produce specifications not products, look at existing technologies.
It takes the legal niceties to a place most suppliers and departments don't really want to go, with unbounded contracts that require both sides to trust each other. There is also a fear that if an Agile project goes wrong and moves to litigation, then both sides feel they won't be able to defend their position with a forest of paper that shows what was requested and so on.
At a technical level, it's blindingly successful, in my experience, at delivering pretty much what the customer wants when they want it. It helps concentrate the customers mind on what they really need and anything that's a nice to have or a personal desire tends to get sidelined.
DSDM as one of the Agile methods uses timeboxes.
So every project has a definite end, only the requirements are in flux (I know, I know).
One of the problems is that the Agile methods are software development methods in contrast to project management methods, hence do not cover the complete project management cycle.
Besides that minor quibble there are some criteria which have to be met in order to do a software development project in Agile style (Scrum, DSDM...):
a) not a lengthy list of legal requirements
b) availability of the user
Interesting to see how that pans out...
And another point to b) even if the users can make themselves available, they need a certain 'enlightened' view point as well (Process Awareness, anyone?)
I've seen a couple of public sector projects that were developed using agile methodologies. They both failed horribly. The main problem being that when the developers said "please prioritize these requirements so we can timebox them" everyone agreed that they were all top priority and had to be completed in the first iteration. It sort of went downhill from there.
Agile development certainly has it's advantages[*], but it's perhaps telling that the Wikipedia page for it states that "Large-scale agile software development remains an active research area". And I'd suggest that government contracts are generally as large-scale as they get!
For instance, one of the key statements of the Agile manifesto is "Working software over comprehensive documentation". That'll work well in an environment with tens of thousands of users with heavily varying IT skills...
Wikipedia also suggests that "Team size is typically small (5-9 people) to simplify team communication and team collaboration. Larger development efforts may be delivered by multiple teams working toward a common goal or on different parts of an effort". However, with non-comprehensive documentation and the probability of requirements change/rescoping, there's a high risk that the teams will experience problems in coordinating their development activities.
Also, the idea of rapidly delivering iterative slices of functionality is great in theory, but can cause problems: if you're delivering changes to an existing system, constant change can be very disruptive and costly, both in terms of customer buy-in, system outages and user training. And things get worse when you're replacing an existing system - users are unlikely to use/buy into the new system until it's feature set is on parity with the old system, thereby negating all of the benefits of the iterative development process.
Just to be clear: while the above may all sound negative, I think agile development is a good way to deliver functionality. I'm just not convinced it's the best way to handle large-scale government contracts...
[*] I've been involved in both small and large-scale agile developments - the latter involved an external customer, an international userbase and a six-week rolling deployment schedule. We kept things running relatively smoothly, but the logistics and processes were horrendous to manage, as you have at least 3 releases to monitor/manage at any given time: the one being developed, the one being prepared for deployment and the one which has just been deployed...
Agile - and other development methods for that matter - work best with small teams doing small projects or 'atomic' project elements (e.g. an ORM or model layer). Large scale projects do not have to be large scale developments - they can be collections of small projects with pre-defined, fixed message/interface boundaries agreed in advance.
The biggest issue is then one of overall governance (as always), but the 'governors' in this case should not get involved with the innards of each system - just with the tested/warranteed deliverables (you know, like 'real' customers).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
