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?
Image attribution: Photodune
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Paul Makepeace says
Correct me if I’m wrong but even a two stage rollout instead of a one stage rollout didn’t help them because all the problems discovered in stage 1 were ignored and they carried on with stage 2.
Mark Levison says
I suppose you could argue since the Minister who owned the system choose to stick their head in the sand the problem was unavoidable. Perhaps. Even the two stage rollout done well would still have been a massive disaster, just a smaller one.