EPISODES: A Pattern Language of Competitive Development


By: W. Cunningham
Published in: PLoPD2
Pages: 371-388
Category: Organization and Process

Summary: Organization and process for software development in small teams that describes mental states or episodes.

Url: http://c2.com/ppr/episodes.html

Pattern: Product Initiative

Pages: 374-375

When a wish list of features and functions is created for a product, clearly define an initiative for product improvement and be sure everyone understands the initiative. When this pattern has been followed, use Market Walk-through

Pattern: Market Walk-through

Pages: 375

When Product Initiative has been followed, hold a walkthrough of program and product concepts with both the development and business sides of an organization. When this pattern has been followed, use Implied Requirements

Pattern: Implied Requirements

Pages: 375-376

When Market Walk-through has been followed, it's time to name functionality. Use names that have meaning for customers and that are consistent with the product initiative. When this pattern has been followed, use Work Queue

Pattern: Work Queue

Pages: 377

Use the implied requirements to create a schedule. Order the requirements by priority. When work can be factored from two or more items, give the common element a name that establishes its position on the list. Be prepared to reorder the list as new priorities arise. When this pattern has been followed, use Work Group

Pattern: Work Group

Pages: 377-378

When you've completed a work queue that (a) describes product initiative-relevant work, (b) is ordered by priority, and (c) shifts up as completed work is removed from the top, then allocate roughly two month's work from the top of the work queue. Be sure the team assigned to this work is committed to work together to complete their assignment. When this pattern has been followed, use Work Queue Report

Pattern: Work Queue Report

Pages: 378

It's difficult to detect schedule slips in a weekly status meeting. Collect status reports from weekly personal interviews. Request estimates of days of remaining effort (in terms of uninterrupted days) using comparisons with related previous work. Use these estimates along with individual dilution factors (usual number of uninterrupted days per week) to predict days to completion for each deliverable. When this pattern has been followed, use Completion Headroom

Pattern: Comparable Work

Pages: 379-380

Ask developers to estimate by analogy to comparable tasks. A task half as complex as some previous task will probably take half the time.

Pattern: Completion Headroom

Pages: 380

Estimate completion dates using the remaining effort estimates in the work queue report. Calculate each contributor's earliest possible completion date, find the latest of these, and compare that to the hard delivery date for the project. The difference is the completion headroom. The headroom may fluctuate, but steady evaporation of headroom requires management to reorder the work queue, possibly deferring items to a later release date, creating a work split that removes poorly understood or difficult pieces, or holding a Recommitment Meeting

Pattern: Development Episode

Pages: 380-381

Don't emphasize an individual's special skills. Treat all development as a group activity. This will produce better design decisions and will have a positive effect on the participants. Expertise is shared and everyone in the group learns.

Pattern: Informal Labor Plan

Pages: 381-382

Allow individuals to create their own short-term work plans. Realize that most of the group activity in a development episode will take place in pairs that find the time to work together. Don't call a meeting to schedule a development episode. Let individuals make their own plans.

Pattern: Work Split

Pages: 382

Divide each task into urgent and deferred pieces. (No more than half should be urgent.) Defer more work if necessary to have sufficient headroom. Defer analysis and design for parts that won't be implemented. Both halves of the split should appear in the work queue with different priorities.

Pattern: Recommitment Meeting

Pages: 382-383

When a product initiative is in jeopardy because implied requirements cannot be met, even with schedule and work queue adjustments, schedule a meeting with all management and key developers. Show that simple adjustments will not help. Eventually a solution will appear, usually as the question: "What is the least amount of work required to do X?" Give an answer based on a recent work queue report. This may be repeated for Y and Z. Ultimately a plan will be developed.

Pattern: Requirement Walk-through

Pages: 383-384

When any member of the work group begins to consider any part of an implied requirement, assemble the entire group. This is a good time to sketch the first informal work plan for that requirement, and it can lead to staffing changes.

Pattern: Technical Memo

Pages: 384

Develop a series of well-formatted technical memoranda. Focus each memo on a single subject. Keep it short. Carefully selected, well-written memos can substitute for comprehensive design documentation.

Pattern: Reference Data

Pages: 384

A requirement walk-through will identify relevant information sources, which will be retrieved, reviewed, and absorbed as the development episode begins. Collect these information sources as machine-readable examples. Annotate documents so the sources of information will not be lost.

Pattern: Programming Episode

Pages: 385

Programming should be done in discrete episodes. Select appropriate deliverables for an episode and commit sufficient resources to deliver them. Push for the decisions that can be made. Code the decisions and review the code.