HealthCare.gov and Agile revisited

 

Last November I wrote a post on the initial botch up of HealthCare.gov’s use of Agile techniques on the front-end that didn’t help them deploy the site more efficiently, nor effectively.  So it was with interest that I ran into this Time article where it seems they brought in some heavy hitters from Silicon Valley and revamped the site so that it now at least is workable.

So the article points out the broken contracting process (no surprise) and the idea that the “traditional” methods of deployment were just too old school:

But one lesson of the fall and rise of HealthCare.gov has to be that the practice of awarding high-tech, high-stakes contracts to companies whose primary skill seems to be getting those contracts rather than delivering on them has to change…

One of the things that shocked [the rescue] team most–”among many jaw-dropping aspects of what we found,” as one put it–was that the people running HealthCare.gov had no “dashboard,” no quick way for engineers to measure what was going on at the website, such as how many people were using it, what the response times were for various click-throughs and where traffic was getting tied up…

What saved it were stand-ups... The stand-up culture–identify problem, solve problem, try again–was typical of the rescue squad’s ethic.

But wait a minute, didn’t the government contracts stipulate that they use Agile last time?  What was different this time?  You can read the article for more details, but my feeling is that it is often times easier to fix problems that have already revealed themselves.  And with such a large and public deployment like HealthCare.gov that did so badly the first time around, people’s expectations were as low as you could go so any improvements would look great.

Would getting the elite, heavy hitters from Silicon Valley initially been more beneficial?  Maybe, but then they would have dropped in with a style that is very contrary to the government’s style of IT deployments that it may have created more problems.  We’ll never know, but the lessons learned from this are one’s that we as project professionals should pay heed.