Like everyone else in the country, I have been following the furor in the media over the Healthcare.gov technical issues with interest and a little bemusement. As anyone reading this post will already know, software projects get delayed all the time…almost every time. IT leaders have been fighting with software project deadlines since Royce proposed a process very similar to classic Waterfall in 1970. Unfortunately for CGI Federal (the largest contractor on the project) and Tony Trenkle (CMS CIO), the entire world was watching and a president was expecting…no pressure right? I feel sorry for all of the great engineers involved and look forward to the media frenzy dying down when the site stabilizes.
Sage Advice for Software Delivery
This situation reminds me of some sage advice I got from a mentor when I was starting out as a software delivery coach, “Don’t get caught with your pants down” or, more specifically, “always know exactly where your team is in relation to their deliverable and timeline”. This sounds like really basic advice but it is easy to lose sight of project goals when the heat is on, and it lends itself well as just one of a number of software testing best practices.
Distinguish where you are vs. the goal
At some point every day, I tend to ask my teams the question “where are we now in relation to our goal?” If I don’t get a crisp answer, or sense any hesitation from the team, we do a very quick progress assessment together until we all feel that we have a good handle on where we are. When gathered directly from the source (the team), this information is an excellent complement to project progress tools like burn down charts or task boards. Eventually good teams will anticipate the question and include it as part of their update at the daily Scrum. When that happens on a consistent basis it’s a magical feeling……well for me anyway!
Practice good build hygiene
Expanding on the “where are we now?” theme, I like to encourage my teams to make the software build processes answer that very question as early and often as possible. “Build hygiene” is a key factor in understanding where you are at any given time on a project. If the build is broken the team should be aware as soon as possible in order to focus their energy on fixing it before adding new functionality into the mix. Again, sounds like a very basic approach but it actually requires some forethought and discipline. It takes time and effort to set up your build processes to run and report more than once a day. It also takes discipline and focus to commit to keeping the build clean rather than just checking in more stuff and worrying about fixing the build later.
There has been a lot of blame for the state of the Healthcare.gov project handed around. I’ll bet there will be many books to come. There are the usual rumors of late specifications, last minute feature creep and burned out engineers raising red flags to management to no avail. This sounds very familiar right? We have all been part of difficult projects with unreasonable expectations and deadlines. As leaders, the best we can do is make sure that we (and our teams) maintain a clear, daily understanding of where we stand in relation to our project goals. If we don’t have that clear understanding then we can’t adapt our approach in order to give the team (and project) the best chance of success, which is ultimately our goal.
There are many simple tactics that can be leveraged to give your delivery team a better chance of success. Keeping the build “clean” and asking “where are we now?” are two that I have used successfully. I encourage you to think about using similar simple tactics on your projects as there is nothing worse than that chilly feeling when you realize that your pants are not where they should be.
***Using advanced software testing approaches, Belatrix Software works with its clients to ensure that their software product development efforts succeed. Thru QA & testing, Belatrix works to minimize exposure risk and vulnerabilities and accelerate fixes in alignment with the agile development process. This means that issues are identified early and fixed sooner vs. waiting until just prior to deployment. To learn more, contact us.