The cost lever is actually several mostly independent levers. Moving any of them can increase or reduce your costs, but each lever has a different effect on the three other primary levers.

The most powerful lever is people. You increase this lever by putting more people on the project. This lever, however, suffers from having both a nonlinear effect and a long delay.

The nonlinearity comes from the communication overhead of having more people. Doubling your team doesn't make you go twice as fast because it increases the amount of communication that needs to go on. There isn't really much guidance we can give you on this, partly because there isn't the data and partly because so many other factors have an effect. All you can do is add some people and measure the effect.

The trouble is you'll have to wait to really see the effect, since adding people causes several changes that take time to play out. The immediate effect is the alarming sight of nothing changing, or even worse, a slowing down. When a new person joins a running team he will initially be of little value because he doesn't know the system or the team. Indeed, he can slow things down because he drains time from other people as they teach him about these things. The more people you add, the bigger this slowdown effect is. Add enough people and the project can come to a big crunching halt. This is the origin for Brooks' Law, "Adding people to a late project just makes it later."^[1]

There are other ways to spend money. Spending on tools can be like adding people. But you will slow down as people learn how to use the tools, and only when they become comfortable with the tools will you know whether they will help.

Spending some money can have a very good return: faster computers, bigger monitors. Don't be afraid to spend money to keep motivation up. Well- motivated developers are much more effective than people whose motivation sags.

Overtime doesn't help. Although in the very short term it does speed up the team, if you do it for any length of time you will get bitten badly. The big killer is motivation. It's much better to have a motivated programmer work seven hours than a tired, distracted programmer work ten. Even if the programmers want to work long hours it's not a good idea. Long hours make people tired, tired people make mistakes, and mistakes take time to fix. We've both gone into clients in the morning and spent all day chasing a bug that was put in at ten o'clock the previous night. Particularly with young Silicon Valley teams, where long hours are such an important tribal ritual, we have to work hard to get people not to do overtime. If they really have no life, get them to play computer games in the evening instead. It's much more productive to have castles mown down by trebuchets than it is to slip bugs into complicated software.

Quality is really two levers: external and internal quality. External quality is the quality perceived by the customer. This includes bugs but may also include nonfunctional requirements such as how the GUI looks and how fast the software is.

Try to move nonfunctional requirements over to scope. Make a story for something like "Make the user interface more pleasing" or "Get average claim processing time to under 300 ms." As we'll see later, scope is the best lever to operate.

Bugs are often also a scoping issue. Often you may have to trade defects for stories. We'll talk about this more in Chapter 22.

The other lever is internal quality. This reflects the quality of the internals of the system: how well it is designed, how good the internal tests are, and so on. This is a very dangerous lever to play with. If you allow internal quality to drop you'll get a small immediate increase in speed, rapidly followed by a much bigger decrease in speed. As a result you must keep an eagle eye on this lever and make sure it is always up as far as it can go. Nothing kills speed more effectively than poor internal quality. That's why Extreme Programming puts so much attention on practices like testing and refactoring. If you keep internal quality high you can see where you are and predict where you can go.

So the first two levers are difficult to work with at best, and certainly impossible for exerting any short-term control. Time and scope are left as the best levers to operate. With most of our planning, we assume that qualtity and cost are fixed.

The question is how do we best operate the time and scope levers?

The complicated thing about these two levers is that they are placed on very different parts of the machine. The scope lever is right in front of you and just loves to be pushed up. Every time you pass the machine you want to push that lever up a bit and add another little story to the project. The machine responds with a cute little gurgle as an instant reward. "Yes, sir, we can do that, too, sir."

The time lever, however, is really awkwardly placed. You have to crawl on your hands and knees, crane your neck, and flip open the door labeled "Beware of the leopard." Because the effects on time when adding scope are so hard to see, people don't usually realize what's happening until it's too late and the machine is out of control.

Planning must make the time lever visible, so that every time you add scope you can immediately see the effects on time. You just need to arrange the mirrors to avoid the smoke.

You only really know where you are when you are at the end of project. So you need to end the project every few weeks—that's why we use iterations. The iterations force us to look at the time lever every few weeks so we can't avoid seeing the consequences of changing scope.

Planning now becomes a matter of figuring out which stories to build in each iteration.

We need a planning style that

At this point we are getting tired of our Victorian machine and feel another analogy coming on.

What if planning for a piece of software was like shopping? When you go grocery shopping for the week, you have a budget. You go into the store and look around at the items and their prices, and you think about what you need to accomplish. If you are feeding a horde of teenagers, you tend toward rice and beans. If the boss if coming over for dinner, you get steak for one night and go easy the rest of the week.

The elements of the analogy are

Applying the analogy to planning:

The shopping analogy can carry us a little further.

Any time we have to decide what to do, we will go shopping. Who chooses how big the items are and who sets the prices will all vary, but the strategy is the same. We will shop for $5 million worth of software and we will shop for next week's tasks.