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?'"
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.
But it might make it clear that it will fail much earlier and then at a lower cost.
Take that, false programmers :-) Long life to true programming!
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.
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.")
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
"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.
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.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
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.
The government is the client. There is no reason for the public to be involved in an unfinished project.
"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.
try cutting down the scope and complexity of the benefits system first.
Why try to automate suicidal nonsense like the "jihad seeker's allowance"?
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
.
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.
I come here for the love
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.
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.
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.
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...
Agile is the biggest joke programmers have ever perpetuated on the corporate world.
Agile is often abused to excuse forced "death marches".
The real problem is so many people are on welfare that a computer can't keep track of it all.
The bigger they are the harder they fall...
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?
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.
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.
...because of the development model.
They fail because there was not enough though put in up front and the requirements are vague.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
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.
"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.
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 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.
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!
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
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.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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.
is the excuse regularly given here in the UK.
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.
I used to wonder what was so holy about a silent night, now I have a child.
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.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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.
"'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?
In other words...
They were holding it wrong!
They need to remove cubicle walls, exclusively pair program, and give 20 some things veto authority over their geriatric peers.
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...
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:
"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."
Being called 'Agile' doesn't mean that it is in the spirit or letter of 'Agile'.
The reality is that 'Agile' is in practice more of a brand than anything else. Project Managers love to apply the terminology to their projects. This does not mean they actually meaningfully follow a consistent set of behaviors, just that they use similar sounds words.
'Agile' is like 'Cloud' and 'Web 2.0'. While each phrase may have coined with a particular specific concept in mind, they became more hype than anything usefully descriptive.
XML is like violence. If it doesn't solve the problem, use more.
This should be suppose an article about "agile" and the Universal Credit. After reading the article there is no information what-so-ever, except that the Universal Credit project has been admitted to be failing.
So why is Universal Credit an "agile" project?
Why it is failing?
What is Universal Credit anyway?
Maybe that is why Twitter is so successful, the whole article is just a Twitter message: "Universal Credit, suppose to be biggest Agile Software Project, is failing".
Here is some more information:
http://www.guardian.co.uk/society/2013/apr/29/universal-credit-pilot-scheme
http://www.guardian.co.uk/commentisfree/2013/apr/30/universal-credit-iain-duncan-smith
Is it called "agile" because it's a "step-by-step approach" ?
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
If you hired an Agile contractor to build your house, he would build the bathroom in one sprint (wooo....a deliverable!!!), the kitchen in another, the living room in yet another, and by the time the project is complete your house would be totally out of whack.
Agile is NOT a one-size-fits-all solution, but its proponents, having a vested interest in it (money, power, sex ?) don't ever talk about where it is not applicable.
Down with Agile !!!
The government is the client. If they are not sufficiently distanced from the dev team, they cannot properly manage the project.
My CIO laments that 30-40% of our projects fail. That seems below the norm. So Britain should expect this to take 2-3 tries to get right. And then start over Judy because there is a new development paradigm.
In software, lawyering, and baseball can you get paid to fall so much.
deleting the extra space after periods so i can stay relevant, yeah.
I think we've found that Agile is like democracy. It's a terrible system for programming (or government) but it's better than anything else we've come up with yet.
Occasionally living proof of the Ballmer peak.
Quite bad troll attempt.
It's like you throw validation and verification out of the waterfall model or the v model. Do you think it would work?
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.
XML is like violence. If it doesn't solve the problem, use more.
The project is based on Linux... RedHat is a supplier. If it was based on .NET, the summary and the posters would claim that's the reason for failure and it would have been a success if it was based on Linux(see the London Stock Exchange story for hundreds of such comments modded up). So does that mean this project is failing because of Linux?
I don't think so, but all the bigoted hate and confirmation bias on Slashdot is amazing for sure.
I actually don't disagree, but I would think honesty would compel one to note that one could replace the word "Agile" in that paragraph with the name of any of the structured, "rigorous" methodologies and the observation would be equally valid. Unless one has unlimited time and budget, and the architectural equivalent of demigods, the structured methodologies fail very often too.
sPh
If you're an organisation full of MBAs who think their developers are peons and everything can be solved with meetings then the methodology won't matter.
I swear, you're all the people Jack Ganssel warned me about.
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...
I would really like to see some forensics on failure as big as this.
What went wrong?
Time estimates were too narrow? Testing failed or didn't exist? Project management? Bad programmers? Bad code?
Changing targets?
Noone speaking up when they noticed things going bad, for years? (It seems ridiculously common.)
It would be interesting to know if there's a good method to detect early warning signs of a failing project.
Two principles were key and could be used in any methodology.
1) Address risky (new technology, undefined specs, etc.) first
2) Regular time boxed functional builds.
If you can't address the risks successfully, then at least you can cancel the project early.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
"Then it's your own fault for not using Agile right."
But Master, how can I use Agile right?
"Use the parts that work for you."
Master, how can we select the parts of Agile that work for us?
"See Rule 1."
In the last 5 years, and a dozen projects, I have *never* seen Agile "done right". Agile is the new form of Gant charts, deceitful paperwork designed to make managers look useful and look as if they're "invested" in the process and as if real communications is incurring when, in fact, the meetings are being deliberately skewed and ignored by both competent people (who know better) and incompetent people (to pretend they're working).
For complex problems, you need highly competent people, and then get out of their way. That is was Agile basically does. "Individuals and interactions over processes and tools", it is right there as the first step in the Agile Manifesto. My guess would be that these idiots went for the cheapest offer that did Agile, but did not have good people. Processes can only help, but can never turn incompetent people into competent ones. Agile is not about not needing really good people for complex projects, it is about having the processes not hinder said really good people from doing their work. Or to put it differently, if an Agile project fails, most likely it is not the fault of the Agile approach, but personnel that cannot cut it. These people will still not be able to cut it with the waterfall model.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So Britain's liberal-conservative government, who don't care about the poor as evidenced again and again, fail to make a project work that would help paying benefits to the poor. Why am I not surprised?
Yes. By people that do not know the first thing about Agile. The first statement of the Agile Manifesto already clearly states "Individuals and interactions over processes and tools". Those that see Agile as a silver bullet are not even capable to understand that simple sentence or did not bother to find out what Agile is.
Also, Brooks "There is no silver bullet" still applies and there is zero reason to expect it will ever go away. Are these people completely and utterly disconnected from the real world? Have they not done even minimal research on what software engineering for complex projects entails?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
It is not really. "Individuals and interactions over processes and tools" is the first thing you need to know about Agile. It says right there in the Agile Manifesto that it is not a silver bullet and does not try to be one. The problem is all those "managers" without the first idea about software development, that think it is a process problem, because they also have not the first idea on how to select and manage competent people.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I have never, not once, seen a requirements document that accurately captures exactly what the system will do. [...] 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.
Well, in this case, "what they really want" tends to be defined literally by Acts of Parliament and/or policies set by the highest legal authorities in the government. I know it's popular to mock politicians in Europe for having no idea what they're doing economically, and it seems there's some truth to that in light of recent events, but you don't implement software to automate a major component of your national tax and benefits system in incremental changes with one guy designated as the project owner who can change his mind every now and then as you go along. That guy is the Chancellor of the Exchequer, and he has a few other things to do apart from responding in timely fashion to Bob the Programmer's request for clarification of how to implement the national tax rules.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Large projects never end in development because the devil is in the details. Many gaps get created between the various objectives that in turn become projects all to themselves. Those of us in development know all too well that just meeting a milestone is never enough due to the fact that when given a second shot at it things could be done much more efficiently. The whole WebKit/Blink fiasco is a great example of this. Agile has become a great method for moving forward and not looking back. Its no surprise to me that with enough small holes you can sink a ship. They either need to hire more people or spend more money on existing technologies, money walks and BS just schedules more meetings.
"The Guardian reported earlier this week that five companies working on the IT contract - Accenture, Atos Origin, Oracle, Red Hat and IBM - had claimed that work on the UC system had been halted" link
AccountKiller
And everyone (should) know this.
http://en.wikipedia.org/wiki/Basic_income_guarantee ... Winners of the Nobel Prize in Economics who fully support a basic income include Herbert A. Simon,[51] Friedrich Hayek,[52][53] James Meade, Robert Solow,[54] and Milton Friedman.[55] ..."
"A basic income guarantee (also called basic income or citizenâ(TM)s income) is a proposed system[1] of social security that regularly provides each citizen with a sum of money unconditionally. Except for citizenship, a basic income is entirely unconditional. Furthermore, there is no means test; the richest as well as the poorest citizens would receive it. The U.S. Basic Income Network[2] emphasizes this absence of means testing in its precise definition, "The Basic Income Guarantee is an unconditional, government-insured guarantee that all citizens will have enough income to meet their basic needs.
Just give every citizen (and maybe permanent resident) in the country a fixed amount per month and be done with it. Probably on the order of 50% of the per capita GDP, divide by twelve months. All you need to confirm is identity, citizenship, birth/death, and banking details for direct deposit. Then you are also set up to deal with the rise of robotics and AI displacing the need for most human labor over the next twenty years.
Contrast with:
http://en.wikipedia.org/wiki/Universal_Credit
"Gareth Morgan has written a detailed piece about the effects of welfare reform on benefits received, including Universal Credit.[6] The Universal Credit has some similarities to the negative income tax, but should not be confused with the universal basic income or basic income guarantee. There is some debate as to whether it should even be considered 'universal' at all given that it is subject to income levels and conditions around work availability.[7][8]"
Or in other words, it the requirements are buggy, it does not matter if you have great developers...
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
The problem I've seen is analogous to building skyscrapers and garden sheds. Some projects, like skyscrapers, have be complely designed in advance and built to be a skyscraper. You don't build a 2-story building then decide it works pretty well and then add another floor, and so on, until you have a skyscraper.
At the other end, you want a shed to protect your tools from the weather. While you could design a shed and the process to build it the way you would a skyscraper, but that's a lot of expense and it's going to take a long time. Instead, if you wanted, you could throw up some supports and put up a roof. This gazebo works well and protects your stuff from the rain. It's pretty easy to add walls, and so on.
Agile is useful for certain kinds of projects and the "classic" way is good for other kinds of projects. The real problem is that people try to use the same methodology for every project.
I'm a software developer who's been doing Agile development for years. I've signed the manifesto and try to walk the walk, and most of my Agile projects have been very successful. That said, in my current position as lead developer on a large State government project, I resisted Agile when planning the project with the PMs. I've worked on Agile projects long enough to know that Agile is not a fit for all organizations, especially governments.
Governments love their politics and bureaucracy, which run completely counter to the Agile notions of open communication, buy-in from the business/product owners, and team empowerment. If those are absent, then no matter how much you call it "Agile," you're setting yourself up for failure.
We chose a waterfall process that caters to the government's top-down management style. As a developer, I'm not 100% happy, but I'm happier than I would be than if I had tried to deceive myself into thinking that what we were doing was "Agile." That doesn't mean we don't use some Agile concepts -- we pair program, we do TDD (about 2/3 of the time), and we have decent test coverage.
BTW, having read the article, it seems as though they were actually doing some sort of iterative waterfall methodology and calling it "Agile."
Who has the contract? I worked for a software company that authored UK online apps back in 2001-2003. We did the PAYE, SA and a DWP app. Our company was brought in by EDS because EDS kept failing to deliver for the UK government. I spent 2 years in an EDS office in London. I was amazed EDS could get anything done. EDS had all of those contracts with the UK government back then. BTW, EDS is now HP consulting.
So, it has to expand upon the existing system, and must deliver new function, and must be delivered on time, and on cost? That's an iron triangle and therefore must be waterfall, and with a ton of contingency.
Fire the project executive that picked Agile for that one....
Beware: I believe all are created equal, and have the right to life, liberty, and the pursuit of happiness.
There are three things I have learned never to discuss with people... Religion, Politics, and Agile.
When you have bullshit phrases like "agile" or "scrum", you know that the software development team is a bunch of buzzword addicted cocksuckers.
Without a decent proportion of "smart, talented, dedicated individuals" you're most likely going to fail whatever methodology you use.
Problem seems to be there's a large industry (and certified professionals embedded in middle-management) who have vested interests in pitching approaches, not solutions - and however good a programmer you are, you're not going to make the 'big-bucks' without at least flirting with management. This is a good thing, but tends to make people tie their colours to a particular mast.
IMHO most methodologies are good - some have particular strengths for particular tasks/organizations - but basically they're just common sense (formalized in a way that you can slap on a power-point and justify to the clueless guy with the money).
A theoretical worker works for a company that switched from water-fall to Theory of Constraints. He was naturally dubious, but after his intro decided that he quite liked the idea (he's certainly been guilty of coasting on a task that was coming along nicely and was going to finish by the planned end date).
Then the bad stuff happened - "We automatically lop 25% of the estimate as this is more efficient".. I can see some savings, but howabout we're more realistic and just see if this stops stuff over-running. Then we start planning (tasks, estimates, buffers, dependencies etc) and start piecing it together. End of the first day we've formalized that this project cannot be delivered ontime using TOC. So well somebody decides some dependencies can be removed. Oh, and then somebody else starts adding 'programmer tbc 1' to the plan etc.
Basically, projects fail for all manner of reasons and this is often associated to the methodology. Reality is that it's the same old humans pushing the same problems into the systems, which then just fail with slightly different nomenclature.
You don't really need a magical 'named' framework. "Agile" is just another bullshit name for a bullshit idea. What you really need is a well defined definition of what the project is supposed to do, with all of the inputs studied and well defined, and all of the outputs studied and well defined. You then break down major ideas into blocks with well defined inputs and outputs, and break those down into functional units, also with well defined inputs and outputs. You break those down into pieces with well defined inputs and outputs into code blocks, which are then coded in a well defined, structured way. You build test beds to test each block for inputs/outputs and for stability, reliability, security and efficiency. As you connect blocks of code, you test the functionality between each, making sure of your results. You can put a fancy name on it if you want, but that's all you need to do. You know what you are getting along the way, and you get predictable timelines, and expectations. Once the thing is delivered, you accept revision requests (its inevitable, end users don't really think about scope until after delivery). Often revisions require major rewrites. Occasionally they are impossible.
The problem is that in practice you usually can't get a full definition of what a major project is supposed to do until after you've implemented it. It's simply too large, and there's too many things nobody thought of until they tripped over them during implementation. And worse, the longer you spend analyzing the problem to figure all those things out before-hand the more changes have to be made to the requirements because the problem you need to solve is evolving and changing over time. Your process is nice in theory, it merely fails to acknowledge reality.
Agile often goes too far the other way, though. Sometimes things are changing too fast to keep up at all, which is usually a sign that you need to be in R&D phase rather than trying to design and implement a production system. And there's usually a minimum amount of the system that has to be present for the system to function sensibly at all, trying to release anything before you've got to that point is an exercise in futility.
Major /.er reply: "This morning .... regained consciousness ... FUCK.
I like Agile methodologies, although I recognize that they are not suitable for all type of projects. But on this case, the problem is not the supposed methodology used. The UK government (well, that goes for every government) has failed big projects with different methodologies (waterfall, prince2, ...) The problem resides on the companies used and the view of the bureaucracy that they need to cover their asses.
Once thing that peeves me is that the are people, even here, thinking that programmers are code monkeys. Your analogy with building is absolutely wrong. The programmers are not the workers that do the actual build. That is the job or your make, msbuild or ant. Compared with actual building, construction on a software project is infinitely cheaper. The programmers are the building architects, your tests (be either unit, integration, system or what not) are the formulas used by architects to calculate that the distribution of strength allows the building to stay upright. Every analyst, project architect or project manager on top, is just additional bureaucracy. Especially the ones that have done no coding at all and think that the system they have designed is the 8th wonder of the world. I don't think anyone will ask someone that doesn't know the steel coefficient of elasticity or its strength properties to design the next skyscrapper.
Finally, to answer to someone over here, in software development you can start designing first a "hut", and then, as you advance in the project you can refactor, add or delete code (which is just an architectural plan) to support a bigger system (first a two story house, then a 10-story building, then your skyscrapper)
... so much as a reflection of the fact the risk of development failure increases proportionally with the size/scope of the system being developed, and this is/was a very large system.
Or, to paraphrase a quote I heard (Google can't find it for me, alas):
"There are two types of complex system; the type that started out as a simple system and grew more complex over time; and the type that doesn't work."
I don't care if it's 90,000 hectares. That lake was not my doing.
I've been on multiple agile projects and let's just say that it failed over and over when Agile was the only methodology employed.
Agile plus Test Driven Development plus peer programming and/or code review plus a solid set of automated unit test tools tends to work. Agile also works best in an environment of mostly mediocre developers who happily code what is on the sticky note. They are willing to work on one mundane task after the next after the next.
Agile also works extremely well when you have at least one full time "cowboy" who is creative and is expected to follow the project through and regularly identify which direction things are moving and catch when you're about to be boxed in before you get started.
Agile is almost perfect for database applications which require no new technologies and can be implemented in a single uniform method across the board. It's absolutely ideal for projects where it's just a huge amount of code made up primarily of lots of forms with lots of data. This is why things like "Business Intelligence" middleware is so important. When these types of projects are being made, often the developers shouldn't be working on trying to write optimised queries which require fancy handling of stored procedures for example. Get the project finished, throw a crap load of hardware at running it and then optimize it afterwards. Make sure that no code is written at all without a unit test to make sure that when optimization happens, it continues to work as designed.
Any project is subject to corruption by the management, regardless of what is the term used to describe their justification for being there in the first place.
The problems with "software engineering" don't have much to do with software, and much less with engineering - a lot with bloodsucking bureaucrats who barely know how to use a spreadsheet or M$ Project. Announcements of the kind "Agile project failed" are already part of the cover-up they suggest that it is this or that methodology to be blamed, rather than people in charge who should not be in charge of anything.
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.
I think they just wasn't agile enough
For those who don't have time to read to the end of the article (apparently most posters):
"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"
To some degree, agile is sold as, "Implement this and you'll never have to really manage a software project again." Just follow the steps, we are told, and everything will just work itself out. When agile fails, we're told it is because the steps weren't properly implemented. Everything is put on the method and very little demanded of the ones in charge. That's a really prescription to fail; accountability is the first requirement for success.
The client is the government. You are not the government. You are the end user of the software and the client/customer of the government.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
*most* software projects don't have constraints that mean a reasonably-sized team cannot have a working system that is doing something useful within 4 weeks (which is about the longest an agile process will usually let you go without delivering useful software).
This debate has, very reasonably, become a matter of the degree of applicability of agile methods.
Insofar as most projects are incremental changes to existing systems, I could agree with the quote. This is not, however, where you find the hard problems in software development.
Could the mega-project in question have been restructured as a series of useful, incremental changes to existing systems? Maybe, but doing so on a basis of anything more than wishful thinking would have taken some non-trivial planning and analysis, which is anathema to agile zealots (though not, I imagine, to agile's founders, who seem to be fairly pragmatic.)
Perhaps they should have tried a no management approach?
Have you fscked your local propeller head today?
While you can use a spanner to pound a nail, a hammer is better. "Agile" like "object-oriented", "top-down design", "structured programming" and many others before it, was just the latest in the long line of "faddish" software engineering methodologies. It has its place, but it is not the be all and end all. It is a tool that must be used judiciously and in the appropriate circumstances. My impression of "Agile" is that it works best on initially small projects with minimal requirements that grow quickly by accretion. At some point in time a certain threshold is reached, the law of diminishing returns kicks in and "Agile" gradually loses it potency. I cannot imagine "Agile" working in a situation where the requirements are the size of an encyclopedia set and not a lick of code is written. I don't see it working very well in this kind of scenario.
Read "Extreme Programming Refactored: The Case Against XP" by Stephens & Rosenberg. They have a good overview of the C3 (Chrysler Comprehensive Compensation) project where this stuff started. The XP guys never mention that it delivered nothing in four years, cost a ton of money and was completed with a conventional approach within schedule and budget later.
The strength of agile is obtained when you can develop one story at a time. This project has to support n different government programs. I don't know anything about the UK, but I'll guess that there are interactions between the programs. First you try to develop support for one thing in one program, but that thing needs info about some other program before it can figure out how much, when, or whom to pay. And vice versa, if you collected from them, you can or can't get this from us until you have tried the other for a while, but then this other other one might get you instead sort of requirements. So nothing is ever finished easily, you write code and leave holes to fill in when the other code gets finished, and you wind up with round pegs for square holes and vice versa and a few things done twice in different places and a few things no one has addressed.
so don't be surprised. The taxpayers, by the way, are not the client. The goverrnment is the product owner. Therein lies the rub.
-- Jimtown Kelly
I thought Agile was the solution to all the problems in the world!?
I used to be
Unfortunately this is never going to happen until the EU becomes a true federation and implements it universally - and at a universal level, independent of country GDP. Otherwise the first state to do it will see a giant influx of citizens from EU countries with lower guarantees.
"A *person* is smart. People are dumb, panicky, dangerous animals and you know it."
- 'K' in Men in Black.
If it's agile, then they must have something nearing working software, functional in some sense. Agile has given them the chance to more easily switch their strategy, rescope, resource - whatever, which they've done. The fact that they could switch back to waterfall is a prime example of its' flexibility.
It's a witch hunt, and agile got in the crosshairs.
Agile or waterfall doesn't matter. Any project may fail due to https://en.m.wikipedia.org/wiki/Pareto_principle
Casteism