[NB: This is an excerpt from https://pragprog.com/magazines/2013-02/estimation-is-evil, by Ron Jeffries. I've selected the vignette about C3 and piecewise updating because it applies to so many systems out there. The whole post is important, I hope you can read it all -- Peter]
One of the best-known long-term Agile projects was Chrysler’s C3 payroll, the first Extreme Programming project.
I was once present for an exchange between Sue Unger, then CIO of Chrysler Corporation, the highest-ranking IT executive I’ve ever met, meeting with the C3 team. Kent Beck had just explained how we’d be working in iterations of a few weeks duration, building whatever our “Customer,” Marie DeArment, asked us to build. Ms. Unger asked “How will I know whether you’re on track or not?”
Kent held up our stack of story cards for the payroll. “Here are all the things we have to do. We’ll be adding things as we discover them, and removing any that don’t need to be done. We ask you to visit us every month. We’ll show you these cards, and show you how many are done and how many are left to do. If you’re not satisfied with the progress, cancel the project.”
Sue Unger, the highest-ranking IT executive I’ve ever met, said, “I can do that.” If she can, so can you.
Now the C3 project was a payroll program, and Marie was a payroll expert, so she knew exactly what had to be done. The team had been working on payroll software, so they had a good idea of the need and what it entailed. Even so, we added and removed things over the course of the project, deferring work that didn’t need to be done, and picking up new items along the way. This was one of the best-planned projects I’ve ever seen, and even so, at least one third of the requirements were added, removed, or substantially changed.
Nonetheless, the team, and Ms. Unger, were able to tell whether things were going well enough by looking at the stack of work that was done, and the stack remaining to do.
As students of Agile history know, however, the C3 project was not entirely successful. Despite shipping a number of versions on time, the project was ultimately cancelled. The reasons were largely political, but clearly if the project had been perfect, it wouldn’t have happened. It took us some time to realize that there was a big lesson hiding inside that history.
The C3 project’s purpose was to replace the entire family of Chrysler payroll programs. It didn’t accomplish that. Many years later, the subsequent project to replace the entire family of payroll programs has also not accomplished it. We now realize what should have been done.
We should have replaced the broken bits, one at a time, most valuable first.
The fundamental idea of making a complete list of everything payroll, and clicking through it, was wrong.
Parts of the old payroll programs were just fine, and didn’t need replacing. Other parts never belonged in payroll at all. Some of these, like tax, were recognized as external, and were done using external programs. But other parts were assumed to be part of payroll, and therefore the new payroll couldn’t be released until it included those parts.
This was not the right idea. There was a much better, simpler idea that we didn’t see. There were things Chrysler didn’t like about its existing payroll suite. This part was too slow. That part was done differently in different payrolls. Another part was hard to maintain. And so on. We supposed that the job was to build a grand new payroll program to rule them all. Wrong.
What we should have done, and could have done, was to solve the problems one after another, in the order that Marie and the other payroll people wanted them solved, and deployed those solutions as soon as they were ready. Some of those solutions would have been kept in a central program, and some would have been separate modules. For example, the overall flow of payroll is important, and it should be managed carefully. At some point we would have needed to organize this into what we called “the line.” It’s not clear that we needed to do that first.
Another area that needed work was Chrysler’s savings programs. There were many savings plans, they were complex, and they interacted. We should have written a program, or a series of programs, to deal with that. Those programs needed to interact with the line, but they didn’t need to be part of it.
And so on. We could readily have worked on the problems a few at a time, in the order Chrysler needed them solved. We could have deployed those solutions as soon as they worked. There would be issues with keeping them cooperating, keeping them maintainable, and so on, but we had those problems anyway, and smaller independent modules would have been the right way to address that. We could even have run separate modules on different computers, at different stages in the time-keeping, calculation, disbursement process, and would very likely have produced a more efficient, more modular program.
Had we done that, much of that work would still be running today and only the parts that really needed to be redone would have been redone.
The C3 Payroll, held up as one of the original successes—and original failures—of Agile, would very likely have been more successful had it not assumed that the job was to predict when it would all be done, or even track and project when it would be done. The job was to convene a team to solve the problems of the Payroll organization, and when the return on that investment declined, to move on. More would surely have been accomplished, and quite likely more of it would be still running today.
It’s not ideal to think of our product as a long list of things we must do. It’s not the best idea to predict when we’ll be done, or even project when we’ll be done. The Agile Manifesto calls for Working Software. Take the next problem, solve it with working software. Really solve it, which means getting that solution in the hands of the people who need it. It’s not about planning, predicting, and projecting. It’s about choosing, building, and providing.