Several people have asked me to republish historic information on Scrum. This was posted on my website in 1995 after Agile Manifesto signatory, Bob Martin, sounded off on project management.
Group: comp.lang.smalltalk
From: rmartin@rcmcon.com Robert Martin
Org: R. C. M. Consulting Inc. 708-918-1004
Date: Fri, 3 Feb 1995 16:05:49 GMT
Subj: Re: OO Project Management
____________________________________________________________
The question has been asked: "How do we use our standard project
management tools to help manage OO projects?" On the surface of
things, this appears to be a significant problem. We have used the
normal suite of tools for managing "waterfall" projects, and it is
difficult to see how they can be used to manage "iterative" projects.
However, the standard suite of project management tools (e.g. PERT and
CPM and Ghant) are not incompatible with iterative development. They
are designed to model the schedules of projects, and iterative
projects still have a schedule.
The difficulty is that the items on the schedule are different. In
waterfall project management, the items on the schedule are
"Analysis", "Design", "Implementation", "Test", etc. However in
iterative development it does not normally make sense to use such
items. What items should we use?
There is a common myth that iterative projects are projects without
schedules. They ramble about, hither and yon, until some techie
decides that they have done enough work and declare the project
complete. This is not the case. An iterative projects has a schedule
just like any other project, and that schedule can be modeled with
standard project managment tools
When an iterative project begins, the application is broken down into
many sub-projects, each with a very small number of features. These
sub projects are sometimes called vertical slices, or just slices.
Each slice represents a small amount of work that needs to be
accomplished. It must be possible to array the slices in time, such
that the features implemented in earlier slices do not depend upon the
features implemented in later slices. Thus the slices can be
implemented in a chronological order.
Once the slices are allocated, each can be estimated as to the
resources that will be required to implement it. Then these slices
can be arrayed on a PERT chart, or any other project managment tool to
produce a complete project estimate. However, this estimate is
extremely unreliable.
When the project begins, the time required to implement the initial
slices is recorded, and fed back into the schedule. Each time a slice
in completed we learn more about how much time the other slices will
take. Thus our schedule becomes more and more accurate as time goes
on. The end date on the schedule will change (probably recede) as
more data on the implementation of the slices is gained.
Fred Brooks once said: "Adding manpower to a late project makes it
later." This is certainly true when 80% of the schedule has been
exhausted and only 40% of the project has been completed. The benefit
to iterative scheduling is that feedback concerning the accuracy of
the schedule comes back very early. After the first few slices,
project managers can begin to measure the error in their initial
estimates and plan for resource changes. Thus they can add manpower
to an early project so that it does not become late. (Or they can
decide to scrap the project altogether).
Note, that the items that are placed into the project management tool
are not "Analysis", "Design", etc. They are the slices themselves.
In projects that are really big, the slices should be broken down into
sub-slices, using exactly the same scheme. The schedule for these
slices should also be broken down into sub-schedules, and the process
repeated in a hierarchical fashion.
English 
French 
Spanish