Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

World's Biggest 'Agile' Software Project Close To Failure

Soulskill posted about a year ago | from the be-careful-not-to-learn-anything-from-this dept.

United Kingdom 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?'"

Sorry! There are no comments related to the filter you selected.

Because (1)

Anonymous Coward | about a year ago | (#43821123)

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.

Re:Because (5, Funny)

PNutts (199112) | about a year ago | (#43821331)

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!

Re:Because (1)

LifesABeach (234436) | about a year ago | (#43821517)

Now I've spit coffee all over my keyboard!

Re:Because (2)

Big Hairy Ian (1155547) | about a year ago | (#43821799)

One question. How many of the Devs were at home sitting playing WOW and just outsourcing their tasks to a small Dev shop in China?

Its been done before :D

Agile doesn't mean that the project won't fail (5, Informative)

kthreadd (1558445) | about a year ago | (#43821131)

But it might make it clear that it will fail much earlier and then at a lower cost.

Re:Agile doesn't mean that the project won't fail (2, Informative)

Michael Monaghan (2932285) | about a year ago | (#43821183)

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.

Re:Agile doesn't mean that the project won't fail (5, Insightful)

Anonymous Coward | about a year ago | (#43821259)

...since there is daily accountability and you're working on smaller pieces.

So that means it's impossible to do anything big or that requires extended planning? Sometimes a developer needs to be left alone for a week to come up with something good. Regimenting the process into days and forcing a daily bullshit update is just abusive to the creative process.

Re:Agile doesn't mean that the project won't fail (3, Insightful)

tgd (2822) | about a year ago | (#43821395)

...since there is daily accountability and you're working on smaller pieces.

So that means it's impossible to do anything big or that requires extended planning? Sometimes a developer needs to be left alone for a week to come up with something good. Regimenting the process into days and forcing a daily bullshit update is just abusive to the creative process.

You've already failed at project of that size if you're letting a developer be "alone for a week to come up with something good". A developer's job, in a project like that, isn't to come up with something good. Their job is to implement a specific piece of functionality in the specific way defined by the people whose job is to have the broader view of the project.

Some developers may not like working in that environment, and they shouldn't be working on a project that size. Cowboy programming is for small companies. (And, for what its worth, I've worked directly with many hundreds of engineers in the last couple of decades, and the happiest engineers are the ones who recognize which kind of project they like to work on, and avoids working on the other.)

Re:Agile doesn't mean that the project won't fail (5, Interesting)

Anonymous Coward | about a year ago | (#43821519)

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.

Re:Agile doesn't mean that the project won't fail (4, Insightful)

Anonymous Coward | about a year ago | (#43821579)

Agreed. Agile is a WHOLE lot easier to get wrong than it is to get right. The benefits it promises come only from the synthesis of ALL its components. Project managers who think they understand it, but don't quite get it, wind up tweaking it just a bit (in a way that seems to make perfect sense) and that tweak completely undoes the approach. The effect often isn't instantaneous...it is felt over the life of the project.

Be that as it may, for some types of projects Agile is flat out wrong.

Agile is awesome when you can't afford to frontload your development costs, don't really know which features will get a lot of use and which ones will just collect dust, and when your project manager actually understands agile. But there is a very severe drawback when you are building a huge feature-rich juggernaut of a system that needs a very sophisticated and precise back-end: refactoring costs go through the roof.

Agile proponents often get angry when one says anything bad about it, and yell about how writing maintainable code is one of those elements of agile that you can't sacrifice. And I agree. And the refactoring cost gets more evenly spread that way, but remains astronomically high for complicated systems. Here is exactly why:

Every feature you add to a back end system, no matter how well coded, increases the complexity of the system.
The more complicated the system, the more expensive it is to add a new feature to it.

Waterfall can give you some savings in this specific department because the initial system design already includes the final (or near-final) level of complexity, so you don't pay the extra cost of adding a new feature to an already existing system over and over again. Waterfall still has costs in that some of those features may never be used, and hence are wasted effort, and also misestimation and requirement changes are more expensive and put a project past deadline. But for huge systems, these costs are preferable to the project-destroying costs of agile refactoring.

There isn't one approach that is right for every problem, and agile is not the right approach for this one.

Re:Agile doesn't mean that the project won't fail (4, Funny)

LifesABeach (234436) | about a year ago | (#43821585)

This should be modded Score 5, Funny. Your thesis is that everyone knows what thery're doing, except the programmer that can't make it work, and is honest enough to tell you so.

Repeat after me, "The King has no clothes." It just doesn't get old.

Re:Agile doesn't mean that the project won't fail (0)

Anonymous Coward | about a year ago | (#43821889)

Cowboy programming is for small companies. (And, for what its worth, I've worked directly with many hundreds of engineers in the last couple of decades, and the happiest engineers are the ones who recognize which kind of project they like to work on, and avoids working on the other.)

Small companies like Facebook?

Re:Agile doesn't mean that the project won't fail (4, Insightful)

Virtucon (127420) | about a year ago | (#43821273)

I agree but the daily accountability is still something that a lot of hard core developers don't buy into. The "leave me alone" mentality still prevails in big shops. There's also a lot of gaps in Agile and IMO while Stories are great they are not a substitute for fully defined requirements analysis. Not that they can't go hand in hand but I've watched lots of Agile projects fail because of incessant changes in vision and invalidation of stories subsequent to their definition by other stakeholders. The key stakeholders either don't pay attention or louder voices who have really no relative bearing to the project somehow get suddenly important. These are often folks with something to gain by holding things up or creating confusion. That is always the problem in all projects but it seems more acute in Agile because "hey, we have a process that can allow for these changes." Ultimately the team gets into a tail chasing situation and nothing of value (to the key stakeholders) gets built and the project gets cancelled. On the successful projects that I've worked with in Agile, there's strong stakeholders, good architecture keeping the vision in place and project management that keeps things well orchestrated. Without those in the mix, it'll fail just like all software projects.

Re:Agile doesn't mean that the project won't fail (2, Insightful)

SirLurksAlot (1169039) | about a year ago | (#43821843)

There's also a lot of gaps in Agile and IMO while Stories are great they are not a substitute for fully defined requirements analysis.

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. Even if it did it would be true for all of 5 minutes before the product owner/user changed their mind and redefined what they want. The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want. I know what you're going to say next: "If they keep changing their minds then how does it ever get done?" Simple, you make it extremely clear that continuously changing their mind directly equates to more time and money spent and prevent other functionality from being implemented.

The key stakeholders either don't pay attention or louder voices who have really no relative bearing to the project somehow get suddenly important. These are often folks with something to gain by holding things up or creating confusion. That is always the problem in all projects but it seems more acute in Agile because "hey, we have a process that can allow for these changes."

You're right, this is true on all projects. Stakeholder involvement has to be managed just like any other aspect of a project. As for "we have a process..."; if you think Agile is about processes then you really don't get it. Agile isn't about processes, it really is about adapting to change and doing what works. If what works is having a daily stand-up and holding team members accountable for for their work then so be it. If it means not pair-programming, then do that too. There are no hard and fast rules.

Re:Agile doesn't mean that the project won't fail (2)

darkstar949 (697933) | about a year ago | (#43821911)

Depending upon what type of software you are writing, if you aren't doing some fairly detailed requirements analysis then you are setting yourself up for failure. Case and point, medical devices and financial systems. In both cases you can't just go in there and change things on a whim as there is paperwork that is involved with documenting why you are even making the change in the first place.

It sounds to me like the direction they are taking the project (waterfall model for the back-end and Agile for the front-end) is likely how they should have approached things in the beginning. User interfaces need a lot of iterations to get "right" but for the back-end code, as system like this likely already has a body of knowledge to draw on for what needs to be done so Agile wouldn't necessarily gain you anything.

Re:Agile doesn't mean that the project won't fail (5, Interesting)

tgd (2822) | about a year ago | (#43821373)

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.

Re:Agile doesn't mean that the project won't fail (0)

Anonymous Coward | about a year ago | (#43821645)

For most projects, if they fail, it's because of poor planning or poor implementation. Agile is a tool that tends to work better than waterfall if done correctly, but if not done correctly, either blame the programmers and/or management for not being professional enough to understand how agile works.

Re:Agile doesn't mean that the project won't fail (1)

LifesABeach (234436) | about a year ago | (#43821649)

Interesting concept, use Waterfall for Macro Project Planning; then cross over to Agile for Micro Project Planning.

Re:Agile doesn't mean that the project won't fail (5, Interesting)

gutnor (872759) | about a year ago | (#43821725)

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 (1)

AuMatar (183847) | about a year ago | (#43821897)

The problem is you can't avoid mediocrity- most programmers are mediocre. And in more corporate environments the percentage of mediocre and bad goes up, as the really good programmers tend to gravitate towards pure software shops and startups. The trick is to give them parts that stretch their abilities but don't overwhelm them, which requires good management.

Re:Agile doesn't mean that the project won't fail (4, Insightful)

Chris Mattern (191822) | about a year ago | (#43821335)

But it might make it clear that it will fail much earlier and then at a lower cost.

But apparently it didn't succeed in that, either. They're discovering massive failure only after three years and billions of pounds.

Re: Agile doesn't mean that the project won't fail (3, Insightful)

CadentOrange (2429626) | about a year ago | (#43821393)

It could have been a lot worse. They could have discovered it after decades and spent even more billions. Like the central NHS database project.

Re:Agile doesn't mean that the project won't fail (1)

Big Hairy Ian (1155547) | about a year ago | (#43821413)

But it might make it clear that it will fail much earlier and then at a lower cost.

But apparently it didn't succeed in that, either. They're discovering massive failure only after three years and billions of pounds.

The people doing this project are human they make mistakes. Besides we don't know how Agile they are I've worked on a lot of Agile projects and a lot of Waterfall projects and I've never seen one yet that was wholly Agile. I'd be more interested in how much of it was outsourced but then I didn't RTFA

Projects don't fail... (1)

sycodon (149926) | about a year ago | (#43821503)

...because of the development model.

They fail because there was not enough though put in up front and the requirements are vague.

Take that (0)

Anonymous Coward | about a year ago | (#43821141)

Take that, false programmers :-) Long life to true programming!

Re:Take that (1)

wmac1 (2478314) | about a year ago | (#43821397)

Project failures are hardly a programming problem.

Project management, software engineering processes (specially requirement engineering) and design are the most risky. Hiring programmers which are fit for the project is still a risk factor though.

Re:Take that (2)

Z00L00K (682162) | about a year ago | (#43821665)

Having seen both the waterfall model and the agile model I would say that both models needs to be applied correctly to work. The agile is working for incremental development in small steps where you can adjust and adapt as you go, the waterfall works for long iterations but it requires that each step is thoroughly analyzed for problems. It works fine for slow projects but not for quick to market and cheap projects.

Changing process method in the middle of a project is a sure sign that it's time to abandon ship because the management doesn't have a clue what they are doing.

One of the primary reasons for a large project failure is that people aren't working with the same goal in sight. Even the single worker needs to know what the overall picture is and what they are supposed to do and why.

What's that saying about agile? (5, Insightful)

NotSoHeavyD3 (1400425) | about a year ago | (#43821143)

Agile assumes you have smart, talented, dedicated individuals doing the work. Then again if you have that pretty much anything works.

Re:What's that saying about agile? (5, Insightful)

jacobsm (661831) | about a year ago | (#43821177)

Agile is just the latest management fad. In a year or two something else will come along, and the lemmings will follow.

Re:What's that saying about agile? (2, Insightful)

Virtucon (127420) | about a year ago | (#43821285)

Year or two? Agile and it's variants have come into being because the old methods of software engineering were thought deficient and slow. Agile does work when teams are focused and stakeholders engaged. Agile does work just like the other methodologies but it's not the ultimate solution and companies or governments in this case who take on a development project with it need to know the pitfalls and how to avoid them. Otherwise you'll still have a steaming pile of dog crap at the end.

Re:What's that saying about agile? (1)

Anonymous Coward | about a year ago | (#43821429)

Agile can only be described in a big poster of buzzwords. Follow the buzz you dumb lemming.

Re:What's that saying about agile? (0)

Anonymous Coward | about a year ago | (#43821831)

Taking it more seriously, both methods can work. Taking one side or the other is akin to attaching yourself to a particular political or religious manifesto and following it blindly. I have seen great waterfall products with great results. I have seen waterfall fail in a death march. I have seen Agile efforts work nicely (especially on smaller projects) and I have see some "fail fast" over and over again.

It's more about people and talent than process.

What, it's 1999 again? (-1)

Anonymous Coward | about a year ago | (#43821355)

Son, I remember hearing those very claims back in 1998 and 1999, when the whole "agile" movement really started taking off.

I'd hear managers, executives, industry analysts and folks like yourself saying, "it's just a fad" and "something else will come along in a year or two".

Well here were are, 15 years later, and these methodologies are still more widely-used than ever.

I don't necessarily like all of their ideas, and some of what they say just doesn't work in reality, but for crying out loud, don't spew out bullshit that was repudiated over a decade ago!

Re:What's that saying about agile? (4, Insightful)

ph1ll (587130) | about a year ago | (#43821385)

"DWP IT chief and government chief information officer Joe Harley said in May 2011 that agile would ensure his department delivered Universal Credit on time in October 2013." [computerweekly.com]

So, a two year iteration and a guaranteed delivery date? Yeah, that really sounds like Agile.

The article goes on: "Attention must turn to Accenture and IBM, who are on track to earn £1bn between them as lead developers of the system. They may have played the most significant part in agile's failure at DWP, or DWP's failure at agile. Accenture and IBM may have found agile commercially inconvenient. Neither has yet been able to speak about it."

Ass-Center and IBM? Yes, two companies who are well known for their love of Agile [rolls eyes].

Re:What's that saying about agile? (1)

Big Hairy Ian (1155547) | about a year ago | (#43821427)

IBM? I would have thought they'd be using RUP as it's their baby!

Re:What's that saying about agile? (3, Funny)

nightcats (1114677) | about a year ago | (#43821619)

My new project methodology is to be called Fragile. Called it, now everyone jump on board and pay me.

Re:What's that saying about agile? (2)

zitsky (303560) | about a year ago | (#43821265)

Do you actually work as a project manager? I do. Try executing your idea in an average company and see how far you get. Good luck getting only "smart, talented, dedicated" individuals for your project! Even those employees will have character flaws, personality conflicts or other reasons that prevent the project from succeeding.

Re:What's that saying about agile? (1)

Anonymous Coward | about a year ago | (#43821483)

You sound like a typical manager. You think you alone have all the world's talent. Damn the man.

You know what Agile development gets us for our workspace? It gets our managers out of the office for a week as they attend seminars and crap for it. It's amazing the things we get done during that week when they're all off "learning." You know what we do when they get back? We run them in circles chasing a problem we created for the specific purpose of keeping them busy.

Posting AC in case I work for you.

Re:What's that saying about agile? (1)

gallondr00nk (868673) | about a year ago | (#43821363)

Agile assumes you have smart, talented, dedicated individuals doing the work.

And, I would wager, reasonable, patient, even handed clients (which will be the government, and not the ridiculous assertion as stated in the article that it's the taxpayers). I challenge anyone to look at the Victorian dinosaurs in power in the UK and assume any of those qualities.

That was just a cheap shot at the government, I admit it.

I imagine whatever will run UC on a technical level will just be another government collossus. Their minds are incapable of conceiving or implementing anything else.

Re:What's that saying about agile? (0)

Anonymous Coward | about a year ago | (#43821409)

It also assumes you don't have leadership constantly pulling the rug out from under you.

IBM (0)

Anonymous Coward | about a year ago | (#43821571)

"IBM signs £525m DWP contract to provide Universal Credit systems"

http://www.computerweekly.com/news/2240105721/IBM-signs-525m-DWP-contract-to-provide-Universal-Credit-systems

Incompetent idiots...

No, not IBM, IBM's job is to milk morons for their money, using whatever buzzwords will sell the project, no the incompetent idiots are the people who hired them.

So it fails, and IBM etc. market it as a failure for 'Agile' when in fact most of their projects fails regardless of whatever BS, they use to sell them.

Re:What's that saying about agile? (0)

Anonymous Coward | about a year ago | (#43821687)

Agile assumes you have people with an IQ of at least 100 and can understand what Agile is. The only thing "hard" about Agile is that it requires planning, but one would hope that most large projects would have planning.

BTW should I mention my pet name for Agile (4, Interesting)

NotSoHeavyD3 (1400425) | about a year ago | (#43821161)

I refer to it as "Monkey's Paw Development" (And before anybody asks agile to me ends up being "Hey let's ask developers what they'd wish for in an awesome development environment. Then give them that but give it to them in such a way that they regret ever asking for it.")

To quote Bruce Lee... (2, Insightful)

Anonymous Coward | about a year ago | (#43821163)

"Before I learned the art, a punch was just a punch, and a kick, just a kick.
After I learned the art, a punch was no longer a punch, a kick, no longer a kick.
Now that I understand the art, a punch is just a punch and a kick is just a kick."

I've worked with a few different methodologies in my time, but now that I'm older I realize all you have to do is follow common sense. It's really not that difficult.

Simple formula (1, Interesting)

justthinkit (954982) | about a year ago | (#43821271)

Government department + software project = total failure.
.

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.

Re:Simple formula (3, Informative)

Epeeist (2682) | about a year ago | (#43821411)

Government department + software project = total failure. .

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.]

Not a real biggie, just a replacement for Jobseeker’s Allowance, Income-related Employment and Support Allowance, Income Support, Child Tax Credits, Working Tax Credits, Housing Benefit for the whole of the UK population. I mean how hard can it be? Given your obvious talents I am sure you could knock something together using a few Excel macros by next Tuesday.

One of the things about this is that it is being driven by an ideologue who doesn't give a toss about evidence, not quite the person who thinks all government sponsored software development but pretty close.

Re:Simple formula (0)

Anonymous Coward | about a year ago | (#43821419)

I've worked on government and corporate projects and I can tell you that just because it is government doesn't automatically make it any less likely to succeed than a private project. I've seen plenty of corporate boondoggles.

Where's the testing? (2)

jwthompson2 (749521) | about a year ago | (#43821171)

That question would indicate to me that they're doing Agile wrong. Agile development ought to include a short feedback loop that includes not only the client, but automated tests. So, if this question is legitimate, then something is very wrong with how this project has been run.

Re:Where's the testing? (5, Funny)

Anonymous Coward | about a year ago | (#43821525)

That question would indicate to me that they're doing Agile wrong.

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.

Open Source It (2, Interesting)

VortexCortex (1117377) | about a year ago | (#43821199)

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.

What are you talking about? (0)

Anonymous Coward | about a year ago | (#43821329)

What the hell are you talking about?

Open source developers will not flock to work on a bureaucracy-ridden welfare allocation and tracking platform, of all things.

Hell, just look at that goddamn Diaspora project. That is something that actually may have interested a large number of open source developers, but even then it fizzled out and is basically dead.

I don't know what the hell you're talking about, son.

Re:What are you talking about? (2)

PPH (736903) | about a year ago | (#43821477)

Open source developers will not flock to work on a bureaucracy-ridden welfare allocation and tracking platform, of all things.

I will if I get to work on the 'open source developers benefits module'.

Re:What are you talking about? (1)

RobertLTux (260313) | about a year ago | (#43821599)

maybe if you oh included programmers with "skin" in the game (like the few hundred unemployed ones on the dole rolls) then maybe this might not have near failed.

Re:Open Source It (0)

Anonymous Coward | about a year ago | (#43821475)

This is possibly the dumbest fucking comment I've ever read on Slashdot, a brilliant juxtaposition of arrogance and ignorance. Bravo!

Re:Open Source It (1)

westlake (615356) | about a year ago | (#43821551)

Agile Needs Testing? Open Source It.

Open Source a project to consolidate all national welfare transfer payments in a country of 63 million. Meeting all accounting and legal requirements. Now tell me how you recruit and manage OS "volunteers" with the depth and experience needed to do that.

Re:Open Source It (-1)

Anonymous Coward | about a year ago | (#43821849)

Your immaturity is blinding. Hoping anything is a 'disaster' for any reason only makes you look like you are five years old. Apologies if you are five years old by the way.

The public is not the client (2, Insightful)

Anonymous Coward | about a year ago | (#43821219)

The government is the client. There is no reason for the public to be involved in an unfinished project.

Re:The public is not the client (1)

max (79752) | about a year ago | (#43821295)

Someone please mod parent up.

Just because taxpayers somehow pay for something doesn't mean that every taxpayer should be able to get full real-time insight into or control of it. I shudder at the thought of the extra cost when gazillions of wannabe software developers consider themselves to be the clients of a government project and mess it up.

Re:The public is not the client (1)

Anonymous Coward | about a year ago | (#43821471)

If the government is the client then by definition the public is the client, since the government is only acting on behalf of the public. It's its only legitimate reason for existing.
You shudder at the thought of millions of people ‘messing it up’ with their feedback, but what actually happened is that millions of people, who paid for the thing and therefore had a right to transparency, didn't know what was going on and because of that no one applied the brakes or provided useful help and therefore the project failed.

Re:The public is not the client (1)

stenvar (2789879) | about a year ago | (#43821577)

Just because taxpayers somehow pay for something doesn't mean that every taxpayer should be able to get full real-time insight into or control of it.

Really? Why shouldn't the public get "full real time insight" into just about everything government does? What is there to be gained by having government be secretive?

Re:The public is not the client (0)

Anonymous Coward | about a year ago | (#43821845)

Great, so not only do you have to deliver a massive, incredibly complex software project on time and on budget, now you have some non-trivial % of 63 million citizens behaving like backseat drivers, and politicizing every line of code you write, and writing you hate mail because you've "helped the government streamline its fascist confiscatory behavior," or "implemented code helping the government keep the poor and disadvantaged in line." (Take your pick - no matter WHICH end of the political spectrum you choose, some nutjob is going to be writing you hate mail.)

Fuck, where do I sign up for THAT project?! Sounds like a dream!

world's biggest? (4, Interesting)

hackula (2596247) | about a year ago | (#43821225)

"World's biggest" and "agile" don't really go together. One of the core tenants to agile is to break things down into small chunks. Multi year contracts for a predetermined end product are waterfall by definition. Either way, I have seen waterfall work just fine and I have seen True Agile[tm] fail hilariously miserably (to which most Agilistas respond with some form of the "No True Agile" fallacy). 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.

Re:world's biggest? (1)

simonbp (412489) | about a year ago | (#43821255)

World's most agile Zeppelin?

Re:world's biggest? (0)

Anonymous Coward | about a year ago | (#43821343)

Tenets. The things agile has are core tenets. Core tenants would be people who rented a core off you, or maybe people who rent a flat off you in the core of something.

Getting this stuff right helps people to feel that you might actually know what the hell you're talking about. Glad to help.

Re:world's biggest? (5, Insightful)

Kjella (173770) | about a year ago | (#43821553)

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.

Re:world's biggest? (0)

Anonymous Coward | about a year ago | (#43821899)

But with proper planning, even a skyscraper DOES get built "one story at a time."

And there's the rub.

You can build a perfectly suitable "one room shack" by slapping some canvas & boards as temporary walls around the first story of a steel-beam skyscraper. Sure, it'll be one of the most over-engineered one room shacks in history, but that shack is architected for future expansion, which is why those giant steel beams are being used as support members, rather than scrap 2-by-4's.

If you find that you've reached the 20th floor only to realize that all your steel beams are only able to carry 20% of their expected load, then that is a failure of your architects, who failed to provide a design for a building which will be 100 stories tall, but which must get built just a couple stories at a time.

A modest proposal.. (0)

Anonymous Coward | about a year ago | (#43821241)

try cutting down the scope and complexity of the benefits system first.

Why try to automate suicidal nonsense like the "jihad seeker's allowance"?

And who were the contractors? (2, Informative)

Anonymous Coward | about a year ago | (#43821245)

It's the usual crowd screwing money out of the government

HP/IBM/Accenture/BT

https://www.whatdotheyknow.com/request/130677/response/322518/attach/html/3/FOI%203648%20Response%20181012.pdf.html

Re:And who were the contractors? (4, Insightful)

abirdman (557790) | about a year ago | (#43821357)

Notice they've got Oracle in that list. This vendor list is a nasty bunch of international billionaires-- individuals and corporations. These are the kind of companies who want to "partner" with you if you use their products-- one doesn't "buy" Oracle (or IBM or BT) products, one carries them like an STD. Note the three local contractors and sub-contractors who sell to the government, and then sub out to a bunch of bloated global corporations who have no (non-monetary) interest whatsoever in the project working, and probably won't repatriate the profits. This does keep the salaries in the field high. And the government has no choice but to bid out another contract for a plum software project right soon. There's a lot more partnering to do.

Yeah... (5, Insightful)

Greyfox (87712) | about a year ago | (#43821275)

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.

Agile is (usually) BS (5, Insightful)

Anonymous Coward | about a year ago | (#43821297)

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.

Re:Agile is (usually) BS (0)

Anonymous Coward | about a year ago | (#43821567)

Beware anyone who claims that Agile is the solution to anything.

SILVER BULLET EXPRESS! Zooommmmm!

Re:Agile is (usually) BS (1)

Black Parrot (19622) | about a year ago | (#43821621)

ISTM that 'agile' is just a hop and a skip away from 'fragile'.

I suspect it works best for a small highly motivated group of developers, e.g. a startup or some hobbyists making a game.

The total misunderstanding of Agile. (2, Interesting)

houbou (1097327) | about a year ago | (#43821309)

To me, "Agile" isn't meant to be free for all. Rather, it's meant to decouple the development of large software into more manageable chucks and teams.

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:The total misunderstanding of Agile. (1)

GreyWolf3000 (468618) | about a year ago | (#43821887)

Reading the summary, it's clear the problem is that people are confusing what it means to take an iterative approach to development.

Production code is production code, and they should never have stopped shipping production code. The amount of scrutiny/rigor applied to code shipped in an agile environment should not decrease vs. waterfall. You're just shipping smaller chunks a lot more frequently.

All this means test, test, test, the entire time.

Re:The total misunderstanding of Agile. (0)

Anonymous Coward | about a year ago | (#43821895)

Also you should never forget that it is not just about an Agile process, the process can only work when developing on an Agile architecture.
You cannot bolt on an Agile process to add features to a system that was designed and build through a waterfall project.

What happen to CCTA? (3, Insightful)

Anonymous Coward | about a year ago | (#43821339)

The UK Government used to have its own internal computer consultancy. This was called the Central Computer Agency - the Central Computer and Telecommunications Agency after it took over running the government phone network.

CCTA was staffed by a mixture of experienced civil servants and expert contractors, and provided support to all UK government department's computer projects. It had procurement experts, sizing experts, code, architecture, the lot. When these experts were not working for Departments they worked on UK and international standards and methodologies. Some of you may remember the OSI, ITIL, PRINCE, PROMPT, SSADM, CRAMM, BS7799/ISO 27001/2, BS5750, etc...

In those days UK Government projects ran to time and came in on budget, with CCTA project managers. But CCTA was constantly under attack from the computer industry, who saw CCTA as an expert gatekeeper, stopping them from making major profits out of government projects. They lobbied for its closure constantly, and in 2000 they got their wish. CCTA's major functions were closed down and the rump moved to OGC

Interestingly the CCTA Security and Privacy Group (the only UK Government computer security organisation at the time) had been closed down earlier at the request of GCHQ and MI5, who wanted to take its budget and responsibilities. The SPG arguably ran the first CERT (though not called by that name) in 1984, and was influential in developing, inter alia, early AV company liaison and security accreditation with initiatives like Common Criteria.

The UK government departments, encouraged by a variety of groups with ulterior motives, cut off its nose to spite its face. They are now a byword for incompetence and overspend. The collection of experts which existed in Riverwalk House during the 1980s and 1990s will never be replicated again...

Shocking (0)

Anonymous Coward | about a year ago | (#43821379)

Agile is the biggest joke programmers have ever perpetuated on the corporate world.

Death march (0)

Anonymous Coward | about a year ago | (#43821381)

Agile is often abused to excuse forced "death marches".

Welfare problem (0)

Anonymous Coward | about a year ago | (#43821387)

The real problem is so many people are on welfare that a computer can't keep track of it all.

We know the saying... (1)

3seas (184403) | about a year ago | (#43821401)

The bigger they are the harder they fall...

Agile is not a magic wand (1)

Anonymous Coward | about a year ago | (#43821435)

Hi:

I've seen Agile projects fail. The answer was always 'We didn't do Agile hard enough.' No. Agile can be as foolish a project management method as any other but it seems to have a religious component to it. There were always some unbelievers to needed to be rooted out. Probably they were casting magic inefficiency spells or something.

Worse yet is when companies try to do product management via Agile. If it's so wonderful, why don't we run payroll via Agile?

Re:Agile is not a magic wand (2)

Black Parrot (19622) | about a year ago | (#43821587)

Agile can be as foolish a project management method as any other but it seems to have a religious component to it.

Like everything else about software development, from methodology to choice of language to how you name variables and format code.

I find it hard to imagine that people in other fields are as opinionated as we are, with so little evidence to back up their opinions.

(But they're people too, so they probably are.)

True Agile... (0)

Anonymous Coward | about a year ago | (#43821455)

If you know what you are doing more than 50% of the time, you not doing true Agile (tm). Source: I used to be an "XP" coach, working directly with the authors who wrote all the XP/Agile books (spoiler: they were full of crap).

Want to successfully build software systems like professsional grown ups do without all the hype and buzzwords? Then read up on "Systems Engineering", the methodology used to build actual big important things like airliners.

Brogrammers (5, Interesting)

Anonymous Coward | about a year ago | (#43821465)

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.

Unsurprising (0)

Anonymous Coward | about a year ago | (#43821521)

Agile is supposed to be "the right thing to do" because some self-appointed gurus say so. It has no scientific foundation whatsoever, and not even solid statistics to justify itself. It's just another industry fad. Like all fads, it will work fine for some time for some people, but it is not, and never will be, the silver bullet that many are trying to sell.

Vindication! (0)

Anonymous Coward | about a year ago | (#43821613)

I took a course a while ago where I had to study agile, scrumm, waterfall, etc. methods. Frankly I thought it was all a load of shit.

Seeing that it failed in the real world helps bolster my opinion.

I also changed majors to get the hell out of software engineering after that course.

Agile/Extreme is analogous to alternative medicine (3, Interesting)

Hentes (2461350) | about a year ago | (#43821617)

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.

When will they learn (1)

Big Hairy Ian (1155547) | about a year ago | (#43821635)

Wouldn't it be better to get 5 smaller firms to write it for a tenth of the cost each and then grade them based on user experience and number of bugs reported. Once they all finished or given up give the rest of the money to the firm that did the best job!

Thats because you are not doing agile right. (1)

140Mandak262Jamuna (970587) | about a year ago | (#43821657)

If you do agile correctly it will beat waterfall hollow. If it does not, then you are not doing agile right. Because the very definition of agile is "something that is better than waterfall". If it is worse than waterfall it is not agile. Typically you need to ply millions of dollars to consultants who will come in and talk about the Toyota assembly line, about toasting bread slices to black and scraping off excess black to get the correct color of brown, etc. Then they will make all the top managers to stick dots on paper and stuff envelops and write addresses. Then they will point out how horribly wrong and incompetent the top managers are in sticking dots and stuffing envelops. And from these exercises somehow you should understand something and make something better than waterfall. That will be called agile. If it is not better then you are not doing agile right. Rinse, lather and repeat.

Funny thing, our agile development service provider is something called Rally. Some of the trivial things I ask for takes them two releases to implement and release. The entire code runs on their servers, and they have all the data with them. Still it takes them two releases to implement "I want to clone my queries and make minor changes". Then our top management wants our shrink wrapped software, installed on our customer's machine, who won't show us the data because it is proprietary, to ship with brand new features every three months without any regression. I used to call it insane. Now I know the right name for it. It is called agile development.

not agile, not waterfall.... (0)

Anonymous Coward | about a year ago | (#43821685)

Take the worst inflexibilities of waterfall, the total lack of meaningful forward planning from agile and what do you get? Wagile! It's the new paradigm I tell you.

Commercial Confidentiality (1)

sa1lnr (669048) | about a year ago | (#43821691)

is the excuse regularly given here in the UK.

Risk = Size (1)

CyberGarp (242942) | about a year ago | (#43821713)

There was a study done years ago that claimed that the chance of a project failing was proportional to it's size. Unfortunately, I cannot find a link to it this morning. If this hypothesis is true, then blaming the failure on Agile is inappropriate, as the root cause of failure is the fact that the project was too big to manage. The usual approach when things go south, is to throw more money and developers at the project--rather than scaling it back. A better approach would be, slowly merging welfare payment systems 2 into 1, like a single-elimination tournament. Yes, theoretically it would be more work, but the risk of failure is mitigated. For example, if there were 8 systems, there would be 4 merger projects--and one failed. You now have 5 systems to deal with merging, and 3 successful teams. Take the best two and merge 4 of the five into 2, etc. Big huge projects are to be avoided--humans just can't manage software development on that scale very well.

Development and manufacturing. (2)

140Mandak262Jamuna (970587) | about a year ago | (#43821723)

Basic problem here is non-programmers in the management visualize software "product" being manufactured somewhat like a very sophisticated assembly line or teams of workers putting together a product like they did before the assembly line was invented. But software is organic, it is grown. It is not grown like rows and rows of corn in a field but more like growing a city from a village. You are not going to plunk down a new 80 story skyscraper in downtown without huge disturbance to existing structures and users near by. You are not going to add a new Lorentz transform based asymptotic wave form expansion feature in the middle of the simulation sequence without huge disturbance. Or add payroll processing of German employees to you American HR system without serious disturbance.

Never seen real Agile. (0)

Anonymous Coward | about a year ago | (#43821759)

I've been working in the IT industry for almost 15 years now. I first encountered Agile in 2004 and apparently I've worked on 10s of Agile projects since then. I say apparently because I've yet to understand what Agile is or how it actually works; probably because every single "Agile" project I've worked on is run vastly differently to every other project and invariably ends up being a waterfall based approach.

I'm sure pure Agile is run properly somewhere and by people who actually know what they're doing, but I've yet to see it.

The article clearly summs up why it was not agile (1)

Morpf (2683099) | about a year ago | (#43821761)

"'Agile' has been treated as a silver bullet – not as what it really is – just another design methodology – while much of what is supposed to happen with an agile software development project – especially regular and repeated testing of prototypes - has been conspicuously absent."

So no surprise it failed. If you throw away the most important bits that are supposed to ensure some quality and functionality, what you expect what happens?

Re:The article clearly summs up why it was not agi (0)

Anonymous Coward | about a year ago | (#43821807)

In other words...

They were holding it wrong!

They are obviously not doing agile right. (0)

Anonymous Coward | about a year ago | (#43821825)

They need to remove cubicle walls, exclusively pair program, and give 20 some things veto authority over their geriatric peers.

Slashdotters to the rescue (0)

Anonymous Coward | about a year ago | (#43821839)

As anyone who has been around slashdot for a while knows, it's full of people who gallantly fixed projects messed up by those darn H1Bs/offshore programmers... Maybe we should send those people to fix this project...

Not a methodology problem (1)

Digital_Liberty (259479) | about a year ago | (#43821875)

No development methodology or project management style is going to help you if: 1) people are not telling the truth about their progress and 2) the project has numerous stakeholders (or a revolving door of stakeholders) with conflicting goals pulling the project in different directions.

From the article:
"[...] back in September they were telling us everything was great then too: so either they were lying then or they are lying now or they have been lying all along"

From another article [computerweekly.com] :
"The senior management responsible for delivering the programme has also undergone a significant overhaul in recent months, with UC programme director Hilary Reynolds being the latest figure to be taken off the project after just four months in the role."

"[...] esponsibility for the framework is now being moved to the Government Procurement Service – as we've always said it would."

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?