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?'"
What's that saying about agile? (Score:5, Insightful)
To quote Bruce Lee... (Score:2, Insightful)
"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.
Re:What's that saying about agile? (Score:5, Insightful)
Agile is just the latest management fad. In a year or two something else will come along, and the lemmings will follow.
The public is not the client (Score:2, Insightful)
The government is the client. There is no reason for the public to be involved in an unfinished project.
Re:Agile doesn't mean that the project won't fail (Score:5, Insightful)
...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 (Score:5, Insightful)
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.
Yeah... (Score:5, Insightful)
Re:What's that saying about agile? (Score:3, Insightful)
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.
Agile is (usually) BS (Score:5, Insightful)
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 doesn't mean that the project won't fail (Score:5, Insightful)
But apparently it didn't succeed in that, either. They're discovering massive failure only after three years and billions of pounds.
What happen to CCTA? (Score:3, Insightful)
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...
Re:And who were the contractors? (Score:5, Insightful)
Re:What's that saying about agile? (Score:5, Insightful)
"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: Agile doesn't mean that the project won't fail (Score:4, Insightful)
Re:Agile doesn't mean that the project won't fail (Score:4, Insightful)
...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:world's biggest? (Score:5, Insightful)
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:Agile doesn't mean that the project won't fail (Score:4, Insightful)
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 (Score:3, Insightful)
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.
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:What's that saying about agile? (Score:4, Insightful)
Its mostly people and talent, but the question of what you're doing is important too. Agile is great for things that are easily visible to customers- UI development or web pages, for example. It fails where you have other systems depending on you- a back end service can't change that quickly or have stability issues. Of course, you can do different methodologies for different parts of a complex system and use each where they make sense.
Re:world's biggest? (Score:5, Insightful)
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.
I think what the grandparent was trying to say is that a lot of Agile projects tail to give people proper time to actually do some initial architecture of the project before people jump into the sprints. Realistically, you need to combine waterfall with Agile methodologies since large projects need to have a solid foundation to work off of that might take a couple months to put in place.
To go back to the building analogy, if you are building a skyscraper you are digging a basement and putting footings and everything else in before you even build the first floor.
Re:Agile doesn't mean that the project won't fail (Score:5, Insightful)
The unstated assumption in that theory is that there is a group of human beings who are unto demigods, capable of defining detailed specifications that cover all eventualities, see far into the future, and can be implement mechanistically by simple code grinders. I have run into two or three such people in my entire career, out of the thousands of system architects and business analysts I have worked with in some capacity. And even those three people (a) often got caught by surprise by unintended side-effects (b) were often part of a process that took so long to come to fruition the system so designed was obsolete by the time it was deployed.
The only industry I am aware of where strict, spec-controlled waterfall is probably appropriate and generally works is aerospace controls systems. Of course that industry is notorious for huge schedule and cost overruns (the A400 software fiasco is particularly instructive in this regard), and even their software is not free from bugs and unintended consequences. Ref the numerous changes Boeing has made to the electrical system control software on the B-787 since it went into service - why didn't they just "get the spec right the first time"? Enrico Fermi's comment on how to manage the unknown is very instructive.
sPh
Re:Agile doesn't mean that the project won't fail (Score:5, Insightful)
Extremely accurate. (Score:4, Insightful)
Whether it was 'waterfall', 'agile'', or whatever, every project that I've worked with that seemed to put more effort into using the most hyped phrasing to describe their process than into actually developing the project has been doomed.
I liken it to religion. The spirit of most holy texts is quickly lost in the actions of adherents as they focus on the specific content rather than the message. For Christianity, specific belief in the divinity of Jesus seems to often be more important than adhering to his teachings. Similarly, in Agile, managing to map words like 'scrum', 'sprint', 'epic', 'user stories', and so on to what you do is more important than internalizing the original intent behind those words.
Projects that don't make a lot of effort to 'conform' to any specific renowned fad tend to do well. They also tend to do the sorts of stuff Agile advocates without using the words.
Re:Agile doesn't mean that the project won't fail (Score:5, Insightful)
The benefits it promises come only from the synthesis of ALL its components.
Yes, yes, we've heard it a thousand times, if an agile project fails, it must not have been truly agile. Probably isn't a true Scotsman, either.
Re:Agile doesn't mean that the project won't fail (Score:4, Insightful)
...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.
Parent poster here. I see your point, however, my experience has been that separating the designer/architect role from the developer role is fraught with pitfalls. The people writing the code should be the ones designing it, otherwise you end up with a skyscraper put together with superglue instead of bolts and welds. The response to that is to have precise specs, but the time spent writing specs that are precise enough to be flawless is more productively spent doing the actual coding.
The bottom line to all management fads and whether a development process is effective and ineffective are fundamental human limitations:
1. Quadratically growing communication overhead as teams get larger [wikipedia.org]
2. Finite human memory capacity, limiting how much information about a project each developer can be aware of (and each developer must be aware of the whole project, to avoid causing havoc or reinventing the wheel, or they must be sequestered in their own subcomponent)
A good team size appears to be five, and an organization should not have more than five teams that need to intercommunicate. The challenge is to break up a piece of software to fit this kind of arrangement. Anything else will lead to company-wide split-brain, NIH, and communication bottlenecks. This is true regardless of the development process selected. Fundamental human limits are like the speed of light, you can get closer to them, but you cannot exceed them. So assemble good teams, architect your project to fit those teams (or vice-versa), and remember that everyone is human.
Re:Agile doesn't mean that the project won't fail (Score:4, Insightful)
Its more than that. Managers prefer mediocre programmers because then you are not dependent on them.
Managers have this dream that programmers are a kind of generic glorp that can be poured into any job slot and be easily replaced with another generic glorp programmer.
One manager had this dream of putting all programmers for a multi billion dollar company into a single oncall rotation. Whoever was up that night would cover accounting, inventory, plant, invoicing, database, pc problems, etc..
Re:Agile doesn't mean that the project won't fail (Score:4, Insightful)
I'd want a cite on that claim that there is a difference in engineering there. Sounds a lot like, "... on a computer!" to me.
Mandatory requirements and Agile fallacies (Score:5, Insightful)
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.
Re:The public is not the client (Score:4, Insightful)
Just because the people delegate authority to representatives doesn't mean that those representatives should operate in secret.
Re:Mandatory requirements and Agile fallacies (Score:5, Insightful)
Sorry, but you are completely missing my point. My comment wasn't really about tests, it was about the fact that these huge projects are practically all-or-nothing in their success.
Exactly. You cannot use Agile to build a 100-mile canal, as the whole thing would be useless even if you completed 99 miles.
If the system cannot be useful until a large set of functions are in place and working, then it is not suitable for Agile, period.