$50 Million Phoenix Fix – Avoiding Disaster With Scrum

As most Canadians can tell you, the rollout of the Canadian Government’s Phoenix payroll modernization system has gone disastrously badly. At one stage, there were over 80,000 civil servants who had payment problems, with some even losing their houses over the mess. I’ve seen everything from the contractor (IBM) to a lack of training being blamed for the problems. I suspect there is more than enough blame to go around, and it will take years to discover what really happened.

Early and Incremental Delivery

They say hindsight is 20/20, but it’s also a useful tool to avoid history repeating itself. So how could we have done this using Scrum, and minimized, or even eliminated, the pain? Most organizations can’t afford to pay $50,000,000 to fix an “oops”.

A basic tenet of Scrum is that it requires the team to develop truly shippable software every sprint. Or, to use an analogy that doesn’t involve Scrum knowledge, eat an elephant. How do you eat an elephant? One bite at a time, of course.

If we used Scrum as our tool, instead of putting all our weight on a big bang, two-stage rollout, we could rollout to smaller departments at first. If we can’t get things up and running smoothly with fewer than 200 people, then we’re not ready for much bigger. In departments with more complicated needs, do smaller rollouts until the specific needs are well understood.

Strangely, if it had been done this way, most of us would never have heard about Phoenix.

Let’s hope the Canadian Federal Government learns about doing Scrum before it commissions its next large project.

What has your experience been with Early and Incremental Delivery?

Reference: https://www.cbc.ca/news/canada/ottawa/phoenix-pay-update-deadline-1.3751126

Image attribution: Photodune