Commentary On The Benefits Of XP: Project Cancellations
Project Canceled: XP asks the customer to choose the smallest release that makes the most business sense, so there is less to go wrong before going into production and the value of the software is greatest
Response: A factor that XP seems to ignore is the cost of customer involvement from both the customer's perspective and the developer's. The customer may desire small, incremental releases but the cost involved can be substantial. A release is often reviewed by several people. The developer, for his part, must provide sufficient documentation to describe the changes, the new features, and provide training support so that the customer can test out the release. Barring this, a minimalist approach consists of a "dog and pony show", in which the developer presents the release to the customer in a controlled environment in a "meeting" setting, in which the customer is a passive observer. This kind of presentation is often accompanied by PowerPoint diagrams illustrating product features, schedule planning, milestones, budgets, etc. Rarely is the customer left with the product to play with on his/her own.
The customer, regardless of the approach taken, will produce feedback regarding the release. This feedback is often verbal and un-moderated, by which I mean that the feedback:
- may be sporadic
- generated by several people on the customer's side,
- and be received by different people on the developer's side.
On the developer's part, the feedback must be managed:
- It has to be organizing and collated into an understandable and cohesive document;
- Acknowledging to the customer regarding his/her feedback is a good practice;
- Feedback often requires renegotiating with the customer because new/changed features and functionality impact the schedule and cost;
- Conflicting feedback must be resolved (the potential for contradictory or conflicting feedback increases as more people become involved in reviewing the release);
- The developer must continually keep the customer's goals in mind, which the people reviewing the release may not be aware of. Personalities, politics, personal agendas, and poor communication result in developers being more psychologists than programmers
- Finally, the feedback must be approved and incorporated into the design.
Projects which involve computerizing manual processes, or "automating a business", have additional problems to deal with regarding customer feedback. These problems arise when manual processes do not transfer over well to automated processes, resulting in "but this isn't how we do things" feedback. The developer must respond by providing the customer additional understanding of the problem domain, how the automation addresses the requirements of the workflow process but is implemented in a manner that is more efficient from the point of view of a computerized system. Something often forgotten is that computer programs do not just make life easier, they change life.
- 10:01 PM - [Link] - Comments ()
...
Commentary On The Benefits Of XP: Schedule Slips
Schedule slips: XP calls for short release cycles, a few months at most, so the scope of any slip is limited. Within a release, XP uses one- to four-week iterations of customer-requested features for fine-grained feedback about progress. Within an iteration, XP plans with one- to three-day tasks, so the team can solve problems even during an iteration. Finally, XP calls for implementing the highest priority features first, so any features that slip past the release will be of lower value. (Extreme Programming Explained, Chapter 1)
Response:
Projects have beginning and an ending (hopefully!), whether I as a consultant write the proposal, or I and my team, as employees, write the proposal. The schedule in the proposal is based on the input received from the customer (as defined by TQM). If the proposal is accepted, among other things, the customer will plan activities based on the anticipated completion date. In certain industries (such as the gaming industry) this is a very critical date and slipping on the completion date can kill a product.
Releasing a product in short release cycles by its very nature reduces the perceived schedule slip, however this schedule slip continues to aggregate for each release and the end result is the same--the product slips its schedule, whether it was done in one big release or many little ones. The only way to modify a project that is incurring schedule slip is:
- reduce the feature set
- work more efficiently
- work harder (overtime)
- make it up somewhere else
- add more people
- negotiate an extension
From the perspective of the customer, none of these are viable solutions except "work more efficiently". All the other options incur costs and penalties that, while difficult to quantify, reduce the profit potential of the product. The "make it up somewhere else" option does not necessarily involve additional costs but carries risk--the areas where the "make up" is anticipated to occur may not be realized.
XP's technique of pushing features that slip past the release date to a lower priority eventually results in a bottleneck of low priority items. As development proceeds, some of these items will enter the critical path to complete higher priority items which will result in a cascade effect of further schedule slips. This will manifest itself in the Iteration Planning Meeting, as low priority items enter the critical path of high priority stories and tasks.
- 3:29 PM - [Link] - Comments ()
...
