These are methods that produce increments of the goal and/or product in a series of distinct cycles each one of which is a complete project life cycle. By proceeding incrementally one's learning also proceeds incrementally. In a classic monolithic lifecycle method such as Waterfall one may not get the necessary learning for effective planning until the end of the project. Incremental and iterative methods help teams learn faster and feed that learning back into the planning process sooner.
Where information about the future is in short supply or the requirements are constantly changing we need to use a project strategy that takes that into account. Trying to plan a project beyond the effective knowledge time horizon is often a waste of time. This is why adaptive project methods were developed.
Philosophy
There are a number of philosophical issues that run at the heart of project management. The main philosophical areas are around the limits of our knowledge and how best we can apply the information that we actually have to achieve desired outcomes in a future world. I list key manifestations of these issues below.
- PMI: The Project Management Institute
Many people are under the impression that the PMI is only about Waterfall. This is not true. In fact, the PMI does not advocate Waterfall or any particular project method. In the language of PMI, incremental and iterative development is known as "Rolling Wave Planning". There are several issues that obscure this for most people. PMI focuses on process rather than problem solving. It uses terminology closer to the quality language of predictive manufacturing than the world of new product development. PMI materials (such as the PMBOK) focus more on the role of the project manager. Modern incremental and iterative methods focus more on the team. PMI focuses on the measurement of activities. Modern incremental and iterative methods focus on the delivery of increments of product. - The Agile World
A very clear statement of the philosophy behind incremental and iterative methods is in the The Agile Manifesto:
i. "Individuals and interactions over process and tools
ii. Working product over comprehensive documentation
iii. Customer collaboration over contract negotiation
iv. Responding to change over following a plan
v. That is, while there is value in the items on the right, we value the items on the left more." (See reference 5 below) - Rob's philosophy
Solving problems is more important than process excellence in new product development.
Choose the right method for the right problem. There is no one method that solves every problem. The project management culture of a company can have a profound effect on the selection of methods. Sometimes this leads to a good conclusion and at other times leads to the selection of methods incompatible with project success. This is why some companies create "skunk works" and "spin-outs".
There are a number of attributes that characterize agile methods. At a very high level all project management methods live on a spectrum that ranges from predictable to adaptable. The placement on this spectrum depends on one's knowledge about the future. The deeper into the future one can confidently predict the longer is one's effective planning time horizon. The agile methods live in the region where one can only make confident predictions on the order of 2-6 weeks. Keep in mind that if there is an element of the project for which you can make accurate predictions about the future it might be worthwhile to keep the planning of that element on a longer time horizon than the less certain elements (especially if they do not have strong dependencies). For example, there are many uncertainties around requirements and performance for software. However, the development of a datacenter not only has greater lead times but many elements of a data center are far more certain from a planning perspective than the requirements of the software that will run in that datacenter. In the extreme case, we can use waterfall when we have highly certain information about the future for the entire length of development. We must use iterative methods, as our effective planning time horizon gets shorter. For example, a very popular agile method in use today (Scrum) has a 30-day planning horizon.
- Time boxing for activities: The "triple constraint" is the PMI paradigm. This comprises time, cost/resources, and requirements/quality. However, to reduce planning complexity the time is fixed in most agile methods. This means that the length of an iteration is fixed. For example, in the Scrum method the length of an iteration is 30 days.
- Customized Project Artifacts: All agile methods have a legion of artifacts from which to choose. A key aspect of agile methods is that the team chooses which artifacts are important and useful for their project.
- Amount of Process Ceremony: Whereas some methods have a great deal of process ceremony others have very little.
- Short meetings: The team meets often (at least daily) and most methods strongly recommend co-location of the team, customers, and product owner.
- Daily measurement
- The Project Manager is hands-on
The popular methods and their key attributes.
- Scrum:
Iteration Length: 30 days; Ceremony level: low; Most popular method - XP (Extreme Programming):
Iteration Length: 1 - 3 week; Ceremony level: low; Designed and used for software projects - Evo (Evolutionary):
Iteration Length: 1-2 weeks; Ceremony level: medium; One of the first incremental & iterative methods - UP or RUP (Rational Unified Process):
Iteration Length: 2-6 weeks; Ceremony level: flexible (from low to high depending on how customized); Compatible with software made by Rational (RUP).
Since Scrum is the most popular of these methods I present below a very high level view of the Scrum process, roles, and typical artifacts.
Roles
There are three roles directly involved in a Scrum project. They are:
- Product Owner: Gets the initial and ongoing funding, develops the initial requirements, and makes sure they are prioritized throughout the project.
- Team: Develops the functionality.
- Scrum Master: Teaches and coaches everyone involved in the project the Scrum process.
A Scrum project can actually have many Scrum teams. The flow below is for a simple project with a single Scrum team (click on the image below for a larger diagram).

The process steps:
- Sprint Planning Meeting: Updates and prioritizes the product backlog (the requirements) and develops a plan (the Sprint Backlog) for the next Sprint.
- Sprint: Sprints are the 30-day time-boxed windows during which the project work is done. Each day during the Sprint a short daily Scrum meeting is held.
- Sprint Review Meeting: Demonstrate the increment of functionality that was developed during the Sprint and get feedback from stakeholders.
- Sprint Retrospective: This is a review of the methods and artifacts. In essence, it is about finding ways to improve the process for the next iteration based on what the team learned during the previous iteration.
- Product Backlog: List of prioritized requirements
- Sprint Backlog: The list of activities for the current sprint
- Burn Down Chart: Shows the amount of work remaining
- Agile & Iterative Development: A Manager's Guide by Craig Larman
- Agile Project Management With Scrum by Ken Schwager
- Rapid Application Development by Steve McConnell
- The Project Management Body of Knowledge (PMBOK) from the Project Management Institute (www.pmi.org)
- www.agilealliance.com
- www.scrumalliance.org