Extreme Programming Challenge Sixteen

Your sales team has just signed you up to completely replace every system in a Fortune 500 company with a new, unified system. You are required to stick with the technology and system your company implemented at another Fortune 500 company in the same domain. All FourVariables are constrained by the contract. If you do not meet the constraints your company will not grow that year and you will not be able to get any more contracts in this industry.

Quickly, you discover the system you are to "reuse" is not very reusable or flexible. Further, it, written in a combination of C, Cobol, Oracle Forms, PL/SQL, has business rules replicated in multiple places of the system. So, small changes typically take exponentially long to implement. Further, you cannot change to another technology or completely rewrite the system because there is no management support and you will be fired if you do.

The estimate for the project is based on ~100 people and you are required to use everyone of them. They have no background in object-oriented systems. There is no option to train for object-technology.

Nine months until the required date. What do you do?

What I would first observe, is that it is very easy to overconstrain the development process. Which it appears to me that you have done. I do know of one project, in which roughly 95 of the people were given several months of free time in which to train themselves on whatever they felt best. While the other 5 people set out to redesign the system. These 5 then invited a few others to join them over time, until they had a small team that eventually developed the new system successfully. The unused people did no more damage to the company than if they had been used actively on the project. --AlistairCockburn

First know the truth: determine how long it will take and how many people. See PlanningGame. Then tell the truth. If they fire you, collect severance, get a decent job. If they don't fire you, tell them how you are going to do the project. If they fire you, reuse the previous description. If they don't fire you, do the project correctly.

Chances of success are very low. Might be less stressful to eject. ExtremeProgrammer's don't sign themselves up for failure. --RonJeffries

Alternatively, bring in an ExtremeProgrammingMaster with your sole intent being to explain to management that they're in deep trouble and what to do. They might listen to the XPM. They might fire the XPM, but be more willing to listen to you. If neither happens, you know you're doomed. Eject. --RonJeffries

Basically, the project is doomed (I've just played out this scenario with a client who couldn't write tests because "development speed is our number one priority", so it's gut-wrenchingly familiar). MartinFowler and I did an XP workshop in Munich recently. I started it by asking, "How many of you are working on doomed projects?" At least 10 out of 50 people raised their hands. So the scenario is depressingly valid.

The seeds of victory or defeat are in the problem statement. The fact is that management hasn't constrained the four variables, they have only pretended to constrain them. The most you can do in this case is communicate to them the best case outcome. But it has to be done from measurements, not philosophy. So, here's what you do.

You work for one month XP style. You estimate before. You write the tests. You implement. You notice the actual time everything took. You do this with as many people as possible and still stay under managements radar (this might well be everybody). At the end of the month you spend a day estimating the rest of the project. Then you call the managers in front of the whole team and present the results-

Here's what we did. Here's what it means. If you don't like the answer, please change something. If management refuses to change, quit. If you can't quit, keep acting in accordance with your beliefs until they fire you (this will likely take longer than you might imagine since "excess honesty and integrity" aren't on the approved list for immediate termination). If you can't quit and you can't act with integrity, then I can't help. --KentBeck

Only 10 out of 50? That sounds surprisingly low to me. Maybe it's my poor luck, maybe it's my fault, but in five years in industry, I've only had a few months in which I wasn't working on a doomed project.

"Doomed" is surprisingly relative, and subject to the speaker's frame of mind. I have finally, maybe, lived long enough to see projects ship at long last, projects I had written off as doomed. The project sponsors wanted the software enough that they simply kept at it for 4, 5, 7 years, until they got it. In the early and mid stages, the participants thought the projects were doomed. The end stages were painful, but they made it. If you have only been in industry for 5 years, and one of these projects takes 4-7 years, then they would look doomed to you, but perhaps not to the sponsors.

I have seen projects that were so badly organized that you could safely predict that womeone would have to pull the plug. I have seen projects that went on for so long that you couldn't remember why anyone cared - some of these eventually got cancelled and some eventually shipped. In the 15 or so projects that I have personally been involved with, hardware and software, three I felt were doomed (one is currently shipping, two got cancelled), another three got canceled after they completed (marketing or other reasons), and the rest lived either short or long lives after completion, depending on other factors. Just personally, that is 3/15 or 20%, the same as Kent recorded, for a sensation of "doomed". Looking at it industry-wide, 20% doomed sensation seems like a lot, but from a personal perspective, being on only 3 doomed-sensation projects out of 15 seems like a pretty good deal. --AlistairCockburn

Yes, the doom-sensation is undeniably worse then the actual doom. I'd rather believe a project is going out the door and have a strong sense of efficacy before an abrupt cancellation than live with doom-sensations.

It is amazing that even the worst run projects often succeed but only after extreme pain. In many situations, you may not be doomed, but it is definitely going to be painful.

-- MichaelFeathers

The doom sensation is worse than the actual event of losing a project/having it canceled. At least that brings closure. Like I said, maybe it's me, but my first job (2.5 years) involved three projects that got shut down. My second job has had more successes, but the biggest failures were the ones I had the most invested in.

To try to get back to the original problem -- I don't think XP can save you if sales is making impossible promises. I don't think anything can save you. Either find a way out of the problem or find another employer.

Does anyone know of anyplace to talk about DeveloperMorale??

How about FearIsTheMindKiller? Nah, that's art. Let's use DeveloperMorale? if anyone has anything to say.

You are a doctor in an emergency room. A patient comes in on a stretcher. His head has been severed from his body. They can't find the head. How can you save this patient?

Wrap in aluminum foil and place in a deep freezer.

You want to add whole-body frostbite to his troubles? See CryonicsDoesntWork.

His problems are over. I assumed we were saving him for a snack during the next DeathMarch.

BTW, the phrasing above was a wonderful metaphor for a doomed project. My congratulations to the author.

Your sales team has just signed you up...

If your company is playing at the level of throwing 100 people at a Fortune 500 account, and if Sales is making commitments without Engineering having first done due diligence, then you have a rather different problem: Which works better for a resume? Palatino, or Times New Roman.

See ExtremeProgrammingChallenge