By: A. Cockburn
Published in: Addison-Wesley, 1998
Category: Organization and Process
Summary: Strategies for managing, staffing, and building a development organization.
Url: http://members.aol.com/acockburn/riskcata/riskbook.htm
Pages: 206-207
You don't know the issues well enough to put together a sound plan, so deliver something. This will tell you the real issues.
Pages: 208-209
You don't know what problems you will encounter during development, so deliver something early. Discover what you don't know you don't know. Deliver regularly and improve each time.
Pages: 210-211
You don't know how some design decision will work out, so build an isolated solution and discover how it really works.
Pages: 212-213
You have to create a plan but have never done this sort of project, so run an 8- to 12-week instrumented pilot to get productivity and throughput data for your plan.
Pages: 214-216
Development of a subsystem requires many skills, but people specialize, so create a team from multiple specialties.
Pages: 218-219
You don't have time to wait for requirements to settle, so start design and programming immediately. Adjust requirements weekly.
Pages: 220-221
Be sure every deliverable has one and only one owner.
Pages: 222-223
If you organize teams by components, functions suffer and vice versa, so be sure every function and every component has an owner.
Pages: 224-225
Distractions constantly interrupt your team's progress, so be sure that someone keeps moving toward the primary goal, no matter what happens.
Pages: 226-228
A major diversion hits your team, so let a subteam handle the diversion and keep the main team going.
Pages: 230-231
A minor diversion hits the team, so assign one person to handle it.
Pages: 232-235
Experts are spending all their time mentoring novices, so put one expert in charge of all the novices. The rest of the team keeps going.