Kent Beck - Planning Extreme Programming

In On War, Carl von Clausewitz tells us that military history is a pendulum swinging back and forth between the relative advantages of armor and of mobility. The knights in shining armor were able to dominate any knight without, but they were no match for the quick, nearly naked pony warriors that swept across the plains with Genghis Kahn and his Mongols. Light cavalry itself was doomed as soon as there were tanks, and tanks were no match for fleet-footed Palestinian teenagers with Sagger missiles. With the Maginot Line, the French were gambling that the pendulum had swung again toward armor, but it hadn't, and the Germans simply went around it.

In the field of IT, we are just emerging from a time in which armor (process) has been king. And now we are moving into a time when only mobility matters. Building a product the right way still sounds like a laudable goal, butlet's face itwhat really matters today is building it fast. Because we are process-obsessed in our field, we have tended to react to this new imperative as we reacted to the imperatives thrust upon us in the 1980s and 1990s. We have asked, "What shall we add to our process to deal with this new situation?" No answer to that question is going to be right because the question itself is wrong.

What the new mobility imperative requires is that we subtract from process: We need to get light.

"Getting light" means more than just abandoning heavy process and its attendant mountain of documentation. It means investing in people so they can work quickly and effectively without formal process and without generating a ton of paper. No one has a better vision of how this is done than Kent Beck and Martin Fowler.

The XP movement they have founded is a way to make IT projects light and quick. The principles of XP are not just another methodology, another process. They are the antithesis of process. They are means to make process irrelevant.

Because XP projects are completely different, it stands to reason that managing them is different too. Planning Extreme Programming focuses on how a team of XP-empowered developers is optimally led. Beck and Fowler's prescriptions are often wry, sometimes wise, and almost always bang on target.

XP is the most important movement in our field today. I predict that it will be as essential to the present generation as the SEI and its Capability Maturity Model were to the last.

Tom DeMarco

Camden, Maine

A couple of times a week, the tracker checks progress on the iteration to see how things are going.

You have an iteration plan, so now all you have to do is sit back and watch the plan unfoldright? If you said yes, hit yourself on the head three times with this book (and be glad it's a thin one).

The only thing you know about a plan is that things won't go according to it. So you have to monitor the iteration at regular intervals. You need to have someone whose job it is to track progress in an iteration. We call this person the tracker.

When a meeting gets boring, leave.

Robert Cecil "Uncle Bob" Martin

Have a short meeting once a day so everybody knows what's going on, and what's not.

You'll notice we aren't into lots of meetings. Meetings are at the top of most programmers' lists of boring time wasters. But meetings are also a way for people to communicate. The challenge is to figure out what kind of meetings work well.

We've found that short daily meetings are invaluable for giving everyone an idea of what other people are doing. However the emphasis is on short. If the daily meetings ever start dragging, you'll run into trouble.

The stand-up meeting gets its name from one of the tricks we use to keep it short: Everyone has to stand up for the whole meeting. That reminds everyone to be brief. If they don't remember, remind them again (with a stick if necessary).

The format is simple. Everyone stands in a circle and you go round person by person (whether you go with or against the clock is up to you). Each person briefly says what he or she did yesterday and what he or she is doing today. Problems or announcements that are important to the team are passed on.

The purpose of the stand-up is to communicate problems, not to solve them. Keep the meeting brief. The usual stumbling block is when somebody says, "I implemented some code to the floop the foobar," someone else says, "I did something like that last month,""Oh, I needed a triple axel,""You can do that by modifying the config file." Suddenly it's on the way to being a long conversation. At this point you suggest, "Maybe you should get together this morning and talk about this." Anything that requires anything more than a brief announcement should be shunted off to another session where only those who are interested need to attend.

Have the stand-up meeting daily, so everyone knows roughly what everyone's doing. Pick the same time every day, and aim at a time when everyone is there. Earlier in the day is better, as that allows time for people to get together quickly if they need to.

Anyone should be able to sense the state of the project by looking at a handful of graphs in the team's working area.

We are big fans of the scientific method. Emotional outbursts like, "I think you are going too slow," or, "This software is riddled with bugs," don't help when you're trying to steer a software project. How fast are we going? What variety of Swiss cheese does the software most closely resemble?

Deming says, "You can't manage what you can't measure." We're sure this isn't true, because lots of software gets shipped without any metrics being gathered. However, if you choose to manage without metrics, you are committing yourself to a degree of emotional detachment that is difficult to maintain, especially under pressure. The numbers help you look your fears in the face. Once you've acknowledged your fear you can use informed intuition to make your decision.

The danger with a "scientific" approach to planning is that the measurements can become the end instead of the means. The overhead of data collection can swamp real work. The process can become inhumane, with peoplemessy, smelly, distractable, inspired, unpredictable peopleconveniently abstracted away to a set of numbers.

That's not what we are talking about. Don't do that.

Instead, here is a process that combines intuition and measurement:

1. Smell a problem.

2. Devise a measurement.

3. Display the measurement.

4. If the problem doesn't go away, return to 2.

Courage! What makes a King out of a slave?

Courage!What makes the flag on the mast to wave?

Courage!What makes the elephant charge his tusk, in the misty mist or the dusky dusk?

What makes the muskrat guard his musk?

Courage! What makes the sphinx the seventh wonder?

Courage!What makes the dawn come up like thunder?

Courage!What makes the Hottentot so hot?

What puts the "ape" in apricot?

What have they got that I ain't got?

Cowardly Lion, The Wizard of OZ

Software development is risky. People involved have many fears of what may go wrong. To develop effectively we must acknowledge these fears.

Why do we need a software process? For the same reason that we need laws, governments, and taxes: fear.

The Declaration of Independence says:

That among these [rights] are life, liberty, and the pursuit of happiness. That to secure these rights, governments are instituted among men, deriving their just powers from the consent of the governed.

Though the profundity of these words may distract us, consider the word