By: W. Cunningham
Published in: PLoPD2
Category: Organization and Process
Summary: Organization and process for software development in small teams that describes mental states or episodes.
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
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
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
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
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
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
Ask developers to estimate by analogy to comparable tasks. A task half as complex as some previous task will probably take half the time.
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
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.
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.
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.
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.
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.
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.
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.
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.