Traditional

Agile

Open source

Documentation

Documentation is emphasized as a means of

quality control and as a management tool.

Documentation is deemphasized.

All development artifacts are globally available, including code and information documentation.

Requirements

Business analysts translate users’ needs into software requirements.

Users are part of the team.

The developers typically are the users.

Staffing model

Developers are assigned to a single project.

Developers are assigned to a single project.

Developers typically work on multiple projects at different levels of involvement.

Peer review

Peer review is widely accepted but rarely practiced.

Pair programming institutionalizes some peer review.

Peer review is a necessity and is practiced almost universally.

Release schedules

Large number of requirements bundled into fewer, infrequent releases.

Release early, release often.

Hierarchy of release types:

“nightly,” “development,” and “stable.”

Management

Teams are managed from above.

Teams are self-organized.

Individual contributors set their own paths.

Testing

Testing is handled by QA staff, following development activities.

Testing is part of development.

Testing and QA can be performed by all developers.

Distribution of work

Different parts of the codebase are assigned to different people.

Anyone can modify any part of the codebase.

Anyone can modify any part of the codebase, but only committers can make changes official.