Agile Project Management vs. Traditional Project Management

Agile Project Management (APM) is a process that employs short iterative cycles, actively involve users to establish, prioritize, and verify requirements, and rely on a team’s tacit knowledge as opposed to documentation. An agile method must be iterative (take several cycles to complete), incremental (not deliver the entire product at once), self-organizing (teams determine the best way to handle work), and emergent (processes, principles, and work structures are recognized during the project rather than predetermined).

Traditional project management assumes that projects are predictable and tools and techniques are well understood. In addition, with traditional project management, once a phase is complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays out the steps for development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow, and clients usually find it difficult to communication all requirements early in the project.

Unlike traditional project management, that emerged from the construction, engineering and defense industries and dates back to the 1950s, APM was born in the twenty first century. In 2001, prominent software developers from both IT and software engineering domains, convened to arrived at a consensus on how the software development industry could produce better results.

APM is conducted collaboratively, with a small co-located team. This core team usually consists of two developers who write code in pairs (for quality control), the customer/end-user, IT architect, a business analyst and a project manager. The work is accomplished through a series of sessions where the team writes code, then tests working modules of the system and repeats the process. There is minimal documentation as the team relies almost exclusively on informal internal communication.


Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time.

The concept of predictability flowed into the Waterfall concept; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt.

An Agile approach to problem solving is different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end."