Agility and Project Leadership

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.

I found this article on the Defense.gov website and it seems they made a decision to go Agile with how they procure and deploy IT:

It seems lately that I'm finding quite a few articles on the web where people are moving away from Scrum to Kanban.  As this post from the blog "Journey of Continuous Improvement" indicates:

Some people will argue that we weren’t doing Scrum right so no wonder we had problems. But this is the crux of my problem with it – so much effort goes to doing scrum instead of channelling that focus to building better software, faster.  For my team, using Kanban to liberate us from a prescribed process and visualising the way we worked allowed us to have this focus.  I think there is a misconception that Kanban is a process and directly comparable to scrum. I don’t see it like that. I see Kanban as a set of practices which helps teams define their own way to work with absolute freedom. It wraps around your way of working and helps you refine it.

The section about liberating from a "prescribed process" was interesting to me as many think Scrum is about being flexible, but in reality if you're doing it "right" you have to come up with good story point estimates and plan your Sprints to ensure you deliver working software at the end of a Sprint.  Estimating is notoriously hard and even more so if you're doing cutting edge software.

In this post from "Blue Sky on Mars", it outlines a similar sentiment:

With Scrum, this sort of planning is built-in to the process. You estimate all of the stories in question, add them up and divide by the velocity to find out how many sprints it’ll take. Or, compute how many sprints you have and then you can choose which stories fit best into the time you have.