In a Forbes' article, HealthCare.gov Diagnosis: The Government Broke Every Rule Of Project Management, the author lists key reasons why the project failed:
As a Scrum Practitioner, I cannot but help reflect on "What if Healthcare.gov development were managed using Scrum?".
Since the US Government is ultimately the entity answerable to the eventual sponsor, namely the people of the US, you'd have a ScrumMasterUS and a ProductOwnerUS within the Government to be answerable to the people of the US1.
There will be a good number of epic user stories and some epic user stories may indeed reflect the scrum team hierarchy. We'd have to expect that ProductOwnerUS2 would be the entity responsible for creating this product backlog for HealthCare.gov.
It'd be the responsibility of ScrumMasterUS and ProductOwnerUS to ensure a steady output of Healthcare.gov functionality for the end-user. For example, they could say that, at the beginning of every calendar quarter, a new set of functionality would have to be turned online. This is quite doable for, if each of the 55 scrum teams were on a monthly sprint, you would have a chance of having the output of at least three individual sprints from each team for the quarterly output from ScrumMasterUS and ProductOwnerUS.
Now, it is important for each scrum team to adopt the scrum framework properly, so that each sprint produces an output that is potentially shippable, meaning potentially usable by relevant user types. And, if necessary, to ensure that only highly-tested output would go online, ScrumTeamUS could form a team that takes the output of the other 55 scrum teams through its own scrum process ... Some could argue that there should be no need to organize ScrumTeamUS in this exclusively quality engineering mode but, somewhere in this whole arrangement, lies the responsibility to ensure that half-baked software is not unleashed on the various user types and, most certainly, one particular user type, namely the public.
Is anyone in HealthCare.gov listening?
- Unrealistic Requirements
- Technical Complexity
- Integration Responsibility
- Fragmented Authority
- Loose Metrics
- Inadequate Testing
- Aggressive Schedules
- Administrative Blindness
As a Scrum Practitioner, I cannot but help reflect on "What if Healthcare.gov development were managed using Scrum?".
Firstly, due to sheer complexity of the Healthcare.gov web site, you'd need an arrangement of Scrum of Scrums, because we see from the article that:
"A total of 55 contractors were hired to produce the various pieces, and in order for all the steps to work CMS had to involve five federal agencies, 36 states, and 300 private-sector insurers offering well over 4,000 plans."A "no-brainer" approach would be to define 55 contractor scrum teams, with 55 contractor scrum masters & 55 contractor product owners, even though some of these 55 contractor teams might themselves have to be scrum of scrums. The 36 states and 300 private-sector insurers would take the role of stakeholders in these 55 contractor scrum teams and, working with respective ScrumMasteri and ProductOwneri, i = 1, 2, ..., 55, would help create the necessary user stories. And, there would be several user types — subscriber-user, state-user, insurance-user, ... — for which we would have user stories described.
Since the US Government is ultimately the entity answerable to the eventual sponsor, namely the people of the US, you'd have a ScrumMasterUS and a ProductOwnerUS within the Government to be answerable to the people of the US1.
There will be a good number of epic user stories and some epic user stories may indeed reflect the scrum team hierarchy. We'd have to expect that ProductOwnerUS2 would be the entity responsible for creating this product backlog for HealthCare.gov.
It'd be the responsibility of ScrumMasterUS and ProductOwnerUS to ensure a steady output of Healthcare.gov functionality for the end-user. For example, they could say that, at the beginning of every calendar quarter, a new set of functionality would have to be turned online. This is quite doable for, if each of the 55 scrum teams were on a monthly sprint, you would have a chance of having the output of at least three individual sprints from each team for the quarterly output from ScrumMasterUS and ProductOwnerUS.
Now, it is important for each scrum team to adopt the scrum framework properly, so that each sprint produces an output that is potentially shippable, meaning potentially usable by relevant user types. And, if necessary, to ensure that only highly-tested output would go online, ScrumTeamUS could form a team that takes the output of the other 55 scrum teams through its own scrum process ... Some could argue that there should be no need to organize ScrumTeamUS in this exclusively quality engineering mode but, somewhere in this whole arrangement, lies the responsibility to ensure that half-baked software is not unleashed on the various user types and, most certainly, one particular user type, namely the public.
Is anyone in HealthCare.gov listening?
1You now have at least a total of 56 Scrum Masters and Product Owners. If each of the 55 contractor scrum teams is organized as a scrum-of-scrum team, that is an internal complexity that the 55 contractor scrum teams can handle, but the ScrumTeamUS need not worry about it in any routine manner. And, if 55 itself is a large number for ScrumTeamUS to handle, one could consider 5 or 6 scrum-of-scrum teams, each comprising of several of the ScrumTeami, i = 1, 2, ..., 55, ...
2ProductOwnerUS would work through ProductOwneri, i = 1, 2, ..., 55, to ensure consistency in project output.
I think agile is key to successfully implement projects. I got my Scrum Master certification done and now working in a project using Scrum. and I am loving it :)
ReplyDelete