Extreme Programming Installed, Chapters 19 - 21
by Ron Jeffries, Ann Anderson, and Chet Hendrickson

Chapters 19 - 21 of Extreme Programming Installed is about steering a project and making changes to schedules and estimates along the lifecycle of the software. Whenever you make estimates at the beginning of planning, it's not always easy to be completely accurate because you just don't know how much time is required until you start coding. When steering your Extreme Programming project, you need to focus on projected estimates versus actual coding time, changing priorities in the code, and roadblocks that keep a programmer from completing their tasks.

According to the authors, it's important to keep tabs on and track the project so you can steer the project to success. First of all, the most important thing is to get user stories done. Instead of almost completing all of the tasks, it's better to finish as many of you can and either postpone or throw out the tasks that aren't as important. You should also take the time as you're programming to improve your estimates. If a task that you estimated at 2 weeks ends up taking 3 weeks, you can use that knowledge to help when you're estimating future similar tasks. To keep track of these estimates and progress within the team, it's useful to have a team member who's job is to "track" the rest of the team. They are responsible for checking in with each team member on the status of their tasks, and be there to make decisions if there is a problem with development. For example, if a team member is struggling with a problem in their code, the tracker can make a decision about whether to assign the task to another person or change priorities.

And lastly, it's important to continually steer the project towards release. Keep track of how much work is getting done each iteration; if you can only finish 32 points in an iteration, don't plan to continue with the 40 points scheduled for the next iteration. Instead, you need to take out some user stories and adjust the task so it's on track for a successful release. And you always make sure that you choose the most valuable user stories to complete - in this way, you always have a successful project that could be released and be useful at any point in the stage.

I definitely agree with this process for updating your tasks and schedule along the way. It's not possible to always plan and design everything before you start doing the programming; it's so much easier to start programming and get a better understanding of the project and possible implementation avenues and then adjust your estimates. Being flexible makes it really easy to adjust and make sure your project is successful. And I definitely agree that when a programmer gets stuck on something that other people should step in. A lot of the time, you just need another set of eyes there that might be able to look at the problem from another perspective.