As 2013 begins it's last few weeks, we may be experiencing the beginning of the end of poorly managed software development projects. I'll bet, if we take a close look, we will see all the earmarks of yet another disaster in the making. And don't get me wrong, this isn't an advertisement for Agile; I'm not condemning waterfall (though you won't catch me using it ever again).
The signs that marked the disaster that has become Healthcare.gov probably looked like this:
- Requirements were unclear and kept changing -- no matter how you're doing product development, someone has to OWN the product and be able to make decisions about functionality. When those decisions can't be made, are made by too many different people, or keeping getting made again and again with a different answer, you get a mess.
- Enough time to do it fast, not enough time to do it right -- it's already been said during the Congressional hearings about the project that the team really needed more time, but they couldn't get it.
- Software was not tested properly and was tested too late --- USA Today reported today that the general contractor responsible for the project said that testing on the site began two weeks before rollout on October 1. Does this sound familiar? Worse, while each of the independent contractors working on the project were doing some kind of testing during the "construction" period, integration testing didn't occur until the end.
The list could probably be made much more exhaustive, but there are plenty of people ranting about the website that this information is easily accessible elsewhere. My point is this -- this is the first time that a software project of this magnitude and everyday-American-impact has hit the headlines. Sure, there's been lots of government and privately funded disasters, but they are easily forgotten by the average American. This website, however, not only affects each and every American who needs insurance and doesn't have it (and wants to avoid the tax penalties in 2014 for not having insurance), but the website also represents a perfect opportunity for some politicians to complain and grandstand and for others to take cover.
In truth, this project isn't unusual in government or private-sector efforts. It's not even rare. The overall management and governance approach used in many traditional (and yes, many so-named agile projects) is outdated, ineffective, and wasteful. Politicians are complaining about how badly managed this project was, how many Americans are being hurt and how much money is being wasted. But truly, this project isn't an anomaly, it's a poster child for a litany of poorly managed and badly governed projects that are wasteful of funds, time, and people. Those same politicians are keeping silent about many other failed projects in their districts and states, projects that failed for the same reasons, hoping that everyone looks the other way while they rail on about Heathcare.gov as if it were a unique circumstance.
Perhaps the silver lining here is that our brothers and sisters in the software development ranks that took part in this project are not being subjected to this scrutiny in vain. Perhaps, something like this needed to happen in order to open the eyes of the government and the private sector in general that the typical way in which software development projects are managed and governed must change. The Healthcare.gov fiasco isn't unique, it's just uniquely positioned. If our leaders in Washington REALLY want to make a difference, they should look to the root causes of these disasters to avoid making the same mistakes again and again and again, instead of jumping on the bandwagon of the cause-célèbre.
What should have happened? At a high-level, some simple improvements would probably have made all the difference.
- Create a single owner - yes, the United States is a democracy, but software product development is not. In fact, it could be demonstrated quite easily that the fiasco that is Healthcare.gov is simply a reflection of the body ultimately responsible for it, Congress. Congress can't seem to accomplish anything in a reasonable timeframe either, right? If you want to build a website, you need to know what you want it to do and the kind of user experience you want people to have and you need to have one person who has the final say about functionality. Someone on this project, some close to the development teams, needed to have the authority to have the final decision.
- Communicate and Collaborate - multiple vendors were involved in the construction of the website and a single general contractor was responsible for the entire project. But in this structure, information has to pass up and down through layers of responsibility instead of across teams. The teams on the project, no matter who they were employed by, needed to be treated as if they all worked together and they needed to work together continuously.
- Continuous Testing - testing is NOT something you do at the end. Definitely integration is not something that should occur at the end. The development teams should have had a test strategy in the very beginning that would support continuous automated unit and integration testing throughout the course of the project. Yes, this means that development initially may take a little longer, but it supports shorter development cycles (internal releases), smaller batch size (increments of functionality), an earlier and deeper view of the functionality being developed (supporting better decision-making earlier in the project), and would raise the flag far earlier if there were integration or performance problems.
In the end, it's really not about Waterfall or Agile, it's about recognizing that software product development is not a defined workflow (think Henry Ford and assembly lines) -- it is an empirical workflow (think game development labs or studios where creative, even artistic, work is done). When we understand the underlying nature of the workflow (and stop fooling ourselves that strict management controls is all we need), we can create high-value, high-quality software on-time and on-budget. This is not a Republican failing. It's not a Democratic failing. This is how the government and most private and public corporations work today. But it's the wrong way to do software development. Perhaps Healthcare.gov is the beginning of the end of bad software projects?