Cthree Project Terminated

The ChryslerComprehensiveCompensation page has a quiet addendum at the end saying that the current phase of the project has been terminated before reaching completion :)

Too quiet an addendum in my opinion.

This forum has seen a staggering amount of activity surrounding the adoption of XP on the C3 project. It seems unfitting that the project should end without getting a proper send off on these pages. -- PhilGoodwin

See: CthreeRetrospectByRonJeffries?

Sorry, Kent, I horked this from a posting you made on the ExtremeProgramming mailing list:

Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over. Or not, we'll see... -- KentBeck

So, I'm curious - does this represent a failure of XP? -- AnonymousCoward

Sensitivity, certainly. But if the people who tell you what to do don't agree with the people who evaluate what you are doing, you're stuffed, XP or no XP. -- KentBeck

So maybe XP can identify this situation much faster than, say, WaterFall can. That does not sound like a failure to me. -- PhlIp

I just wanted to say that I'm sorry for you C3 folks to be "stabbed in the back" like that. Must be hard.

Kent, in an ideal world, what would have been the XP way for the GoldOwner/GoalDonor to recognize and resolve this conflict? -- FalkBruegmann

So, three cheers for C3 for everything that it has begun to teach the world of software, even if the biweekly process didn't end up in production for the full 27000 people it was designed to apply to. (It's good to have confirmation as a result of these comments that the vast majority of monthly Chrysler salaries, around 9000, have been paid using the system for a long while now. And of the incremental nature of the deployment. Great stuff.)

Here are three initial reactions from someone who isn't too surprised or too bothered (initial because I agree with PhilGoodwin that a longer "post mortem" is probably called for given how much lineage has been devoted to C3 in these here pages).

Firstly, it's good to see the WikiTherapy? team working here to repair any damage done to those of good heart. This is genuine, NOT snide or ironic - this has been a major, positive feature of Wiki for me, alongside the amazing use of WikiAsXpTrainingCourse. "Software's too damned hard" not to have this kind of support, whatever your theories.

Secondly, "all software development projects end in failure". See the quote by Enoch Powell in AnAcceptableWayOfFailing. There's always a "current phase of the project that has been terminated before reaching completion" if you're doing it right.

