Your browser does not support JavaScript!
  • LinkedIn
  • YouTube
  • RSS

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.

en_USEnglish
Shares