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:
- The Executive Sponsor reconsiders the business need for the project (in one case, the executive team decided simply to buy a commercial package instead);
- The team removes tasks from the project;
- They shrug their shoulders and simply move forward.
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.
- They spot that a particular cluster of cards almost creates a coherent release having business value. By moving a card up higher, they can get that coherent business value much earlier. In one case, I heard the Ambassador User say, "If we only had this card up here, we could start charging revenue with this release." You can guess that we immediately moved that card up, and then moved down all cards not strictly needed to produce that release!
- They spot a risk from having a card late in the project. This is typically done by someone with technical background playing the challenger.
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."
- They spot that one particular person has too many cards allocated to him or her. That person is going to be overloaded and will probably get into trouble. They brainstorm how to assign those tasks, or the bulk of some of them, to other people to reduce the risk to the project and the strain on that person.