– A Great Example of Failing… without Agile

This is a story of contrast between two popular methods of software development. One is called “waterfall,” the other, “agile.”

Waterfall development favors listing a huge set of requirements for a system up front, letting developers go away for months (if not longer) and expecting a huge software product in the end.

The agile method does the opposite, favoring work done in phases, delivering “minimum shippable” parts of a software system in weekly or biweekly cycles. This allows for iterating — or adjusting to hiccups discovered in the previous cycle, changing features or quashing bugs quickly and avoiding getting an end product that doesn’t look a thing like what your users need.

Like many government projects, was developed under the waterfall approach — and to its near doom.

The key findings in the presentation found here come on Page 5. Even though it was written in March, the slide sums up most of the key problems we eventually saw with the rollout of last month: limited testing time, evolving requirements, over-reliance on contractors and “stacking” of all the phases of development. The really damaging decision, according to the consultants: launching “at scale.”

Find the full story here, and the slides here.


13 Replies to “ – A Great Example of Failing… without Agile”

  1. It may be I’m reading this differently, but it looks to me that presentation page recommends the waterfall approach for the project as the “ideal” method.

    In fact all of the recommendations are regarding locking down “release 1.0” and creating a critical path to be followed rigidly to the end.

    Not the best advert for the Agile approach… of course, it doesn’t look like they did it properly, but still.

    1. I think that’s kinda the point… the recommendations for (doing) waterfall were wrong.

      There are WAY too many variables to blame it on just one thing… but for sure, this was ill-conceived.

  2. Yeah I agree Peter, Not so sure that even using Agile would have saved this project. Having been a Scrum Master on a couple of CMS and SSA projects; its been my experience that leadership or the lack thereof has always been the weakest link in Govt IT projects. Leaving most integrators to decide, either to fight the leadership or go with the flow, keeping an eye towards the next SOW.

    1. Thanks Dave!
      I think this article points to even MORE unsaid issues…
      Like how many contractors on the work.
      Stable teams.
      Understanding metrics that matter.
      And more…

      While I think taking more… “modern approaches” could have helped. It almost doesn’t matter WHAT approach you take if people aren’t aligned on how to develop a complex system TOGETHER.

      Jerry Weinberg said that every problem in software is a people problem. Yup. That’s probably it, regardless of what process you use.

      1. I like John’s comment on the article too:

        “”… did use agile processes and it failed.” I disagree with the assertion, Michael. They CLAIM to have used Agile process. Robert Martin already pointed out that the claim fails the most basic possible tests for an Agile project — no matter what the process was called. Maybe Agile would have failed in this project, but calling a tail a leg doesn’t make it one. The core of the Agile approaches — ranging from Lean Manufacturing to Lean Startup to Agile Software Development — requires a business level mindset change. The description of the approaches used to build the site are the same as would have been used to purchase toilet paper in bulk — ergo, no matter what it was called or what trappings were adopted, it was Waterfall.”

        1. Old Habits are hard to break, especially in large institution. However, these failings are not just related to process, but to project leadership and the curse of “status Quo”

          1. Indeed. HHS acted as system integrator on this project. Not even the DoD, which is a huge purchaser of software solutions, tries to manage this sort of project themselves. It’s not their core competency; they would have done better to serve as the product owner and let people with real problem domain experience drive the design, development, testing, and roll-out. Would you hunt with a shotgun designed and built by a dentist?

        2. They used Scrum, badly. I keep telling people: Scrum is not a solution, it’s a method of working toward a solution. You can use Scrum to do your work badly, at least as easily as you can to do it well. Failures like this aren’t an indictment of Scrum, any more than a story about a guy who cuts his own leg off is an indictment of chain saws. Using “waterfall” as an epithet prevents us from learning important lessons about what actually happened. Jerry Weinberg is absolutely correct; you can’t solve people problems with methodology changes. If you can’t change the people, sometimes you have to change the people.

          As a guy who’s done a number of roll-outs of open enrollment systems for commercial clients, I’m going to post my observations in a few days. I wrote something last night, just want to let it ferment a bit.

Leave a Reply