Agile Project Management is often compared with the waterfall approach to project management. The waterfall project management approach is most familiar to project managers, systems engineers and developers who have been working in the IT project management industry the past two decades. The waterfall approach is a phase-based approach that is based on the Deming Plan-Do-Check-Act method. The Project Management Body of Knowledge (PMBOK) contains 5 phases in its waterfall-based life cycle — initiation, planning, execution, monitoring & control and closure.
The premise behind the waterfall approach is that specific activities have a time and a place within the life-cycle, and you generally complete one set of distinct activities before moving on to another set of distinct activities. For example, eliciting requirements is conducted during the initiation and planning phases. Once requirements are baselined and approved, development begins in the execution phase.
The waterfall approach is generally accepted as the best approach for large projects. And, interestingly enough, according to the International Council on Systems Engineering (INCOSE), the agile approach is more suited for smaller projects. I do not fully agree with this premise. It is not as black and white as this. In fact, an agile approach is, in many cases, better suited for larger projects — especially when the full scope of the project has not been finalized.
An agile approach requires that work be planned and performed in a modular fashion. Each portion of work is performed in a fixed period of time, called a sprint, that is generally no more than 30 days in duration. Each sprint deliverable must be a “shippable” product, which is to say that it should be essentially bug free and ready to deliver to market (There is plenty of information on the web about how to run an Agile project — discussing sprints and backlogs. The purpose of this post, though, is to focus on the differences between Agile and Waterfall).
Before going any further, it is important to read the Agile Manifesto if you have not done so already. Main items to pull out from the Agile Manifesto are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile is also the antithesis of the “flip the switch” approach that the waterfall approach encourages. The past decade has proven that the “flip the switch” approach is not working. Projects are failing, or under-delivering at an alarming rate. Why is this? Could it be that, at the same time, projects are becoming larger and more complex? The evidence seems to be point to a correlation. Combine this with limited resources and additional pressures to deliver, and you have the perfect conditions for failed projects.
The list below provides some of the distinguishing factors between Agile and Waterfall approaches:
- Agile Approach
- An incremental approach to work
- Work can begin with a short-term planning effort
- Requires buy-in from all aspects of your business because they will be intimately involved in the process
- Does not require a life cycle
- Project work is separated into Sprints (about 30 days), which provides the opportunity to make multiple corrective actions during development
- Business members and technical members are co-located and work together closely
- There are daily meetings (especially in the Agile SCRUM approach — 15 minute standup meetings to determine progress, plan for the day and any required assistance)
- There is a great deal of responsibility placed on each member of the SCRUM team to deliver clean and working products
- Requires more up-front testing by the developers to ensure that the product is delivered bug free
- May not be the best solution for an industry that requires significant quality assurance planning and documentation
- Incremental releases of features (not a flip-the-switch approach)
- Might not require planning far in advance (however, there is a caveat to this, if you have to follow the federal budgeting life cycle per OMB-based policies and guidance
- Could be a very viable alternative to the waterfall approach for large projects with significant integration and planning. Agile is beginning to change popular opinion that it is not just for smaller projects. In fact, if a larger project can be broken into more manageable chunks, Agile could be the best solution.
- Not all requirements must be finalized before starting the work
- Requirements can be modified adjusted between sprints
- Is not a way to avoid documentation, but emphasizes the need to document only what is needed.
- Waterfall Approach
- Is based on a life cycle development approach
- Longer term planning effort
- Work is performed sequentially — planning, development, testing, deployment, etc.
- Generally business functions conducted separately from development functions (e.g., requirements developed and handed off to developers for implementation)
- Daily meetings are not a requirement for Waterfall. However, there are required project status meetings and control gate meetings at the end of each life cycle phase to verify that the project is on track and ready to move to the next sequential phase
- The responsibility of the project is more distributed among the team based on functional areas of expertise. The pressure to deliver working code is perhaps not as strong as in Agile.
- Testing is performed at various stages of development. However, the main focus of testing is after the completion of the development of the product, when it is ready for final testing. Generally, in a waterfall approach, testing is conducted at the completion of the development period with the expectation that there will be bugs that will need to be fixed. However, waiting this long to “flip the switch” means that there might be a possibility of significant errors that could impact the schedule.
- Encourages documentation and significant planning up-front.
- Long time to project completion
- Flip-the-switch deployment
- Requires Planning far in advance, with later changes to requirements more costly
- Big on documentation
Considerations for implementing Agile in the federal space include factoring in how the work with be budgeted and funded according to the OMB budget life cycle. OMB requires that project funding requests be posted 2 years ahead of time. This goes against the agile nature of Agile. Additionally, most agencies still have a life cycle that must be followed in order to support the governance policies and procedures in place by the Agency. In order to comply with existing life cycle processes, a hybrid approach should be considered. For example, the Sprints could be conducted during the execution phase of the life cycle so that the product could be delivered iteratively during the execution phase of the life cycle.
Additionally, for funding flexibility, Indefinite-Delivery Indefinite-Quantity (IDIQ) contracts could be set up, and task orders could be created off of the IDIQ. For more information on this, see OMB’s guidance “Contracting Guidance to Support Modular Development” — http://www.whitehouse.gov/sites/default/files/omb/procurement/guidance/modular-approaches-for-information-technology.pdf. (More on this document in a future post).
- http://www.slideshare.net/voximate/introduction-to-agile-project-management-and-scrum — A slide presentation about how the Agile SCRUM process works
- http://www.whitehouse.gov/sites/default/files/omb/procurement/guidance/modular-approaches-for-information-technology.pdf. — Contracting Guidance to Support Modular Development
About the Photo: At a beach in Corolla, North Carolina — looking over the sand dune at a lighthouse (July 2010).