Slashdot Mirror
World's Biggest 'Agile' Software Project Close To Failure
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?'"
But it might make it clear that it will fail much earlier and then at a lower cost.
Agile assumes you have smart, talented, dedicated individuals doing the work. Then again if you have that pretty much anything works.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Just because you're agile, doesn't mean you crap daisies and unicorns. I often see inept upper managers latch onto agile as the latest magic bullet which will solve all their problems with no other changes on their part. Except they keep all the micromanagement bits, discard all the engineer empowerment bits and hand their scrum team a year's worth of priority 1 stories to implement in the next sprint. Good managers will likely be successful no mater what methodology they use, bad ones will likely fail no matter what methodology they use and the ones in between will have mixed results no matter what methodology they use.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
All Agile methodologies really are are different ways of implementing the Spiral Model of development. If used correctly, any of them can work fine. Unfortunately, that's only in theory. In practice, Agile generally becomes an excuse to use Code and Fix, which is the worst methodology and the most prone to failure. Beware anyone who claims that Agile is the solution to anything.
You wouldn't understand it.
You would exploit it.
You wouldn't do anything to make it better.
You would waste time complaining about everything.
Burma Shave!
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.
Agile, unlike everything else in the world, is the perfect silver bullet. There can't be anything wrong with Agile. The seminar even said so.
The most important thing is tight iterations. If a 2 week sprint fails, then it is not that big of a deal. If a 2 year death march fails? Someone's getting fired, since its the equivalent in agile-land of failing 52 sprints straight.
But is it two weeks sprint down a dead end? For a project this size, agile is like trying to build a skyscraper first as a one story building, then two story building, then three story building and so on. Apparently you're making great progress the first sprint and you have a shack up, that's 1/100 floors done already. Except it doesn't work like that, so sometime around the 20th floor you've got people all over the first 19 trying to build in extra support columns and stronger walls and propping up the foundation. Things grind to a halt and you're not making any real progress. Then the orders come to get moving and you start going upwards again more and more rickety until eventually you find the straw that broke the mule's back and it all comes crumbling down.
Agile is nice if you're close enough you can start delivering actual features that would belong in the end product at the end. In practice it often means you build the first iteration with string and duct tape planning to replace it with something more solid on the back end in time, but I think everyone knows how that goes - the string and duct tape has a tendency to stay because that part is "done". Of course hindsight is always much easier but agile I feel lacks foresight, we do this now to meet our sprint goals and then if we need to change something to meet our next sprint goals, we'll deal with that then. In practice, there's not time to go back and rework things every time you figure out this should have been done differently.
Live today, because you never know what tomorrow brings
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.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
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.
The trouble is, you can have software that runs and passes some tests, yet still does not meet all of the mandatory requirements for the project and therefore may have no value at all in the real world. You don't get any credit for meeting 90% of the mandatory requirements on a job like this. The idea that having software that runs and maybe passes some tests has some sort of inherent value might be the biggest fallacy perpetuated by the whole Agile movement. It's just not true, and therefore neither is the claim that agile projects can't fail as a result.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.