Extreme programming takes a new approach to planning software development. My main observation about XP planning is how incredibly transparent the process is for the client. Clients participate in the initial release planning at the inception of the project, where a general idea of the shape of the project is established. Throughout the project, they plan along side of the developers during iteration planning meetings, where a more detailed plan for that iteration period is developed.

This method of planning aims at accomplishing two goals: predicting what will be accomplished by the next iteration, and deciding what to do next. If you read my post two days ago, this more compartmentalized approach to planning helps to solve some of the complexity of decision making that I was referring to with regards to project management.

An interesting feature of this type of planning is that very little is concrete beyond what would be accomplished in, say, a two week planned iteration. This also draws back to the previous post where it emphasizes how software projects are notoriously difficult to plan due to changing requirements, varied skill levels, and unpredictability of decision consequences, among other things. It is incredibly difficult to predict with precision how long something will take, so the idea with XP planning is that the project is guided in a particular direction, but not forced along a path.

During the initial planning, referred to as release planning, the client will present their desired features to the programmers, who will try to decide how difficult each will be. More difficult tasks will carry a higher cost, and with that in mind, the clients will prioritize the features in order to lay out a general plan. I say general because neither the client nor the programmers are able to predict with accuracy how the project will progress. The idea of this meeting is to set the stage with the overall requirements to get a rough idea of what the project will entail.

Iteration planning meetings, on the other hand, will discuss what can be delivered within more concrete terms. Because iterations are usually only one to three weeks, they are much easier to manage and predict. Features discussed during a previous meeting will be broken down into tasks and split up among team members. The team members will work, generally in pairs, to accomplish each task. Usually in the middle of the iteration, the team will gather to see that 50% of the iteration tasks and features have been met, and if not, they regroup and reorganize to try to get those tasks and features completed by the agreed upon next iteration meeting. These meetings become easier to plan as the project settles in because neither the client nor the team knows how quickly the team will work at the beginning of the project with the given requirements.

I see how my current situation in my apprenticeship is taking a similar approach. My iterations are over a one week period. At the end of that period, I have a planning meeting with my mentors. We discuss the goals that were set at the last meeting and go over the requirements for the next iteration. I am encouraged to keep in contact with my mentors (as the clients), during the week if I think that there will be something that I fail to accomplish by the IPM.

The obvious benefit of taking this approach is that it manages uncertainty. While tasks during an iteration are set, the short period of the iteration means that pivots can be made if something is not working out, or even that the project can be cancelled without a great deal of loss. Short periods between evaluation means that the client maintains greater control of the project, but also that there will be less pressure and stress for the programmers needing to only worry about the immediate and reasonable goals that they help to set for themselves.