By: P. Taylor
Published in: PLoPD4
Category: Organization and Process
Summary: How the ability to produce and evolve software can be created and maintained.
For managers of teams using iterative development.
You see a lot of activity but little progress on deliverables. You must translate the activity to an assessment of the team's progress and its capacity to produce. Use Bootstrapping, Pulse, and Round Pegs for Round Holes
Most team members are unfamiliar with the problem domain, the application, and each other. Partition some responsibilities and share others. Use Round Pegs for Round Holes to identify those team members with capabilities and experience. Then use Problem-Oriented Team
You've used Bootstrapping. Use the team's need to understand the problem to build team cohesion. If the problem space is highly complex and cannot be mastered by all team members quickly, choose a critical but manageable part.
You've used Bootstrapping. Now you must assign tasks to people. Individual capabilities and preferred work modes must be observed over time. Discover each individual's preferences for working, and allocate tasks accordingly.
A software development team is capable of bursts of higher productivity to meet production demands, but you must handle the timing, length, and frequency of these peaks with care. Determine the team's delivery rhythm by putting the team through periods of higher-pressure release cycles. You'll establish a project rhythm of peaks and troughs aligned with project plans and deliverables.
You must scope and time the team's deliverables so that they will be used. Don't release until users are ready to consume.
If productivity is to be maintained over time, a holistic, healthy work environment must recognize the natural rhythm of human work. Productivity peaks interleave with nonproductive periods during an average day. Create a physical space for casual, unplanned interactions between team members.
A critical team member is leaving. The departing developer should handover to a continuing developer, setting the replacement free to do new work. If the continuing developer is now overloaded, using the departure as an opportunity to shuffle and reallocate everyone's tasks and responsibilities.
Your established team is entering a transition period where members are replaced by newcomers who must quickly come to grips with large and complex software modules. People are territorial and need to mark their intellectual territory to establish a feeling of ownership. Newcomers should move in by cosmetically arranging code. This must be a background, incremental task and should not be used as an excuse to trash the backyard.