Planning Extreme Programming: book notes

These are my notes from Planning Extreme Programming by Kent Beck and Martin Fowler.

Why Plan?

We plan because:

• we need to work on the most important thing.
• we need to communicate with others.
• when bad things happen, we need to understand the previous two things even more.

Everyone (customers, developers, managers) needs visibility at all time about how far along the project we are. To do this we use milestones.

If unexpected events cause things to go not according to plan, we must not pretend everything’s ok. The longer this happens, the more we deviate from the plan. Keep plans honest and expect them to change.

Fear

Customers are afraid that:

• they won’t get what they asked for.
• they’ll ask for the wrong thing.
• they’ll pay too much for too little.
• they must surrender control of their career to techies who don’t care.
• they won’t ever see a meaningful plan.
• the plans they do see will be fairy tales.
• they won’t know what’s going on.
• they’ll be held to their first decisions and won’t be able to react to changes in the business.
• noone will tell them the truth.

Developers are afraid that:

• they will be told to do more than they know how to do.
• they will be told to do things that don’t make sense.
• they are too thick.
• they are falling behind technically.
• they’ll be given responsibility without authority.
• they won’t be given clear definitions of what needs to be done.
• they’ll have to sacrifice quality for deadlines.
• they’ll have to solve hard problems without help.
• they won’t have enough time to succeed.

Unacknowledged fear is the source of all software project failures.

These fears need to be put on the table and dealt with. If they are not, developers and customers will build walls to try and protect themselves which will lead to the proper information not being shared.

Customers have the right to:

• an overall plan, to know what can be done when and at what cost.
• get the most possible value out of each programming week.
• see progress in a running system at any time, proven by repeatable tests they specify.
• change your mind, substitute functionality and to change priorities without paying huge costs.
• be informed of schedule changes, in time to reduce scope to restore original date.
• cancel at any time and be left with a useful working system reflecting investment to date.

Programmers have the right to:

• know what is needed with clear definitions of priority.
• produce quality work at all times.
• ask for and receive help from peers, managers and customers.
• make and update your own estimates.
• accept responsibilities instead of having them assigned to you.

Driving Software

Driving a car is not about getting the car pointed in exactly the right direction and calculating the speed in advance, but by constantly making little corrections to the steering wheel to get to your final destination.

Driving software is similar. You don’t get it right by planning everything up front and not deviating from it, but bu constantly steering and updating the plan.

Even if you have the perfect route planned, you may need to change it to avoid traffic or to pick up some extra food on the way home.

Balancing Power

Business people make business decisions:

• dates
• scope
• priorities

Technical people make technical decisions:

• estimates
• implementation

This is crucial and requires business and technical people to be involved with the project at all times. Neither should ever try and be clever and make the other decisions - they cannot possibly know - sometimes they can make guesses but that’s all they are.

If the customer is represented by lots of people, they must speak with only one voice. Somebody should be nominated. This person could be somebody from the client company, or a person in the development company acting as a proxy who understands the business needs (not a developer).

The customer must:

• be as much a part of the team during development as the developers.
• steer the project throughout the process.
• fully understand the domain.
• understand how the product being developed provides effective business value.
• not be scared to deliver too little rather than nothing at all.
• be able to make accurate decisions about needs required now and those that can be deffered until later.
• be willing to accept responsibility for the success or failure of the project.

The last item is the hardest and customers will often try to hide from this behind lots of requirement documents - this cannot work in XP. If you get lost driving, it’s the driver’s fault, not the car’s. If a customer refuses to work this way, then steer clear of XP.

Customers should be able to ask for small parts of functionality at a time rather than one huge system. The smaller the functionality, the quicker it is developed and they can start using/testing it and hense get business value from it. As soon as the small functionality is complete, the next piece can be developed.

Customers should trust the developer’s estimates, yet remember they are only estimates. The customer is never in a situation to make better estimates.

Overview

A project is typically delivered in a Release. This usually lasts from one to six months.

A release is broken down into Iterations. Each iteration lasts between one and three weeks. The result of an iteration must be a fully tested, production-ready system.

An iteration is broken down into Stories. A story is a small piece of functionality request by the customer.

The problem with an iteration being so short is that it leaves no time to complete the analysis, design architecture, build the infrastructure, setup frameworks, testing, integration, deployment, etc. Actually, it does but on a much smaller scale. These tasks are performed for each story, rather than for the entire release. On this smaller scale, each task should usually only take hours or even minutes.

