Let's face it- Agile has become a codeword for let's micromanage software developers while increasing the pressure on them to deliver.
My theory is that Ken Schwaber and Jeff Sutherland came up with Scrum in order to limit management's ability to screw up software development in corporate settings. That was mixed with some observations about the need for iteration, not doing upfront work when it's wasteful (and it's not always wasteful) and visibility that came from the Agile manifesto.
However, one lesson I'm constantly re-learning is never underestimate people's ability to screw things up and I think Ken and Jeff underestimated.
The whole agile thing has been subverted and if indeed Healthcare.gov was done using "Agile" practices then this is another bit of evidence.
We, as software engineers, need to move away from these and figure out some way to qualify what makes good software engineering. You don't see non-technical hospital managers going around telling doctors where to place an incision and you don't see non-technical aerospace management telling engineers what bolt to use in a rocket engine. But for some reason "programming" has been demoted to something that just being "agile" is enough to do. Badly.
In his YouTube Scrum talk Ken Schwaber says something about if you have a poor team with bad engineering practices than Scrum will generate crap for you sprint after sprint. Somehow no one listens to that part.
Bingo. When you have project managers hounding you about "story points" and meetings of managers who are concerned about each individual's burn-down rate, it becomes a micro-managing clusterfuck.
When the estimating meetings happen without you and you're told "we think this will take you five story points" (that is, two and a half days) and then the build is broken for three weeks (because of all the people checking in code in a panic) and you're called on the carpet for being behind, then it's an atomic clusterfuck.
You're in a circle of managers and PMs.
"We're concerned about your burn-down rate."
"I'm concerned about your ability to manage a project more complex than calling the elevator to your floor."
"Are you going to be done . . . today?"
"Is the build going to fucking work . . . today, or any time in the near future?"
Then the circle jerks (none of whom has written a working line of code in five years, yet they've somehow "shipped stuff") gabble amongst themselves for a minute, look confuxed, dismiss you and call in the next developer.
> figure out some way to qualify what makes good software engineering
I doubt we'll ever be able to distill it to a formula.
People ran successful software projects decades ago, long before any methodologies were formally described. And they have failing projects now, even when they use a supposedly good formal methodology.
Instead of another alternative to waterfall, scrum, or agile, I'd propose the following ingredients for success: Organized people, a good working relationship with plenty of trust, a clear understanding of roles and responsibilities, realistic expectations, and colleagues who honor their agreements with each other. To name a few.
All of this is peopleware, not process. Unfortunately, there's no silver bullet to get this stuff right.
I agree with this and many times we are emphasizing the wrong question with our processes. Are we shipping on time or are we making good products? If we are making good products then we need to put the quality of products above timeline on occasion. Agile does take away at times longer term feature quality for the needs of short term milestones. i.e. a programmer will hack in a feature to get it done that week, then deal with problems with that implementation for weeks as there is no time to change it. Yet taking another week on that part would have saved a ton of time.
A good product a day late is still a good product. A bad product on time is a world of hurt not just for the programmers, for sales, the users, getting next projects etc. In the end it is good project management and programmers/contractors that can build a solid product, not just deliver on weekly Agile tasks. In the end the quality and product result from where people place their demands. If it is time as the main demand, over shipping a good product, then we know what happens.
I'm not so convinced it's been subverted. Scrum — even (or maybe especially) in pure theoretical true-Scotsman form — is just micromanagement collectivized.
We are a community of motherfucking programmers who have been humiliated by software development methodologies for years.
We are tired of XP, Scrum, Kanban, Waterfall, Software Craftsmanship (aka XP-Lite) and anything else getting in the way of...Programming, Motherfucker.
We are tired of being told we're autistic idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do... Programming, Motherfucker.
We must destroy these methodologies that get in the way of...Programming, Motherfucker.
1. Using user stories to define your requirements does not make your process agile, just like writing a traditional requirements doc does not make your process waterfall. It's not about the tools. If you're not capturing the requirements you need to capture, your process is just broken.
2. Design documents do not magically make your project successful. Agile doesn't like design documents because it typically uses more lightweight artifacts to capture design decisions--but it still captures them! Again, if those decisions are not captured at all, your process is broken.
3. Wat? Asynchronous vs. synchronous is a project design decision; how does this demonstrate the failure of agile methods?
Multiple sources ([1], [2], etc.) have reported that the requirements for the system were not known until Spring of this year, and that they were in flux until weeks before the release. That's not a problem that would be fixed with use cases, UML and design documents.
Healthcare.gov was not built in an agile manner. Sure, some items that are labeled as artifacts of agile-based software development, i.e. user stories, may have been utilized, but that doesn't make for an agile process. Heck, even an agile process doesn't make one agile.
To say it failed "despite agile practices" misses the mark. It's like blaming a roof for leaking despite the use of hammers. Process is a tool, and if used properly, it may be a solution. But pixie dust, it is not.
Those are two things that don't have anything to do with each other. You seem to think that every single web service and database works the exact same way.
Not that I'd hire the NSA folks per se, but I'd imagine that the NSA's programmers are full time employees. One thing that might dramatically improve government IT in general is to shift more of it in-house rather than relying on contractors.
Having actually worked with NSA programmers, I can tell you that while they tend to be absolutely brilliant, that doesn't necessarily make them any better at making things "easy to use", "intuitive" or even necessarily "good".
When it comes to algorithm design, reverse engineering, or crypto, I know exactly who to call when I need help. When it comes to a layout that works, or in many cases, even just coding up some fairly simple HTML with CSS, my NSA buddies aren't in the top 50 of people I'd call.
Yes, they're brilliant. The best of them though, produce websites (if they're capable of coding on the web) that look more like stallman.org than anything like healthcare.org.
Project went bad? It's just a matter of fixing the process.
That's a reasoning that's simple, easy to understand and entirely wrong. Contrary to what the evangelists' tell us, process has small (I'd almost say minimal) influence on software development failure or success.
The responsibility is on the lead project manager. He's not been good enough. A failure on a project of this size doesn't just happen overnight. If you just look, you can see it coming from miles away.
The solution will always be highly uncomfortable though. You'd have to stand up to powerful people who hold authority over you, fire sub-contractors or employees, significantly reduce scope, move deadlines. Big, high impact actions that won't be popular, hell they might even get you fired. Not a job for the faint of heart for sure.
It's depressingly typical of big corporations and organizations, to allow people not capable enough to be put in charge of such large projects. And it's even more depressing knowing tax dollars are being wasted in such huge amounts on relatively (big emphasis) simple software.
Isn't a system specified by legislation fundamentally at odds with an agile process? Neither the requirements nor the dates could change without an act of Congress (or in some cases, the President).
The author suffers from the common misconception that agile is a process for designing software. It is not. It is a process for implementing a design, while maintaining flexibility to feed implementation experience back up into the design process. It's this feedback that the author's process lacks. FTA: "This [process] will take a few months, but when it is done we will know exactly what we have to build." Most of the time, experience has shown this not to be true; only when you've gotten into the implementation do you know what you 'have to' build (within some reasonable timeframe). That's because large software projects are typically nonlinear complex systems, where small implementation details can sometimes have large design consequences.
There is no prohibition in agile from using UML, and the process is certainly not hostile to design. It may be that some people believe that using agile implementation processes relieves them of the responsibility to design their software, and that it's OK for user stories to be generated off the top of their heads without analysis. Those people are mistaken. Nowhere does agile promise to design your system for you.
As a user I would like to be able to use the Healthcare.gov with at least 50.000 people or more at the same time
Here's your story
I think it is the same deadly cocktail of empty slogans in politics that meet the naked truth of booleans in software that wreaks havoc among government IT programs all around the globe.
We should ban the use of booleans in any governement project from now on. Politics can't handle booleans.
So yet another magic bullet doesn't really work. Maybe one day we will learn that it is not the process that matters but the people. Good people will work with a good process that looks a lot like agile, but if you cram that same process down the throats of a random group of developers then you are going to get random results.
The details of the methodology don't matter. If you look at what http://semat.org/ is proposing for the standard engineering methodology for developing software you will find that it IS agile, but it is not specified down to the nth detail and more importantly, it is extensible and adjustable so that any significantly sized project can build their own compliant methodology and process within the SEMAT framework. That part is so often missing, where the developers themselves discuss how to go about building the software, and management listens to them and defers to the developers because they are software engineering professionals.
Having observed a few big projects failed like that in my country, I can't deny the feeling that "throw big money onto company/institute(s) X to deliver a very big system that will replace the old system on day Y" is an awesome recipe for a spectacular failure, regardless of the software development process and skills of the programmers. Eventually the initial failure would be converted into something usable by spending 10x more money and 10x more time.
Contrary, a minority of national-level projects that succeeded here were always almost things that were initially planned to be very small, experimental, with no hard deadline and implemented without a big-bang in media. The biggest distinction is that the small systems tend to be put in production only partially but much earlier, often as an opt-in, working in parallel to the old often paperwork based systems. So there was no huge switch to something new and the risk was pretty small. This is what agile means to me.
Failure is such a imprecise word. Assuming it works eventually is that failure or success? Success or failure, assuming you can even define them precisely, and blaming the result on some vaguely defined reason is pointless. You may as well blame healthcare.gov's problems on bad pizza.
I'll have to read the article, but at an initial reaction, I think this project was not suffering for a lack of "agile" practice.
The didn't need a bunch of "nimble", independent teams. They needed some early, stable requirements. Some early, hard deadlines that they had to hit. And a focus on making the fucking back end work, first.
The last thing this project needed was some sort of last minute "agile". Of course, now they'll attempt some variation of it, out of necessity.
Corporations act like using the word 'Agile' instantly brings the benefits of flexible planning and proper management to a team.
Most people never really interact with a proper agile process - its kind of a unicorn in the development world.
The failure is not necessarily the process but the managers not understanding that it isn't a silver bullet. It is often used as an excuse to delay requirements gathering or understanding of requested features from stakeholders. This leads to churn and failure.
The most successful, most praised by clients, most robust, most stable and most financially profitable applications I took part at were written by professionals using "waterfall" methods.
This were absolutely not a test-driven development but rather strategies i personally developed that resulted in the most stable and bug free deployments.
These were security applications, real time data backup and mirroring services.
Agile in the wrong hands (or heads) doesn't work and in many cases is just a buzzword.
Indeed. Especially if you really understand what you're trying to accomplish, waterfall can work just fine. Come to think of it, the most successful "greensfield" project I ever headed was essentially waterfall, in large part because I'd been designing it in my head for several years before, had implemented variations on many components in those years, and had figured out why everyone else who'd tried it had failed to a greater or lessor extent.
This seems to be a flawed analysis based off of a flawed analysis...
First, agile principles don't imply that an agile approach will always succeed where a waterfall approach will fail. It merely asserts that agile increases (not guarantees) the likelihood of success.
Second, the article's three sources didn't "proclaim that HealthCare.gov would not have failed if it had just used “modern” software practices, called agile development". The closest that comes is the third source that says, "None of these missteps would have occurred if the contractors had taken a gradual, agile approach." But in general, the articles were arguing that an agile approach would have improved matters, not guaranteed success.
Third, agile is a spectrum. People attempt agile within larger waterfall restrictions all the time. It doesn't work very well, but it still might work better than being 100% waterfall. But it doesn't change the fact that this was a project with guaranteed high traffic on launch day and a hard deadline, and a prohibition to deliver a smaller MVP early. That right there is incompatible with the purest forms of agile.
No, it failed because it was managed by technically inexperienced and/or incompetent people. These people know who they are (the contractors), but they won't admit it.
Talk about process all you want, but everyone is just waving their hands around spouting buzz words. A technically experienced (in large scale systems) management team can make sure the project is done right regardless of the process they use.
The "technically inexperienced and/or incompetent" managers by now have been well established, CMS on up to the White House, and CMS at least has officially been removed from it's role, replaced by QSSI.
What I wonder is how many political types are still telling the new fix-it czar, Jeff Zients, what he can and can't do. I.e. right now all features that can possibly be punting into the future should be.
Although he said his #1 priority was to stop sending garbage to insurers, which isn't particularly political at this point, one would hope.
The evidence presented in the article is quite weak:
"I have seen some of the developer documentation, and it clearly discusses sprints, user stories and incremental testing — all of which are hallmarks of an agile process."
For a project with reportedly 50+ subsystems, where the main failures seem to have been integration, that doesn't tell us much either about this project or agile practices.
Nothing new, really. Methods and tools can help you, but do not guarantee success. Saying that some project failed because they used/didn't use something dosn't make sense to me. In the end, it's all about developers and overall project management.
Many software development failures are due to lack of understanding and controlling the complexity given cost, people and time constraints.
Processes helps the controlling part but sometimes gives a wrong illusion that things are under control and thus hurts the understanding part: people stop bothering to think.
Building large software is really delicate work. You need to have a correct decomposition (thus to reduce the level of complexity) and have a good control of flexibility and complexity trade off on the component level.
It is somehow like solving a formula with many parameters. You can not just look at one or two of them.
[+] [-] YZF|12 years ago|reply
My theory is that Ken Schwaber and Jeff Sutherland came up with Scrum in order to limit management's ability to screw up software development in corporate settings. That was mixed with some observations about the need for iteration, not doing upfront work when it's wasteful (and it's not always wasteful) and visibility that came from the Agile manifesto.
However, one lesson I'm constantly re-learning is never underestimate people's ability to screw things up and I think Ken and Jeff underestimated.
The whole agile thing has been subverted and if indeed Healthcare.gov was done using "Agile" practices then this is another bit of evidence.
We, as software engineers, need to move away from these and figure out some way to qualify what makes good software engineering. You don't see non-technical hospital managers going around telling doctors where to place an incision and you don't see non-technical aerospace management telling engineers what bolt to use in a rocket engine. But for some reason "programming" has been demoted to something that just being "agile" is enough to do. Badly.
In his YouTube Scrum talk Ken Schwaber says something about if you have a poor team with bad engineering practices than Scrum will generate crap for you sprint after sprint. Somehow no one listens to that part.
[+] [-] kabdib|12 years ago|reply
When the estimating meetings happen without you and you're told "we think this will take you five story points" (that is, two and a half days) and then the build is broken for three weeks (because of all the people checking in code in a panic) and you're called on the carpet for being behind, then it's an atomic clusterfuck.
You're in a circle of managers and PMs.
"We're concerned about your burn-down rate."
"I'm concerned about your ability to manage a project more complex than calling the elevator to your floor."
"Are you going to be done . . . today?"
"Is the build going to fucking work . . . today, or any time in the near future?"
Then the circle jerks (none of whom has written a working line of code in five years, yet they've somehow "shipped stuff") gabble amongst themselves for a minute, look confuxed, dismiss you and call in the next developer.
"Spartacus, you're next!"
This'll be good.
[+] [-] jarrett|12 years ago|reply
I doubt we'll ever be able to distill it to a formula.
People ran successful software projects decades ago, long before any methodologies were formally described. And they have failing projects now, even when they use a supposedly good formal methodology.
Instead of another alternative to waterfall, scrum, or agile, I'd propose the following ingredients for success: Organized people, a good working relationship with plenty of trust, a clear understanding of roles and responsibilities, realistic expectations, and colleagues who honor their agreements with each other. To name a few.
All of this is peopleware, not process. Unfortunately, there's no silver bullet to get this stuff right.
[+] [-] drawkbox|12 years ago|reply
A good product a day late is still a good product. A bad product on time is a world of hurt not just for the programmers, for sales, the users, getting next projects etc. In the end it is good project management and programmers/contractors that can build a solid product, not just deliver on weekly Agile tasks. In the end the quality and product result from where people place their demands. If it is time as the main demand, over shipping a good product, then we know what happens.
[+] [-] prostoalex|12 years ago|reply
If you have an excellent team with superb engineering practices, why would you be reading up on agile anyways?
Organizations rarely want to change a working process willy-nilly, they only go shopping around for a better if the current thing doesn't work.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] kps|12 years ago|reply
[+] [-] 5vforest|12 years ago|reply
[+] [-] trentmb|12 years ago|reply
EDIT: To clarify, his style is incredibly annoying.
[+] [-] mercurial|12 years ago|reply
[+] [-] gemma|12 years ago|reply
1. Using user stories to define your requirements does not make your process agile, just like writing a traditional requirements doc does not make your process waterfall. It's not about the tools. If you're not capturing the requirements you need to capture, your process is just broken.
2. Design documents do not magically make your project successful. Agile doesn't like design documents because it typically uses more lightweight artifacts to capture design decisions--but it still captures them! Again, if those decisions are not captured at all, your process is broken.
3. Wat? Asynchronous vs. synchronous is a project design decision; how does this demonstrate the failure of agile methods?
Multiple sources ([1], [2], etc.) have reported that the requirements for the system were not known until Spring of this year, and that they were in flux until weeks before the release. That's not a problem that would be fixed with use cases, UML and design documents.
[1] http://www.nytimes.com/2013/10/13/us/politics/from-the-start...
[2] http://www.huffingtonpost.com/2013/10/22/obamacare-website-p...
[+] [-] jroseattle|12 years ago|reply
To say it failed "despite agile practices" misses the mark. It's like blaming a roof for leaking despite the use of hammers. Process is a tool, and if used properly, it may be a solution. But pixie dust, it is not.
[+] [-] sanskritabelt|12 years ago|reply
[+] [-] iyulaev|12 years ago|reply
Building a database to track the communications of ever single person in the US and ever foreigner they talk to? Piece of cake.
Building a database to track the health insurance policies for a subset of Americans? Over budget, behind schedule, still doesn't really work yet.
Priorities.
[+] [-] caryhartline|12 years ago|reply
[+] [-] andrewfong|12 years ago|reply
[+] [-] bmelton|12 years ago|reply
When it comes to algorithm design, reverse engineering, or crypto, I know exactly who to call when I need help. When it comes to a layout that works, or in many cases, even just coding up some fairly simple HTML with CSS, my NSA buddies aren't in the top 50 of people I'd call.
Yes, they're brilliant. The best of them though, produce websites (if they're capable of coding on the web) that look more like stallman.org than anything like healthcare.org.
[+] [-] monokrome|12 years ago|reply
[+] [-] jacalata|12 years ago|reply
[+] [-] MortenK|12 years ago|reply
That's a reasoning that's simple, easy to understand and entirely wrong. Contrary to what the evangelists' tell us, process has small (I'd almost say minimal) influence on software development failure or success.
The responsibility is on the lead project manager. He's not been good enough. A failure on a project of this size doesn't just happen overnight. If you just look, you can see it coming from miles away.
The solution will always be highly uncomfortable though. You'd have to stand up to powerful people who hold authority over you, fire sub-contractors or employees, significantly reduce scope, move deadlines. Big, high impact actions that won't be popular, hell they might even get you fired. Not a job for the faint of heart for sure.
It's depressingly typical of big corporations and organizations, to allow people not capable enough to be put in charge of such large projects. And it's even more depressing knowing tax dollars are being wasted in such huge amounts on relatively (big emphasis) simple software.
[+] [-] natrius|12 years ago|reply
[+] [-] ericcumbee|12 years ago|reply
[+] [-] vannevar|12 years ago|reply
There is no prohibition in agile from using UML, and the process is certainly not hostile to design. It may be that some people believe that using agile implementation processes relieves them of the responsibility to design their software, and that it's OK for user stories to be generated off the top of their heads without analysis. Those people are mistaken. Nowhere does agile promise to design your system for you.
[+] [-] dep_b|12 years ago|reply
I think it is the same deadly cocktail of empty slogans in politics that meet the naked truth of booleans in software that wreaks havoc among government IT programs all around the globe.
We should ban the use of booleans in any governement project from now on. Politics can't handle booleans.
[+] [-] memracom|12 years ago|reply
The details of the methodology don't matter. If you look at what http://semat.org/ is proposing for the standard engineering methodology for developing software you will find that it IS agile, but it is not specified down to the nth detail and more importantly, it is extensible and adjustable so that any significantly sized project can build their own compliant methodology and process within the SEMAT framework. That part is so often missing, where the developers themselves discuss how to go about building the software, and management listens to them and defers to the developers because they are software engineering professionals.
[+] [-] pkolaczk|12 years ago|reply
Contrary, a minority of national-level projects that succeeded here were always almost things that were initially planned to be very small, experimental, with no hard deadline and implemented without a big-bang in media. The biggest distinction is that the small systems tend to be put in production only partially but much earlier, often as an opt-in, working in parallel to the old often paperwork based systems. So there was no huge switch to something new and the risk was pretty small. This is what agile means to me.
[+] [-] coldcode|12 years ago|reply
[+] [-] pasbesoin|12 years ago|reply
The didn't need a bunch of "nimble", independent teams. They needed some early, stable requirements. Some early, hard deadlines that they had to hit. And a focus on making the fucking back end work, first.
The last thing this project needed was some sort of last minute "agile". Of course, now they'll attempt some variation of it, out of necessity.
[+] [-] stirno|12 years ago|reply
Corporations act like using the word 'Agile' instantly brings the benefits of flexible planning and proper management to a team.
Most people never really interact with a proper agile process - its kind of a unicorn in the development world.
The failure is not necessarily the process but the managers not understanding that it isn't a silver bullet. It is often used as an excuse to delay requirements gathering or understanding of requested features from stakeholders. This leads to churn and failure.
[+] [-] gesman|12 years ago|reply
These were security applications, real time data backup and mirroring services.
Agile in the wrong hands (or heads) doesn't work and in many cases is just a buzzword.
[+] [-] hga|12 years ago|reply
[+] [-] tunesmith|12 years ago|reply
First, agile principles don't imply that an agile approach will always succeed where a waterfall approach will fail. It merely asserts that agile increases (not guarantees) the likelihood of success.
Second, the article's three sources didn't "proclaim that HealthCare.gov would not have failed if it had just used “modern” software practices, called agile development". The closest that comes is the third source that says, "None of these missteps would have occurred if the contractors had taken a gradual, agile approach." But in general, the articles were arguing that an agile approach would have improved matters, not guaranteed success.
Third, agile is a spectrum. People attempt agile within larger waterfall restrictions all the time. It doesn't work very well, but it still might work better than being 100% waterfall. But it doesn't change the fact that this was a project with guaranteed high traffic on launch day and a hard deadline, and a prohibition to deliver a smaller MVP early. That right there is incompatible with the purest forms of agile.
[+] [-] ternaryoperator|12 years ago|reply
That's not my understanding. I understand Agile to assert that it's better able to accommodate changes to the project during development.
[+] [-] fragsworth|12 years ago|reply
Talk about process all you want, but everyone is just waving their hands around spouting buzz words. A technically experienced (in large scale systems) management team can make sure the project is done right regardless of the process they use.
[+] [-] hga|12 years ago|reply
What I wonder is how many political types are still telling the new fix-it czar, Jeff Zients, what he can and can't do. I.e. right now all features that can possibly be punting into the future should be.
Although he said his #1 priority was to stop sending garbage to insurers, which isn't particularly political at this point, one would hope.
[+] [-] Gorimek|12 years ago|reply
"I have seen some of the developer documentation, and it clearly discusses sprints, user stories and incremental testing — all of which are hallmarks of an agile process."
For a project with reportedly 50+ subsystems, where the main failures seem to have been integration, that doesn't tell us much either about this project or agile practices.
[+] [-] koudi|12 years ago|reply
[+] [-] djvu9|12 years ago|reply