World's Biggest 'Agile' Software Project Close To Failure 349
00_NOP writes "'Universal Credit' — the plan to consolidate all Britain's welfare payments into one — is the world's biggest 'agile' software development project. It is now close to collapse, the British government admitted yesterday. The failure, if and when it comes, could cost billions and have dire social consequences. 'Some steps have been taken to try to rescue the project. The back end – the benefits calculation – has reportedly been shifted to a "waterfall" development process – which offers some assurances that the government at least takes its fiduciary duties seriously as it should mean no code will be deployed that has not been finished. The front end – the bit used by humans – is still meant to be “agile” – which makes some sense, but where is the testing? Agile is supposed to be about openness between developer and client and we – the taxpayers – are the clients: why can’t we see what our money is paying for?'"
BTW should I mention my pet name for Agile (Score:5, Interesting)
Open Source It (Score:3, Interesting)
Agile Needs Testing? Open Source It.
It's perfect for that. Open an issue tracker, let folks dump in the requirements. Give us the backend API, and I'll work on it for free an hour or two here and there, just for grins.
Oh, it's closed source? Well, I hope it's a massive disaster and you learn your lesson. You can't pay for the brightest minds. They wouldn't be caught dead slaving away at those software houses. But let them do it "for the good of mankind", they'll be brow bashing each other for a chance to get their beautiful bit of brilliance in the code base.
world's biggest? (Score:5, Interesting)
Simple formula (Score:1, Interesting)
.
I would love to know how cheaply this same project could be done. Probably by one person. Probably a $10,000 project with the final project size 100 times smaller, run 100 times faster, 100 times more accurate. [That is what I achieved after a payroll application they tried to force on our dept. was discarded and we rolled our own.]
Future software challenges should take a government boondoggle, any boondoggle, and have contestants try to make one that actually works with one-hundredth of everything.
It is interesting that Apple, eons ago, knew that some developers were not just 10 or 20% better than others but were 1000 or more % better. Bet this government project didn't require staff to be skilled on Defender.
The total misunderstanding of Agile. (Score:3, Interesting)
Someone still has to helm this and there has to be a rather obvious set of goals and objectives to attain.
The problem I've seen with Agile, is that often, the software is being developed as it goes and to me, that's poor use of the "Agile" experience.
To me, Agile would mean that the software architect(s) know what they are doing, and have a bloody good idea of the road map to take to get there.
The "Agile" part is that for each of these goals to achieve, there is a separation of tasks and an agreement on implementation specs.
Any single team has full knowledge of the objectives of other teams and thus, this team can concentrate of their specific task and at the same time, mockup whatever is required to support their work based on any of the dependencies which depends on other teams work.
Unit Testing, Functional Testing, etc, all of that must come into play.
The Agile process should NOT be 'on-the-fly', which is what I've often seen, for that is the reason why we get delays and development costs going over budgets.
Re:Agile doesn't mean that the project won't fail (Score:5, Interesting)
Pretty much this exactly. Also, it's tough to get programmers and managers who have never worked in an Agile environment to buy into it. My company started using it 4 years ago and we still have a few holdouts despite the obvious benefits in both productivity, cost and simply a better work environment for everyone. Hell, I think the best part about the Agile process is those one or two guys on a piece of a project that never seem to do anything and could end up causing drama simply doesn't happen in a proper Agile setup since there is daily accountability and you're working on smaller pieces.
"Waterfall" -- i.e., the "old fashioned" way of doing things -- does one thing very well that Agile loses. And that thing is something that was understood for a century of large project management planning. Waterfall ensures quality with a team of varying abilities, or large teams. Agile ensures predictable delivery, but quality is very dependent on the individual abilities of the team members.
Anyone who has done large projects would know immediately that you don't do a billion dollar project with a pure Agile methodology. You simply can't get enough people who are strong enough to deliver a quality output without a very high amount of formal planning and progress gates.
The most successful large (multi-hundred engineer) projects I've seen in the last five years tend to use waterfall for the overall project, but encourage teams to run their parts of the work in an agile manner. You get the visibility into progress that way, but the formality of process to ensure you're really building the cohesive system right.
Brogrammers (Score:5, Interesting)
A lot of the 'agile' models reward talkers and people who take immediate action and can rattle off buzzwords, at the expense of more introverted engineers who like to investigate and plan before they act. In a continuously moving environment such as a social networking site, that reward system might be appropriate. In a financial back end doing mission critical work, that sounds like a disaster. So, no surprises here. One size does not fit all companies.
Re:Agile doesn't mean that the project won't fail (Score:5, Interesting)
The short(er) and honest version is that projects like that are inclined to fail, spectacularly and at great expense, whilst everyone on the job gets paid either way.
People are either accountable or not. When you have teams of "project managers" that don't know shit about shit, shoveling ridiculous and disparate feature changes into the (often offshore) dev shops inbox, while their programmers simply crank out code to match, you're begging for the whole thing to go right in the toilet.
Large consulting firms like Accenture build their entire business around this kind of approach. The result is always a failure that costs millions (or in this case billions) of company/government dollars on a product that doesn't do what it was supposed to.
Agile/Extreme is analogous to alternative medicine (Score:4, Interesting)
Agile/Extreme programming is the alternative medicine of software development. It's a collection of mostly unrelated and sometimes contradictory concepts, the only common thing between them being lack of widespread adoption. Like alternative medicine, it has components that are useful in some circumstances. These give unearned credibility to Agile, even though they were there well before it. The problem is also similar, these components are taken to the extreme and are claimed to be universal solutions to every situation. For example, acupuncture is useful to ease pain, but no matter what the charlatans say it doesn't help against cancer. Similarly, frequent testing during development can be useful, but test-driven development is taking it to the extreme, and it doesn't work at all in for example web development. And like alternative medicine has homeopathy, Agile/Extreme has their own set of ideas that are total bullshit like pair programming.
Re:Agile doesn't mean that the project won't fail (Score:5, Interesting)
Actually Agile would probably handle mediocrity quite well, at least making it apparent.
What agile really sucks at is handling the political aspect of the project, because simply agile requires complete honesty and honesty does not scale very well above a small team. In a very large project involving loads of teams, management is a lot closer to a poker game and you don't win at poker by showing your cards to all the players.
Re:Agile doesn't mean that the project won't fail (Score:5, Interesting)
I hate to break it to you but "fully defined requirements analysis" is a pipe dream filled with rainbows and unicorns. I have never, not once, seen a requirements document that accurately captures exactly what the system will do.
Well, I've written them, and I've never had a project fail.
One example involved interviewing
i) the owners of the company
ii) an executive from each department
iii) a "regular joe" representative from each department
This became a 40+ page project specification, which was signed off by all stakeholders and became the contract.
Then this document was fed into a series of code generation engines, which created hundreds of thousands of lines of code. This was all done with an eye towards allowing various professionals to go away and do what they do best without getting held up waiting on each other or tripping over each other, filling in the missing functionality in the generated code.
That system is still in operation close to a decade later, organizing the working lives of thousands and serving the needs of millions.
Now I work in Agile. I hate it. I'm always having to check with other people constantly to move forward, I never get in the zone, there's a lack of clarity and vision, and I feel like I'm getting stupider each day and I'm not producing my best work.
Been there, still there (Score:5, Interesting)
Over my career, i've worked in the UK Benefits Agency processing claims, i've worked in their IT departments, i've worked for the outsourced departments later supporting them, and i've worked for a software company which loves agile (but will do waterfall if pushed).
The problem here isn't waterfall/agile. The problem here isn't .Net/Linux.
The problem here is the parties involved. On one side you have a government agency where people obtain seniority largely through age, not skills, and the main skill that is relevant is passing the buck when things go wrong and taking the credit when things go right (really, this is government agencies through and through - not to mention, most people with real skills/brains get out as soon as they can). On the other side you have the dinosaurs of development (not necessarily age, but sizewise).
Somebody earlier in the thread stated this whole project could have been delivered with much lower cost, with just a few devs, in a much shorter time. I'm 100% in agreement with them. The only real complexity of most government systems is the labyrinthine workflows, but they are documents and strictly followed in their paper variants, its just a matter of getting an understanding of this and turning it into software.
My recommended development approach for this project would have been as follows:
1) Hire some decent devs. They don't need to be hotshots, what is being developed is fairly simple from a technical standpoint. Mainly guys who can follow a spec.
2) Take a bunch of people who actually do the work for real, the paper pushers. Take them down the pub and get them rat-arsed. Listen to them bitch and whine about all the idiotic things they have to do in day-to-day operations.
3) Take notes of their bitching! It may help if you are drunk!
4) Any requirements given to you through the official channels are probably worthless. Dump them. They will simply mislead you from what is actually required.
5) Build the system based on what you learned from the drunk employees.
6) Demo it to the stakeholders and hand over.
7) Contract fulfilled.
Oh, and of course.... 4) Profit... erm...
Re:It is based on Linux.... (Score:5, Interesting)
Just because the failure of one project is caused by .NET does not mean that a project not based on .NET is going to succeed. In fact, traditionally 80% of software projects fail.
This project is clearly failing for the second from last reason. It is also failing because it is not an "agile project". An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay if you use some "semi agile" process like scrum or immediately any point if you use some true agile process.
Once you deviate from "Working software" for more than a couple of sprints (everybody can make a mistake) then you are no longer doing agile. I have seen so many "agile" projects which seem to define "Working" as meaning something like "a prototype which would never work at full scale" and so they have never addressed the major problems of their class of system.
If they are "billions" of pounds down whilst doing agile, then they should have already delivered plenty of working systems and have hundreds of happy users. In this case they are a "success" even if they were a bit slower and more expensive than some other projects. If, however, they really haven't delivered anything then what they were doing was an unplanned disaster using "agile" as an excuse for not having a proper plan.
Whilst I know that the "waterfall" method of development is famed for it's failures. Whilst I know that those failures are spectacular and huge. I really don't see how you deliver, for example, 5% of a working mobile phone network. You just have to have a big interlocked plan with a working phone, transmitter, backend, management and interconnection all planned together. I don't believe that such a thing can be done in a true "agile" way and pretending that you are doing it in an agile way is a dangerous fantasy. Only once you have a working network can you start to improve it in Agile increments.
Re:Agile doesn't mean that the project won't fail (Score:4, Interesting)
Upper management prefers this. I don't think this is anywhere near universal at the lower levels- they realize that the top 10% of developers save their asses. Then again, this is why I work for small companies and startups and not anything outside the tech industry- management at small places is smarter than that or fails quickly.
Re:Agile doesn't mean that the project won't fail (Score:1, Interesting)
Re:Agile doesn't mean that the project won't fail (Score:4, Interesting)
Small companies like Facebook?
You're citing a company whose motto is "Move fast and break things", a company that is indeed infamous for breaking its software all over the place and introducing changes its users don't want, as evidence that cowboy programming works at scale?
Facebook have been shrewd about their marketing, and they've developed probably the most effective lock-in/network effect strategy in software history, and they've also been lucky at a few times when it counted, and they're successful as a result. Please don't confuse any of that with technical merit, which really has very little to do with their success or failure at this point.
As George Shultz would say... (Score:4, Interesting)
There are three things I have learned never to discuss with people... Religion, Politics, and Agile.
But why? (Score:2, Interesting)
I have often wodnered why exactly it is that big projects, paid for by the public, always seem to fail so spectacularly. Over the years I have made some wild guesses, and some of them may be plausible:
- They are too ambitious. It is a well known phenomenon that complexity very easily becomes hyper sensitive to small variations of the premises, even if the components are very simple (like Mandelbrot). It would probably be a lot easier if they started by making a simpler tool - instead of trying to calculate everybody's entitlements everywhere in accordance with whatever the current rules, perhaps one could start by making a tool that solves one or two of the most burdensome problems social workers face, and design it so that it can be easily extended later, when it has proven its worth.
- They keep changing the specifications. This is partly because legislation that governs the input to the system changes unpredictably.
- Those in charge may be highly qualified, but with the wrong qualifications.
- They didn't spend enough time understanding the problem they wanted to solve well enough.
- They lack the will to really see it through.
Perhaps the solution for complex projects is to be found in the world of biology; an eco-system is a very complex entity, but it works because there is room for failure; individual components can fail without endangering the whole, and this in fact helps to evolve the whole over time.