The planning session is an opportunity for the executive sponsor, ambassador user and developers to contribute together to build the project map and timeline.
The following describes a variation of "planning game" from XP that I like to use. I call it Blitz Planning to emphasize that it goes fast. However, I also like to refer to it on occasion as a Project Planning "Jam Session" to emphasize that everyone is supposed to play together and off each other in a collaborative way, as in a jazz jam session. If you lose the amicable collaboration, you can do the technique, but you lose many opportunities to creatively improve the project plan.
I find this technique works well for a planning horizon up to about three months. After that, the amount of detail is overwhelming. For time horizons longer than three months, I use the Project Map described among the work products.
I subtitle this technique a project planning "jam session" because the technique allows the different project stakeholders to gather together and share ideas on how to make the optimal plan. Traditionally, the plan is made by the project manager or team lead without buy-in from the other stakeholders. That leads to two dysfunctions: First, the plan is of course wrong, since the poor person assigned to construct it can't possibly know all the tasks and times; second, when the errors in the project plan become evident, people find it easy to point accusing fingers at the person who made the plan.
To counter these dysfunctions, make sure the Executive Sponsor, one or two key users, any business analysts, and the entire development team, including anyone involved in testing and deployment, are in the room. This group will name the talks more completely, the time estimates will be more reasonable, and just as importantly, everyone will see all the trades-offs made in constructing the plan. Everyone is jointly responsible for the result, and they all know it. As one person said, "We all made it, we all discussed the optimizations made."
Everyone grabs cards and writes tasks on them as fast as they can. Usually the developers do most of the writing, but the executive sponsor and ambassador user often have a few tasks to contribute.
List every task that will take half a day to several weeks, including interviewing users, programming specific functions, writing user help text, migrating databases, and installing the system (I often group tiny tasks together). The idea is to be complete. This step may last 5, 10, or 15 minutes.
Everyone lays the cards out on the table in dependency order, the first ones at the head of the table, with successive tasks down the table. Tasks that can run in parallel are placed side by side across the table; tasks that run sequentially are placed above and below each other; duplicate task cards are removed.
It usually requires a big table. I have used a large conference table and also several six-foot cafeteria tables laid end to end.
Everyone walks up and down the table, looking for tasks that didn't get captured in the brainstorming. One person's card often triggers a thought in another person. Add cards as needed.
Whoever is going to do each task writes down their estimate for how long it will take (I write this on the lower left corner). If multiple people come up with different estimates, they have a brief discussion and put down their best second estimate. They also write down the names of any specific people required for any particular task (I write this on the top of the card).
It often happens that the team lead's name is on a disproportionate number of cards. Seeing that person's name on so many cards should lead the team into a discussion of how to off-load that person or otherwise reduce the dependency on him. If a task is dependent on an external event or task , mark that on the card (I write this on the center of the right side of the card.)
In this step, the people work to identify more closely the presence or absence of dependencies, and to question the placement of cards on the table.
Tasks that are placed sequentially often can be started in parallel. Identifying possible parallelism loosens the constraints on the plan. Also, it often turns out that there are parallel streams of activity, one for the Ambassador User, one for the developers, or perhaps three separate streams for infrastructure, functionality and user interface development.
These parallel streams start to look like separate tracks of cards running down the table, occasionally coming together.
Certain cards have a strictly sequential relationship, such that the second simply cannot be started before the first has finished (example: "Evaluate vendors" must fully precede "Set up contract with vendor"). Mark these pairs in some special way so that information doesn't get lost when the cards get moved around (I put the same capital letter, A, B, C, at an adjoining edge of the card, the bottom edge of the first card and the corresponding point on the top edge of the second card). These strict dependencies are surprisingly rare; I rarely get beyond the letter E.
Finding the first and smallest collection of functionality that can conceivably be of use to some users is critical. It is critical because that release represents the first time the users will see the system, their first idea of the look, feel, and shape of the system. Setting that point as early as possibly gives the entire organization the most time to adapt to any new ideas or mismatches that show up from the initial release. On some occasions, this first release represents the earliest moment at which revenue can be gained; in this situation, the group should focus on getting all other cards out of its way. All in all, three events of interest are located: the Walking Skeleton, the earliest usable release, and the point of earliest revenue.
I mark these points by putting a bit of distance between the cards above and below those points. I have also used string, yardsticks, pencils - anything to demark those points.
It requires cooperation between the Ambassador User, Executive Sponsor, and Lead Designer to discover and optimally set these points, because some tasks will have to be moved up and others deferred. Whoever is moving the tasks around needs to be aware of the consequences of these moves, and that means each stakeholder group has to be present, alert and cooperative.
A word is in order about the tasks that precede the initial release:
Some of the early tasks are likely to be strictly technical, such as ordering software, setting up a contract, or loading a database. It is useful to have those tasks visible to the Executive Sponsor and Ambassador User, because they need to explain the state of the project to other people. The technical task cards show what work needs to be done before business software will become visible.
Historically in our business, the user group gets told only, "The programming team says they have a bunch of technical work to do first." This often translates to months going by without deliveries or even visible progress. By making the tasks visible and public, the Executive Sponsor or Ambassador User can report, "They have five technical things to do before we can see some software," "They still have two technical things to do before we can see some software," "They're on the last technical thing, and then they'll show us some running software."
This sort of visibility goes a long way to reducing the tensions between the groups.
The group works out where other natural release points happen. Quite often, there is a particular cluster of function that really should be bundled together for the users to make good use of the system. At some point, the functions to be included simply become a long list, and at that point it may be more valuable to base the releases on regular time periods (monthly, bi-monthly or quarterly), rather than on collections of functionality.
Neither Crystal Clear nor the Blitz Planning technique mandate what algorithm you use for choosing iteration lengths and release periods.
Mark the key releases using a space between the cards, string, yardsticks, or whatever.
At this point, you have a plan. Typical the plan is not yet a good plan. It is my experience that when the numbers on the cards are added up, the team is in for "sticker shock" (this is the shock a car buyer experiences when stepping around to read the sticker posted on the car window announcing the price after all the car's options are added together).
The entire group, and particularly the Executive Sponsor, Ambassador User and Lead Designer now have some creative problem solving to do to come up with an acceptable plan. What they shift depends on the priorities set for the project: time-to-market, cost, or feature set. This is where they really start "jamming." Typically, following the sticker shock, one of three things happen:
Pressuring the developers to change their estimates is not advisable. That not only makes a lie of the plan, but it convinces the developers that the Executive Sponsor is not being realistic, open and honest.
In the worst possible case, the Executive Sponsor has the right to say, "OK, I see the tasks and the time estimates. However, I can't change the deadline, and I can't see anything else to remove, reorder or outsource. I'm going to multiply all estimates by 80% so that we can meet our target date. In the meantime, let's all keep our eyes open for new alternatives so we can reestablish these original estimates" (see the discussion on Crystal Clear and "Reallocation of Power," page Error! Bookmark not defined.)
This is a drastic measure and should not be used lightly. The point of doing it is to make public both how the priorities affect the schedule, and the fact that the team's estimates are being overridden. Everyone has seen the cards and the original estimates. The team should track both plans, report against both in their status charts, and keep visibility of progress high.
Take it seriously if you have to resort to this measure even twice. That indicates there is another problem in the organization needing to be sorted out, having to do with the viability of the organization's business model, the trust between developers and sponsors, or the historic accuracy of the development team's estimates. Straightening those out will be crucial to the ongoing viability of the development team.
When optimizing the card layout on the table, the people look for three improvements in particular.
I saw a card near the very end of the table labeled "Load Testing." Not thinking too much about it, I asked the Lead Designer: "How long will it take to perform?" He answered, "A few days." Still not worrying, I asked, "And suppose it fails, how long is it likely to take to revise the architecture?" He answered, "Oh, three or four weeks." At this point the Ambassador User started looking alarmed. I asked, "Would it be possible to do it earlier?" "Sure," he answered. We looked for the earliest moment at which he could do it without damaging the other critical business items on the table. I tentatively placed it just after the initial release. "Could you do it already here? (and then you'd have lots of time to revise the architecture if it fails)" I noticed the Ambassador User vehemently nodding her head on the other side of the table, and noticed her large sigh of relief when he said, "Sure."
You have a plan, but it is only cards on a table. You need to preserve the information.
You can photograph the table, tape the cards together and mount the on the wall as an information radiator, or type them into another tool of your choice.
I like to number the cards so that their placement on the table can be reconstructed. I number them 1, 2, 3, and so on down the table for the sequential relationships, 3a, 3b, 3c and so on across any particular parallel set (and on occasion 3a1, 3a2, 3a3 and so on if there are nested subsequences).