Critics use the “failure” of a Chrysler payroll software initiative “C3″ as evidence that eXtreme Programming is flawed and not of serious value. Was it really a failure? Ron Jeffries says:
From the beginning of the project to the end, the C3 project
delivered exactly what they said they could, iteration in and
iteration out. The code worked with higher accuracy than the
existing program and was deployed against one large target
population and one or two smaller ones.
At the time the project was terminated, the system was correctly
calculating the payroll for the next target population, and
performance was good enough but only barely. Things had certainly
taken longer than people wanted … but also exactly as long as the
team’s velocity and Release Plans predicted.
At the time of project termination, all of the projects original
sponsors had moved on. There was no one involved other than the
technical team, including the XP customer, who had been part of the
original thinking or sponsorship.
The termination of the project brought no approbation of any kind on
any member of either the technical side nor the business side of the
project. It was an economic decision made primarily because the
project had been internally funded, and IT was under pressure to
find “synergy savings”.
It is interesting to note that since then, DC has spent many
millions of dollars trying to adapt PeopleSoft payroll to do the
things that C3 already did.
So, was the project a success, or a failure? It is hard to say.
Certainly it didn’t last as long or deploy as widely as one would
have liked. On the other hand, it delivered working software on an
incredibly predictable basis. A business decision was made to
terminate it, for business reasons.
C3 showed, for those who care to pay attention, that the XP
practices can work, and produce highly reliable software on a very
predictable schedule. XP is not the only way to do that. It is,
however, the best way I have seen in nearly a half century of doing
software.
Reliable production of software that solves the problem it was intended for, within budget and under control of the customer - these elements are all elusive to even the best software development teams around the world. I would not call that a failure.
My current employer decided to “try” Agile development for all software groups. My group joined the company as part of a purchase in December 2006. My coworkers resist XP/Agile with a great deal of energy. In one assessment, the group bristled at identification as people who cannot improve measurably by any means, including adopting, at any scale, Agile methods.
There is a difference between adopting a way of doing things and merely following orders to go through the motions. It’s very close to malicious compliance. No one really wants to get better, just left alone so they can do “real” work.