Scrum Log Jeff Sutherland

Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto.

Wednesday, April 21, 2004

Working Together In "War Rooms" Doubles Teams' Productivity, University Of Michigan Researchers Find


PHILADELPHIA---Teams of workers that labored together for several months in specially designed "war rooms" were twice as productive as their counterparts working in traditional office arrangements, a study by University of Michigan researchers has found. Results of the study will be presented Dec. 6 at the Association for Computing Machinery 2000 Conference on Computer Supported Cooperative Work.

Recently, many companies in the software industry have been experimenting with putting teams of workers into "war rooms" to enhance communication and promote intense collaboration, explains Stephanie Teasley, an assistant research scientist in the U-M School of Information's Collaboratory for Research on Electronic Work.

Instead of toiling in separate cubicles, workers sit at wall-less workstations in one big, open room. The room is typically outfitted with central worktables, whiteboards and flip charts to facilitate group discussions. While companies expect benefits from such arrangements, workers sometimes balk at the idea, fearing they'll sacrifice privacy and the quiet they need to concentrate on demanding tasks. The U-M researchers say their study is the first to closely examine the effects of what they call "radical collocation" on both productivity and worker satisfaction.

Teasley collaborated on the project with Mayuram Krishnan and Judith Olson of U-M and Lisa Covi, who was at U-M when the work was done but now is at Rutgers University. The group studied six software development teams at a major automobile company, all of which had little or no experience working in war room settings. The researchers evaluated the workers' productivity using measures commonly used in software development; then they compared the war room teams' scores with productivity data the company had collected on software development teams working in traditionally arranged offices. The researchers also interviewed the workers and had them fill out questionnaires at the beginning and end of the project. In addition, they made detailed observations of two teams---sitting in on meetings and conference calls, watching the teams solve various kinds of problems and photographing them in action.

Teams in the war room environments were more than twice as productive as similar teams at the same company working in traditional office settings. In a follow-up study of 11 more war room teams, productivity nearly doubled again, making the war room teams almost four times as productive as their counterparts in ordinary offices. The setting alone may not account for all of the productivity differences; teams working in the war rooms also used techniques designed to accelerate software development. However, those techniques could only be carried out by radically collocated teams, says Teasley.

Agile Alliance: New User Groups


There are user groups springing up around the Agile Alliance focused on improving development processes. Groups are international in scope. I recently reported on the Calgary: Calgary Agile Methods User Group (CAMUG)

The Thames Valley Agile Special Interest Group (TVASIG) is a new user group promoting and sponsoring the adoption of Agile Software Development methods throughout the Thames Valley area in the U.K. Their aim is to provide members with useful information and help advance their understanding of Agile Methods.

The first TVASIG meeting will be held at the "NEXT DOOR" pub in Oxford on the 27th April @ 20:00. It is hoped that this will be an opportunity for everyone to get to know one another in an informal setting, explain objectives of the TVASIG and agree a future direction for the group.

Agile enthusiasts should also take a look at Uncle Bob's new book (as Robert Martin is referred to by Agile Manifesto signatories). He has an excellent overview of agile principles in the first chapter. I'm reading it now and will report more on it when finished.

Martin, Robert C. (2003) Agile Software Development: Principles, Patterns, and Practices. Prentice Hall.

Thursday, April 15, 2004

Voices From the Past: Uncle Bob on Project Management

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.