Most of the time, the decisions that come out of this process are surprisingly simple to implement. Programmers are good at seeing monsters lurking under every story. The business people say, "I had no idea that was so expensive. Just do this one third of it. That will do fine for now."
Sometimes, though, it doesn't work out that way. Sometimes, the smallest, most valuable chunk of development is large and risky from the programmers' perspective. When this happens, you can't blink. You will have to be careful. You can afford few mistakes. You may have to pull in more outside resources. But when the time comes to go over the top of the trench, then you really earn your money. You do everything you can to encourage smaller scope. You do everything you can think of to reduce risk. But then you just go for it.
Another way of saying this is that the split of power between Business and Development is not an excuse to avoid tough jobs. Quite the contrary. It is a way of sorting out those jobs that are
genuinely tough from those jobs that you just haven't figured out how to make simple yet. Most of the time the work will be simpler than you first imagined. When it isn't, you do it anyway, because that is what you get paid for.
Chapter 15. Planning Strategy
We will plan by quickly making an overall plan, then refining it further and further on shorter and shorter time horizons—years, months, weeks, days. We will make the plan quickly and cheaply, so there will be little inertia when we must change it.
Planning is the process of guessing what it will be like to develop a piece of software with a customer. Some of the purposes of planning are to
● Bring the team together
● Decide on scope and priorities ● Estimate cost and schedule
● Give everyone involved confidence that the system can actually be done ● Provide a benchmark for feedback
Let's review the principles that affect planning. (Some of them are general principles from Chapter
8, Basic Principles. Others are specific to planning.)
● Do only the planning you need for the next horizon—At any given level of detail, only plan
to the next horizon—that is, the next release, the end of the next iteration. This doesn't mean that you can't do long-range planning. You can, just not in great detail. You can cover this release in great detail and cover the next five (proposed) releases with a set of bullet items. Such a sketch will not lose much over trying to plan all six releases in detail.
● Accepted responsibility—Responsibility can only be accepted, not given. This means that
there is no such thing as top-down planning in XP. The manager can't go to the team and say, "Here's the pile of stuff we have to do and here's how long it will take." The project manager has to ask the team to take responsibility for doing the work. And then listen to the answer.
● The person responsible for implementing gets to estimate—If the team takes responsibility
for getting something done, they get to say how long it will take. If an individual on the team takes responsibility for getting something done, they get to say how long it will take.
● Ignore dependencies between parts—Plan as if the parts of development can be switched
around at will. As long as you are careful to implement the highest business priorities first, this simple rule will keep you from trouble. "How much for the coffee?" "The coffee is 25 cents, but refills are free." "Just give me a refill, then." This doesn't tend to happen.
Planning so the customer can establish priorities needs much less detail to be valuable than planning for implementation, where you need specific test cases.
The Planning Game
XP planning purposely abstracts the planning process to two participants—Business and
Development. This can help to remove some of the unhelpful emotional heat from the discussion of plans. Instead of, "Joe, you idiot, you promised me this by Friday," the Planning Game says, "Development learned something. It needs help from Business in responding in the best way." There is no way that a simple set of rules is going to eliminate emotion, nor is it intended to. The rules are there to remind everyone of how they would like to act, and they provide a common reference when things aren't going well.
Business often doesn't like Development. Relations between the people who need systems and the people who build systems is so strained, they often resemble the relations between centuries- old enemies. Mistrust, accusations, and subtle and indirect maneuvering all abound. You can't develop decent software in this kind of environment.
If this doesn't describe your environment, good for you. The best environment is one of mutual trust. Each party respects the other. Each party believes that the other has their best interest at heart, and the interests of the larger community. Each party is willing to let the other do their job, joining the skills, experience and perspective of both.
You can't legislate this kind of relationship. You can't just say, "We know we've screwed up. We're terribly sorry. It won't happen again. Let's work completely differently, starting right after lunch." The world, and people, just don't work that way. Under stress, people revert to earlier behavior, no matter how badly that behavior has worked in the past.
What is needed on the way to a mutually respectful relationship is a set of rules to govern how the relationship is conducted—who gets to make which decisions, when the decisions will be made, how those decisions will be recorded.
Never forget, however, that the rules of the game are an aid, a step toward the relationship you really want with your customers. The rules can never capture the subtlety, flexibility, and passion of real human relations. Without some set of rules, however, you can't begin to improve the situation. Once the rules are in place and your relationship is improving, then you can begin to modify the rules to make development go more smoothly. Eventually, once they have become habit, you can abandon the rules altogether.
First, however, you have to learn to play by the rules. Here they are.
The Goal
The goal of the game is to maximize the value of software produced by the team. From the value of the software, you have to deduct the cost of its development, and the risk incurred during
development.