Thirdly, we need to understand about PairingWithTheEnemy?. That was the talk I wanted to do at XP2000 but I just couldn't make 20 years' messy experience scientific enough (at least that's how it felt). Pairing matters across all project relationships - including the Gold Owner/Goal Donor in this case.

-- RichardDrake

Didn't AlistairCockburn give the C3 project six months to live after RonJeffries left? He signed and dated the post but now I can't remember where it is. I wonder how much truth there was to his prediction: which is the cause and which the effect or are the two events even related? -- PhilGoodwin

Ah, found it it's on HighDisciplineMethodology search for "date-stamp". It wasn't "to live" it was to stop following all of the practices.

NoBadNews is another interesting story about encounters with the C3 PowersThatBe around 1998.

KentBeck said: "Near as I can tell the fundamental problem was the the Gold Owner and Goal Donor weren't the same."

I think this is almost always the case if you have a OnsiteCustomer, since the GoldOwner usually cannot be full time on site. ScrumProcess tries to balance this by having the GoldOwner in the DemoAfterSprint? meeting (roughly equivalent to XP's IterationPlanning).

-- YonatSharon

However you cut it, the fully OnsiteCustomer is by definition only qualified to be Goal Donor because of their past work experience, including their relationships with key non-programmers up to board level if necessary. And that stuff can go out of date surprisingly quickly, especially with the level of corporate restructuring, mergers and acquisitions we're seeing in many large businesses - a situation software in the form of the Internet is not making any less volatile right now!

The GoldOwner on the other hand is a role with more than one person trying to fulfil it, in any large, competitive commercial organization that I've come across. Such people spot the apparent weakness of the official Goal Donor in a flash. The only answer is truly cunning EvolutionaryDelivery based on the most broadly agreed and visible SuccessStatements (UserStories), delivering results that maintain the credibility (and thus budget) of the project, including the OnsiteCustomer, with GoldOwners of all kinds.

So ThePlanningGameIsaPoliticalGame? at least in part - at least that's how we've always viewed it in ImpactModelling. This is something many software people dislike but to truly deliver in most commercial situations we simply have to face it, in my experience.

-- RichardDrake

I'm not clear on this. Is the C3 system now effectively in maintenance mode or has it all been thrown away and the project classified as a failure? -- TomAyerst

I had the same question Tom. But one of the last surviving members of the C3 team confirmed via email that the vast majority of monthly Chrysler salaries, around 9000, have been paid using the system for a long while now and this looks set to continue indefinitely. Whether they call it maintenance mode now I don't know. But the detailed story of the project since Beck and Jeffries arrived, coined XP and applied it, as told by this guy, I would rate as a classic long term evolutionary success story. With a classic evolutionary disappointment at the end: a phase that the development team thought was worthwhile but that the GoldOwner didn't. The key thing though is that a provably valuable system has been left in production.

The loss of the coach almost six months to the day before the disappointment can be interpreted at least three ways in my mind:

The last point we should always be ready for if BusinessValueFirst is being followed throughout. In fact this should become a bit like the Second Law of Thermodynamics for EvolutionaryDelivery (although true exceptions to this rule do exist and are very interesting). Most companies will not keep a coach going to the "bitter end". More importantly, in an ideal world - one without big egos and misunderstandings between people, little things like that - the end should not be bitter. The team size should reduce gradually down to "maintenance mode" levels - decreasing to one pair day per week or less. Full time coach looks a bit much on the balance sheet at this point, in fact well before this point.

I believe we still need to understand a lot more than we currently do about the evolutionary end game. I unashamedly put myself forward as one of the world's leading experts in this important subject!

-- RichardDrake

Of course I'm disappointed that C3 was shut down, and I believe it was a mistake due to the Goal Donor and Gold Owner not talking with each other on a timely or productive basis. The team didn't go off process when I left, they continued at least as smoothly as when I was there. I probably should have left before I did, but at the time, who knew? Not generally known is that the reason I left was so that they could buy a production machine that never went into production. I was replaced by a non-existent computer! -- RonJeffries

Ron, are you saying that the Goal Donor & Gold Owner talked to each other on a timely or productive basis earlier in the project but began not to? If so, do you think this change was due to any changes in personnel? (It's what we've often seen.)

Would it be possible to share some project planning info on the C3 project?

I would be interested in hearing what the original time estimates were for the project, its actual life time, and the percent complete when the project was terminated. An added bonus would be a periodic list of how the percent complete, projected completion time, and LoadFactor changed over the life of the project.

This would make C3 an excellent case study to show how well XP did in improving the estimation of a project.

-- WayneMack

Was any one else who was at XpTwoThousand chilled to hear FrankGerhardt describe how the situation causing the death of C3 poisoned both XP and Smalltalk at the Chrysler side of DaimlerChrysler? -- JasonYip

Could someone expand on this revelation please?

Jason is right, there's a lot of information valuable to the community that hasn't come out yet, it seems. A number of people that I spoke to after the final panel said that Frank's contribution had been both seriously concerning and usefully sobering.

If I remember correctly Frank said words to the effect that, at DaimlerChrysler these days the terms: "C3", "ExtremeProgramming" and especially "PlanningGame", and to some extent "SmallTalk", "GemStone" and "object-oriented" are now unutterable by anyone wishing management there to take them seriously. He got a rather nervous sounding chuckle from the audience with the line "Chrysler has done XP OnceAndOnlyOnce". Did he say that all of DC's IT development is now outsourced? (Tho' why wouldn't it be, they are a vehicle manufacturer, after all?)

The impression amongst the folk I spoke to was that in the view of DC's management C3 was a disastrous project, and never the like shall be seen again there. This echoes some of my own, and others', experiences when applying (some of) the practices: when one gets down to brass tacks, successful delivery of working software sometimes turns out not to be the thing most desired by the GoldOwner after all.

Anyway, the feeling was that there is a serious lesson to be learned here, regarding customer/manager responses to XP. Anyone else got any thoughts? -- KeithBraithwaite

I did some research and uncovered that the XP winter at DaimlerChrysler was not about the C3 project being successful or not. The gap in XP projects was caused by personalities clashing. XP was not used at DaimlerChrysler for a couple years because of a single man feeling that an enthusiastic XP supporter was disrespectful to him at a single meeting. It had to do with a man being overdue for retirement and nothing to do with XP. The truth can be stranger than fiction. There are many projects using XP and XP like processes now. -- DonWells

There was a definite impression of a managerial "frog boiling" going on (see BoiledFrogs). The corporate water was getting hotter and hotter while the project team wasn't looking (over a period of several months), monitoring corporate water temperature is a project manager's job...

So who was turning up the gas, and why?

"successful delivery of working software sometimes turns out not to be the thing most desired by the GoldOwner after all"

Most people are in fact fairly rational when it comes to gold, especially a real GoldOwner. If successful delivery means making a provable difference to the level of gold assigned to that person there normally isn't a problem. It's proving the linkage between many of our systems and gold-colored benefit that is the mystery. EvolutionaryDelivery and XP say there's only one way that we have the faintest chance, through delivering to real people that the GoldOwner cares about, in very small steps. What nobody with much experience would say is that all projects will prove the connection with profit. Some will take many months to be judged ill-conceived or that markets or technology have moved to make them unviable.

C3 took many man years of Smalltalk/Gemstone development starting at a time that Java was nothing like as commercially important as it is today. It was a Y2K replacement system at a time that Y2K turned out not to be such a big deal for the corporate bottom line after all. Corporate ownership and management positions, including I gather the role of SueUnger, who was CIO when Kent started, changed significantly. Such change is normal but has buried many projects.

This one has had a lot written about it though. If the XP practices were employed most thoroughly, for longer, on C3 than anywhere else, and the customer reaction is now as stated, the link between XP and business benefit is shown not to be guaranteed, to put it mildly.

-- RichardDrake

I don't know what happened at C3, Ron told some of the tale at a keynote during XP2000, but I think that a total change of management in both hierarchies (IT and business) during the project without enough attention being payed by the team must have had something to do with it. However corporate politics is a funny thing...

There is one (large) bank that will not use Java, and suggesting the use of Java on an in-house project is a career limiting (or ending, in one case) move (please, no comments on Java). The point is that this is not for technical reasons but rather because of a power struggle between two senior managers in the bank. One took a risk on a pilot project, when the project hit difficulties the other saw an opportunity, got the project killed (incidentally saving a lot of face for a project he was screwing up at the time) and incidentally branded Java as a dangerous technology for ever more.

The point being that unless you keep track of the managerial games (especially if ALL your management champions have moved on) you will be the sacrifice in some gambit. -- TomAyerst

Indeed, it strikes me that C3 was a CooperativeGameWithinInfiniteGames there, and the infinite games superseded the cooperative game called C3.

As mentioned above, C3 is not in the payroll business, and inside some larger game, outsourcing internal IT system makes sense. Of course, it is possible to screw that up,too... YMMV as they say. -- AlistairCockburn

The C3 onsite customer was recently overheard saying that he never thought of the the C3 project as anything more than an experiment anyway. He never believed it was destined to deliver a working system. TheGamesContinue.

I'd like to hear just a bit more about this! Which customer? -- rj

The last one.

Did he not believe it ever was going to deliver, and nobody would care either way; or did he not believe that it ever was meant to deliver? -- KeithBraithwaite

We don't know what he believed we only know what he said, which is why I mention it. Politics within a company can kill any project even an XP project. Already people who were responsible for C3 are trying to disassociate from it.

If you were the customer (GoalDonor) on an XP project that was unfunded WAY into the release cycle, by action of the GoldOwner, not by your recommendation, what explanation would you give for why you neither steered the project to success nor recommended its cancellation? CustomersFinalRole.

The impression amongst the folk I spoke to was that in the view of DC's management C3 was a disastrous project, and never the like shall be seen again there.

So what did they consider disastrous about it? Too buggy, too slow, too costly, high maintenance (Smalltalk is a dead language)?

I don't believe that it is considered disastrous per se. I believe that paying bi-weekly with C3 is considered a failure at this point, but monthly payroll is still a success and has many useful features the legacy system did not.

Maybe disastrous is too strong, but there was certainly the impression of a an air of odium. My guess would be that in some sense DeliveryIsNotTheGoal

[SunirShah's questions about refactoring vs reworking and XP UnitTests vs the StandardDefinitionOfUnitTest moved to XpVsStandardDefinitionOfUnitTest.]

In general, projects succeed or fail by a multitude of reasons. There is no way to even attempt to statistically dissect the C3 project in the hopes of gleaning a trend or too many cold, hard facts about software development. The best we can hope for is to learn as much about what worked well while things were going as planned, and what areas were in need of improvement. The whole cancellation thing seems beyond the methodology.

Once again, Software Engineering proves to be an oxymoron...

-- JonKern

How does the cancellation of C3 for non-technical reasons support the alleged oxymoronic nature of "Software Engineering"? Plenty of civil, chemical and mechanical engineering projects get cancelled for non-technical reasons. -- KeithBraithwaite

I don't want to open the hyper-criticism valve here (I know too well what it's like to be the other end of that on Wiki) but thanks for saying that Keith. (You even get a medal for using the engineering analogy in an entirely justifiable way, a rare thing in software.) This has always struck me as an extremely important page for Wiki (thanks to Phil for recognizing this and starting it). The oxymoron comment I felt was a particularly unfounded and inappropriate blanket statement to end with when I first read it. Something that I'd have been inclined to er, move somewhere else in earlier days, rather than criticize it here in place. But that has been known to hurt feelings too.

"The whole cancellation thing seems beyond the methodology" also seems a most unhelpful overstatement, in the light of what Kent asks in IsEarlierCancellationFailure. "The whole cancellation thing seemed beyond the boundary of possibilities some of the younger people considered during the height of the C3 hype on Wiki" might be a fairer reflection on the shock the news of the termination caused to some XP acolytes here (which it certainly shouldn't have, for reasons explained above). There was a stage when there was a little too much focus on C3 I guess. Perhaps that's why the XP conversation largely left Wiki, because it was hard for some of the people involved either to reread or to rewrite some of the pages which had established a very close coupling between XP and C3 here without er, pretty strong editing of those pages. But in the end this piece of WabiSabi is also good. It reminds us that we're all human. Even on Wiki. -- RichardDrake

Wait a second! It just hit me. C3 was canned, but they're still using it. Isn't that the WholeIdeaBehindXp??! "Well, even if the project gets cancelled, at least the customer has the most useful thing they could have at that point."

KentBeck from the interview of VlissidesOnBeck:

"Jeff Eastman asked me about it in Germany six months ago. He said, "Why do you do this? Why are you compelled to go and tell people about XP instead of just enjoying programming, and maybe helping your team?" You know, why do you publish books and talk at conferences and stuff.

I didn't have a good answer, and it bothered me a lot. But here's an answer I can live with.

I hate feeling that I've done a good job - technically the best job I could do - and my project failed anyway. It spoils the fun of programming for me to think that no matter how good a job I do, no matter how much aesthetic pleasure I take in my work day to day, the whole thing could still tank. Oftentimes it's simple little things that programmers have control over that could make the difference. It's important to me to take what I've learned about doing those little things and tell lots of people about it."

I'd say the situation with C3 is a great success, and I hope I don't just sound like a fan. -- RobHarwood

It has now been 18 months since I left DaimlerChrysler and the ChryslerComprehensiveCompensation system. The decision to stop further development on the software was made in January 2000. A lot of people have been speculating as to why this occurred and what are its implications for XP. As far as I can tell, all of this speculation has come from people who were not there.

At last report, the software is still running. It is not paying as many people as it did at its zenith. In fact, it is paying a very small group of former employees who are eligible for extended layoff benefits. Not what we had in mind when we started, but it is doing a job that no other available piece of software can do.

DaimlerChrysler still wants to replace all of their payrolls systems with a single solution and are gearing up to spend about 4 times C3's total cost to do it. This will be DaimlerChrysler's fifth attempt to do this. C3 is the only one to go live, in fact, at one point it was paying employees from what were three separate payroll systems.

None of this actually matters, because building a payroll systems was C3's secondary goal. I don't think anyone has written about this before, mostly because it happened before RonJeffries joined the team. The team's original charter, and it was reiterated when the decision to bring in KentBeck was made, was to learn how to use object technology, to learn how to manage projects that use it and if we built a new payroll system, that would be gravy.

There can be no question that we achieved the first two. New software at DaimlerChrysler is being written using objects (if you can call Java objects). Management was not happy that we didn't replace the old payroll systems, but they didn't ride us out of town on a rail. C3 alumni have gone on to lead development efforts in areas central to the company's success, areas such as cost management, vehicle manufacturing and personnel management. Reports of XP's demise at DaimlerChrysler have been greatly exaggerated. In fact, we are beginning to see a second generation of conference speakers come out of DaimlerChrysler. At the 2001 JavaOne conference Dave Boehme, gave a talk about how his team, with the help of a C3 alumnus, turned around a large scale J2EE project.

As best as I can tell, the decision to stop C3 development was made, not because we were wasting the company's time and money, but because it was time to use what we had learned on more important problems. We did not work for a payroll processing company; we worked for an automobile maker.

The techniques learned on C3 are now being used on projects that impact the bottom line. As a stockholder, I think it is a good thing.

With all that being said, what really happened at C3?

I don't think that there is one simple answer to that question. The best answer is that we stopped providing value to our customer. Elsewhere on this page the bifurcation of our customer is discussed. The fact that we had two customers, with differing goals, means that we violated the principle of a single on-site customer. Let this be a lesson to you! Your customer must speak with one voice and if that is not the case you will suffer. -- ChetHendrickson

When I was working at GE's R&D center we violated the same principle on a project for GE Capital in a similar fashion: managerial turnover on both sides weakened the commitment to the project so the GoldOwner and customer diverged. I think there is a general problem with projects that take too long - they live in an environment that can completely change many times over the course of the project. During the last several months our upper management worked very very hard to reaffirm GE Capital's commitment, but were not able to. Keeping projects sold is much easier when they have to be kept sold to the same person or small group of people. This should be a key consideration when creating a ProjectArchitecture.

As far as I can tell, the demise of C3 was an object lesson (geddit?) in why the way we choose to build code is one of the less important factors in the success or failure of IT projects. Most projects fail before they leave the board room. XP can't help there. Or RUP. Or SSADM. It's just not that important in the bigger picture. Set clear business goals. Hire good people. There, now that's a lightweight methodology for you...

-- JasonGorman

RonJeffries has some interesting comments to the story in http://groups.yahoo.com/group/extremeprogramming/message/87070

DaimlerChrysler is now working on yet another payroll system. They are using traditional methods and software practices. They are even using PeopleSoft. I need to get fresh details but the reports I have now (7/31/04) indicate that they have a big team, the biggest and fastest servers, have worked on it for about two years, and have not paid a single person yet. Compare that to a thin team, obsolete mini computers, and 11 months to actually start paying people with C3. Payroll at a very old, very large company is not as easy as you think which is why C3 was considered a success. -- DonWells

Considering the size and scope of the project the C3 team does not have anything to be ashamed of. I sometimes think the huge OneSizeFitsAll single application approach is dead wrong. We should focus on smaller tools that do a smaller set of things well. But how do you sell this to management when PeopleSoft and SAP sell them on their 'one size fits all, but your going to have to change your business processes' approach? Also, see this article about the failures of large ERP (SAP, PeopleSoft): http://www.cio.com/blog_view.html?CID=935 -pjl

See also: WhyIsPayrollHard

EditText of this page (last edited June 19, 2009) or FindPage with title or text search