At the beginning of each iteration, the customer must pick the most important stories which are to appear in the current iteration.

Too Much to Do

Very often, problems arise because developers say they “Don’t have enough time”. This is a problem as time cannot be created. Not having enough time to do things causes frustration, mistakes, burn-outs and ultimately failures.

A more sensible way to look at is to say “I have too much to do”. This subtle difference at least allows for three options:

1. prioritise tasks and not do some of the least important ones.
2. reduce the size of some of the things to do.
3. ask someone else to do some of the tasks.

Four Variables

There are 4 factors that can be varied in the project.

1. Cost
2. Quality
3. Scope
4. Time

When ever one of these levers is pulled another one (or two or three) change. All four of them have to be closely monitored at all times.

Unfortunately, varying the levers to find the perfect balance is not as simple as it may first appear as the results are time delayed are non-linear. For example, doubling the cost does not necessarily mean the time will be halved (nine women can’t have a baby in one month).

Cost

Factors that can adjust cost and the consequences:

• Adding people to a project is non-linear as doubling resources does not double speed because of the communications overhead of managing them, and the time required for training.

Brooks’ law : “Adding people to a late project just makes it later”.

• Purchasing tools such as software often leads to loss in productivity due to the learning curve and time needed to get comfortable. Some tools are essential though and these must be very carefully chosen.
• Spending small amounts of money on things like faster computers, bigger monitors, more comfortable chairs, etc, can have an excellent return. These things cost little money in the bigger picture but is key to motivating developers. Many everyday factors like slow machines or constantly having to switch windows to develop/test systems can go unnoticed (by managers and sometimes even by the developer) and lead to internal frustration which in turn leads to silly mistakes.
• Overtime is very uneffective. In the extremely short term it can temporarily speed up the team, but within days developers will become tired and demotivated. Demotivation is a very bad thing and tiredness is even worse. A developers who is not at 100% is worth very little. 7 motivated hours will result in more than 20 unmotivated hours. Most bugs creep into systems late at night when awareness isn’t at it’s most and each one can take hours or days to debug later. Don’t fall into the trap of working overtime, loosing productivity not long afterwards, trying to work more overtime to catch up, and so on…

Quality

There are two types of quality in a system. External quality is that perceived by customers such as ‘making the application faster’, ‘make the interface prettier’ or ‘complete the feature set’. This type of quality falls under the scope variable.

Internal quality is the boring stuff never seen by the customer such as how good the underlying design/architecture/code/test-cases are.

This should always be at 100% and adjusting this is very dangerous. If decreased there will often be a marginal increase in speed as corners are cut, followed by a dramatic decrease in speed. Once the quality drops it is hard to recover and usually involves going back and rewriting the code that was of poor quality anyway.

A careful eye should always be kept on quality to ensure it is always at 100%.

Time and Scope

For most part of planning, the other two variables, cost and quality should be assumed fixed. It is far easier, safer and more productive to adjust time and scope.

Scope is very easy to keep track of - a customer always knows what they want and it’s easy for them to ask for more at any time. However, time is much harder to keep track of as it’s not immediately apparent how much extra time is being added as the scope increases.

Proper planning should reveal how much time is required and how it changes as the scope changes. Because the time taken is unknown until the project is finished, the project is broken down into much smaller iterations which can be finished earlier.

Planning needs to:

• preserve the developers’ confidence that the plan is actually possible.
• preserve the customer’s confidence that they are getting as much as they can.
• cost little because we plan often, but nobody pays for plan - they pay for results.

Yesterday’s Weather

“You’ll do as much tomorrow as you actually got done today.”

It’s the most effective way to predict what will happen next. Luckily all the developers did some work today (even if it was for a different customer) so you already have something to go by (however, if the factors such as technologies being used vary greatly from that being used tomorrow, it is often working performing a small detour - spike solution - to find out how long it may take under the new conditions).

This means:

• we don’t overestimate our abilities, we use actual accomplishments.
• if we overestimate once, we won’t do it again.
• if we are overcommitted, we will finish a few items instead of half finishing all of them - we cannot tell the customer they can have zero features next time.
• people trust the numbers as they are simple to understand.
• estimates track all kinds of changes, such as team members, product direction, technology.