Developer Only Xp

I've had lots of successful projects, adding up to around a half-billion dollars in revenue. I've also had more projects fail or get cancelled than most people have had projects. Each time a project tanks, you try to figure out what made the difference.

Few of my problem projects have been due to "technical" problems; most have been "political" problems.

Internal to development, there are a lot of things that we can do to produce more quality code faster. Producing enough good enough code fast enough is, ultimately, what keeps a project out of the tank. The XP values of Simplicity, Communication, Feedback, and Aggressiveness clearly apply. I'll address that further in a subsequent page TBD.

Project ultimately fail, however, for political reasons: the GoldOwner's get fed up with donating gold and not getting back what they are looking for. Sometimes it is these GoalDonor's who have it wrong: a bad product idea, bad marketing, and so on. If so, I can't fix that: get a marketing consultant.

But the developers, doing XP on their own, can help with the part about "fed up". Assume, because we're all good developers here, that the team has the ability to build enough good enough software fast enough, using as little or as much of the techno side of XP as they use.

GoldOwner's get fed up because they believe that not enough good enough software is coming out fast enough. They may or may not be right in that belief, but it is the belief that counts. Once they lose faith in the team, it's over.

How can we avoid that loss of faith? Here's a scenario:

Imagine that we take the requirements, whether handed to us in a book or on the back of a napkin (or even on UserStory cards), and break them down into sensible chunks on UserStory cards if those weren't what we were given. So now we have UserStory cards, even if we had to cut up the spec, or imagine the spec, to get them.

Then we estimate how long each will each take. And imagine that as we go developing along, we keep doing that, in the small (IterationPlanning) and in the large (CommitmentSchedule). It should be clear that we'll get pretty good at knowing how long a user requirement will take.

And we give the stories business values as best we can. We communicate those priorities back to the GoalDonor's. They'll feed back what the values really are. At first they may try to say they're all imperative. We apply all our skills to GetBusinessValue?.

We begin to arrange the cards in business-value order, and to write the software in business-value order. We report our status every few weeks in terms of written, testing, known-to-work business value implemented. We present that in a context of our overall understanding of the CommitmentSchedule, showing how we have arranged the cards as our best understanding of the order to do things.

There's not a GoldOwner or GoalDonor in the world who can resist picking up cards and moving them forward and back in the schedule. When they do, you just keep reminding them that you can only put as many cards into as Iteration as add up to N (your secret number for how many engineering weeks you can do).

"OK, great, let's move Syntax Word Coloring forward. That's a 3. We have to find a 3 and move it back. How about Intelligent Curly Brackets, that's a 3 also? Oh, you'd rather move Optimized Goto for 1 and Parallel Loops for 2. Great."

Imagine. Every few weeks you tell them exactly where you are in terms of your ability to create real value, as they perceive it, as early in the project as they want it done.

Sure, they'll say you have to go faster. You can say whatever you want, then say "But whether we go faster or slower working 90 hours a week as you suggest, we'll report again in 3 weeks what really happened. That way we'll all have the best possible information about what's really happening."

In almost all of my problem projects, if I had broken down the requirements into individual chunks that could be talked about, prioritized, estimated. I'd have had better-informed management. Usually being better-informed would have meant that they better understood that we were OK. But at the same time, I'd have been better able by far to focus on what they really wanted.

I think there are entire companies that would still be in business if I had been smart enough to do DeveloperOnlyXp. Everyone here has always done their best. We wouldn't be bothering with wiki if we didn't. Here are some ideas for another arrow to add to our quiver: the ability to know what they want, and to tell them what is actually happening.

--RonJeffries

Makes me want to get cards with height proportional to the estimated times - a 1-unit high card means 1 work day, a 3-unit-high card means 3 work days. Then you put masking tape on the table for the increments, and let people move the cards around - it becomes obvious when the cards don't fit in the increments. --AlistairCockburn

Neat! It's all about scale. Say 15-20 iterations with maybe 12-20 weeks of engineering time available. Up to 400 cards. (C3 had 150 for the first release, about 400 for the second.) Let's see, with 4x6 cards, say 2 wide, 40 for 20 iterations = 20 feet wide by 40 inches high. Or 10 feet wide and 6 1/2 feet high. Maybe smaller cards? A separate planning set generated from the larger story cards?

I've thought about this a lot, 'cause the analogy of filling up the little rectangles would be so powerful and easy. Haven't found the trick yet. --rj

Do you really need to have all the iterations laid out at once? Maybe you could use the physical constraints of your tabletop to define the number of iterations you can plan at any one go. There's no reason that the GoalDonor's can't plan out the far future of the system, but keeping things somewhat abstract outside of a near-future horizon might not be a bad thing.

The way DeveloperOnlyXp was implemented in the VcapsProject was to have a manager act as the translator. In our case TrishBuckley? would present management with the appropriate MicrosoftProject reports. However when dealing with developers she had a big shoebox of cards. Cards were used to track completion of UseCases and development tasks while MicrosoftProject showed the traditional delivery dates and manpower loading. We used one-week iterations instead of 3 weeks. She also secured customer time for us. While we did not always have a customer co-located with us we did have the opportunity to go to the customer's work areas and observe their business practices and the actual usage of the system to be replaced. This was called CustomerShadowing. -- DonWells, TomKubit