No Bad News

Back last fall, the ChryslerComprehensiveCompensation project did one of our regularly-scheduled CommitmentSchedules. It showed a delivery date substantially different from what we had originally predicted.

We analyzed what was making the difference. We had more people on production support than planned, and we quickly fixed that problem by building better tools. We had some other little problem, which we identified and fixed.

And we had not been authorized our Tester, the individual who enters data for AcceptanceTesting, runs them, nags us when they don't look good. The effect was that we were perpetually behind on our AcceptanceTesting - they got done late, and we weren't able to use them to know when we were done.

And we did not have the COBOL resources we had requested, which meant that our code to connect to the legacy systems was out of date. We were able to relate these resource shortfalls directly to the difference in progress.

We brought these latter two facts to the attention of our immediate PowersThatBe, who told us that times were tough. Not too much later, we were about to give one of our regular status reports to the CIO. Our immediate-1 PTB asked for a preview of the report. We gave it, reporting the previous two problems and showing how they impacted the schedule. The immediate-1 PTB said "I'll be interested to see how the CIO responds to this", taking a wait and see approach to our problem.

We presented our results to the CIO. She turned to the two PowersThatBe and said, not gently, "Why wasn't I informed about this problem?" Action began the next day to get the resources we needed.

We were lucky to get this response, and lucky to survive it. The reality is that our detection of the problem should have been sooner, our reporting should have been public enough and early enough to get it dealt with without embarrassing anyone or causing any disruption.

Kent points out that one reason WhyIsXpSoHard is that our adaptive approach is at odds with management's usual "go that way and come back when you're there" thinking. Another issue, however, is that no matter how hard you try to be on top of things, and to communicate them effectively, you can always do better. -- RonJeffries

Ron, it would be great if you could assign some times (month/year) to the events above... (a) when was the original prediction, (b) what was the original prediction, (c) what was the new prediction, (d) when was the immediately-prior CommitmentSchedule, (e) was that prediction the same as the original prediction, etc... -- BillSeitz

I remember reading an article about the culture at Microsoft that stated Bill Gates strongly enforces the notion that BadNewsNeedsToTravelFasterThanGoodNews. Unfortunately, not all of corporate America has learned this lesson, and you end up seeing the above response more often than need be.

I never read this page in my first year on Wiki, but the subject of these last two paragraphs is critical for the development of XP in my view. Also ... if C3 hadn't terminated (and PhilGoodwin not accepted a one liner on this bald fact) I would probably have never read this.

I have serious problems with Kent and Ron's view as expressed here and the same respect for Gates as I had before - a great deal. But increased faith in the breadth and quality of Wiki in the shaping process for XP in 1998. Nonetheless, to my mind the process was not thorough enough, because of the make up of the Wiki reader/writership, on the management implications.

Briefly, I believe that Kent is describing bad management or is projecting his past understanding of how software was likely to managed. From experience I believe the adaptive approach suits (decent) non technical managers much better - if we can crack the XpAndAnnualBudgets problem.

But this is simply an infuriating medium if you don't follow it from day one through to the end!

-- RichardDrake

I understand the words here, but not much else. Management did indeed make some mistakes, as did the team. We should have found ways to make our situation more public; they should have been realistic enough to adjust the expectations of delivery, and aware enough of the CIO's focus on the project to have informed her and/or solved the problems.

But somehow I feel I'm missing Richard's point ... help me out? -- RonJeffries