This chapter is from the book
This chapter is from the book
This chapter is from the book
Crisis Days
All right, you may say, so far so good. But what happens when the other shoe drops and the manager's nightmare comes true, and the day you thought was typical becomes anything but? Well, let's revisit our hard-working teams and look how each handles a project crisis.
One Friday, unexpectedly, the customer informs the team that there has been a major change in the requirements—the new CEO has requested an unprecedented, complex report to be generated. On inspection, it is discovered that changes will have to be made to the data input GUI, the database, two computational modules, the output GUI, and the hardcopy report generator. To make matters worse, the report is needed for a board of directors meeting the next Wednesday.
A Crisis Day with PSP/TSP
The customer informs the team of the requirements change and its priority and schedule. She expresses her confidence that the team's track record indicates the change is workable and promises to help expedite any needs they have.
This type of change is anticipated in the architecture, but considerable changes are required in the specs and plans. Assignments are made to estimate the team's ability to complete the change in the requested time.
The team is scheduled to reassemble at 1:00 to decide on its response and to take whatever actions are required.
The team meets and reviews the estimates. Based on current productivity numbers, the team agrees it can meet the deadline, but that there will be considerable impact to the schedule for the next planned release. The replanning effort is completed, the customer informed of the results, and the customer agrees to postpone the next release by the specified time period. Assignments are made and the design tasks begin.
The team reconvenes to address issues raised in the redesign. The architecture has proven robust and the design work has gone smoothly, aided by automated planning and the use of the Unified Modeling Language (UML) and CM tools, as well as the team's experience with the processes. While there are some grumbles about the hassle of changing the schedule and refocusing their tasks, the prospective satisfaction of fulfilling a CEO-level request and the schedule readjustment leave them enthusiastic. Although their documentation is relatively lightweight, a good deal of rework remains in the plans, earned value system, and test plans and procedures, but some team members with free time on the weekend volunteer to come in and work these. Panitee schedules an inspection meeting Monday afternoon to review the completeness and consistency of the changes.
The PSP/TSP team could have had significantly more problems had they had:
-
A less collaborative and authorized customer.
-
An inexperienced manager.
-
Weaker tool support.
-
A larger change that would have required more cost and schedule adjustment.
A Crisis Day with XP
The customer informs the team of the requirements change and its priority and schedule at the standup meeting. The team works out its replanning strategy together. Members identify the main contributors to affected modules to write and estimate the tasks.
The team reconvenes to discuss the results of the task estimation work. Considerable refactoring may be required for the database and report writer modules, but the remainder of the changes look straightforward. The team agrees that they can make the date, but that the time spent will require renegotiating the story content of the current release. The customer works as part of the team to evaluate the options and agrees to push two of the lower-priority stories to the next iteration.
Pair work begins on writing module tests for the new features. Melissa and Ferdinand sketch out the acceptance test.
Most of the pairs have finished their initial work. As they make changes to existing software, they use the results from the automated testing suite to identify any errors caused by those changes that have propagated to other parts of the system. The team responsible for the database refactoring realizes that it is proving harder than expected and asks for help. Jill responds and looks at their progress. She sees a way to reuse a pattern from a previous database development she has worked and the refactoring continues more productively. Some problems crop up, though, in undoing the partially completed now-deferred stories and reachieving a simple design.
The team gathers to take stock. The change has re-energized the team, and Patricia indicates the velocity numbers are significantly higher than they have been for several weeks. It is agreed that they will be able to finish the work within schedule even with the need to rebaseline the design and code. With virtually no paperwork to clean up, the team takes off for the weekend.
The XP team could have had significantly more problems had they had:
-
A non-CRACK customer
-
A less experienced coach
-
A main contributor to one of the affected modules out of the office
-
A nonexistent or incomplete set of automated tests
-
A larger change that required more impact on the increment contents than the customer could accept within the fixed increment length