Managing Agile and Waterfall Types of Projects in One Solution

Projects come in many shapes and sizes. Combining budget amount, scope, number of participants, subject area, degree of complexity and other attributes there are hundreds of variations. Yet, a project is a project. It requires initiation, planning, executing, monitoring/controlling and closing. It seeks to achieve objectives within time and cost constraints. There are change, risk and uncertainty. There are specific tasks performed by people using supplies, machines and systems.

Agile and Waterfall approaches both seek to manage change, risk and uncertainty in different ways. Agile opens the project to change and addresses uncertainty by breaking the project into small manageable parts, e.g., sprints, that can be planned with a high degree of certainty. The Waterfall approach seeks stability by establishing relatively firm requirements and designs early in project life and limiting change.

Waterfall and Agile Belong Together

Contrary to popular belief the two approaches are compatible and can be managed with the same solution - a project planning and control process, using an appropriate PM toolset.

Take as an example a project to select, customize and implement a software product. This project requires a waterfall approach to establish relatively firm requirements for use as a base for procurement and does well with an agile approach for the detailed functional design and software development for enhancements and integration with in-house applications.

Similarly, a process re-engineering project using software applications requires a waterfall approach in the early stages to set requirements and designs sufficient to establish budgets and target dates and get approvals followed by agile software development and waterfall-like deployment.

While some software developers may think that their projects are purely Agile, the reality is that a software development project is embedded in a higher order project or program that is focused on using the software product in a business process or making it available to the marketplace. Funding is required. Priorities among projects competing for resources must be decided upon. The Project backlog must be created. An architecture, design and methodology must be established. Training and procedural change must be planned and executed. The product must be rolled out.

Just about any project of substance requires a combination of waterfall-like initiation, requirements definition and design, and an agile-like detailed requirements definition and development followed by a waterfall-like approach to deployment.

Managing the Schedule

Managing such a project requires the adaptive use of project management tools and techniques. The PM is responsible for predicting the project outcome by keeping the schedule and budget current. Doing so means monitoring the changes in the schedule that occur when tasks slip or finish early.

Using traditional PM tools, it is necessary to clearly differentiate between the waterfall parts of the project in which most dependencies can be set at a phase or large activity level and the agile parts in which detailed requirements activities, detailed estimating and sprints must be planned at a level that recognizes dependencies among small, short tasks.

For example, an agile approach includes creating tasks for individual detailed requirements/functional descriptions and linking them with the tasks of estimating and scheduling the individual functions as a series of sprints. This is done instead of planning to complete all detailed requirements/functional descriptions before estimating and scheduling and development can begin.

The agile approach means more work for the PM who must manage the plan at a more detailed level. It's easier to link major tasks than to link individual small tasks. But, doing it the easy way overly constrains the project schedule and leads to a waterfall-like approach.

To relieve the PM of some of the burden, developers are responsible for managing their tasks, updating the plan as work is completed or dates change. These updates are then incorporated into the master plan to enable others to see the impact of variance on the project as a whole.

Making it Work

Managing waterfall and Agile projects in one solution requires that you recognize that few, if any projects, are all one or the other.

It requires knowing when and how to use your PM tools to link tasks and sub-projects in a way that truly reflects the detailed dependencies among them at the right level of detail so you can quickly see the impact of estimate variances on end dates. Make sure plan maintenance responsibilities are at the sub-project level and there is a means for integrating the sub-project plans into a master plan.

Taking this principle to a higher level, all projects should be represented in a portfolio plan that allows for dynamic scheduling at that level. Should there be pure Waterfall projects and pure Agile projects, they must both be accounted for in the portfolio plan.

Questions or comments? Feel free to share them below!

ABOUT THE AUTHOR: George Pitagorsky, PMP, integrates core disciplines and applies mindfulness meditation and people centric systems and process thinking to achieve sustainable optimal performance. George authored Managing Expectations: A Mindful Approach to Achieving Success, The Zen Approach to Project Management, Managing Conflict in Projects and PM Foundation. He is a senior teacher at the NY Insight Meditation Center.

Excellent post and I could not agree more.. Personally, I have been in projects where these 2 methodologies have co-existed.. It all boils down to work environment and how the hybrid model is being managed.. The core differences between the 2 approaches being:

In order to "bridge" the gap between these 2 methods, Agile should welcome PMI practices and vice versa. Yes the Scrum team is in-charge when it comes to tasking efforts, or estimating durations.. however, the PM should take on a role of a Scrum Master (in my opinion) and facilitate Agile ceremonies whilst maintaining PM job duties (as mandated by the traditional water fall approach) .. Now the scrum master in this case would be breaking away from what's mentioned in the Agile manifesto.. however, the resultant hybrid role is exactly what is can be described as a "Servant Leader"..

Again every workplace is unique.. understanding the work culture could be considered as a pre-requisite before implementing the hybrid / changing the existing model.. Overall excellent post and directive..

This sentence doesn't make sense to me;"Waterfall and Agile Belong Together Contrary to popular belief the two approaches are compatible and can be managed with the same solution - a project planning and control process, using an appropriate PM toolset. " Did you miss a comma or period in there somewhere?

George hit the nail on the head with his observation that there are few 'pure Agile projects' and very few 'pure waterfall projects'. Pure Agile projects do exist: for example, new products that are pure software wit minimal implementation effort, for example, Apple or Google app development. As far as I can see there are no other 'pure Agile projects'. I often see people in government trying to implement Agile principles on their software projects and it is always painful: They manage projects to enhance large and complex inhouse systems that require detailed business case development, careful and complete requirements analysis, major and mandatory implementation efforts, which is all very Waterfall and Agile has no place in that environment in my opinion ... even though Agilists do not like to hear me say that.

Eric, I mostly agree, though I think there is a place in the large projects for Agile. The pure development work can be treated like a sub-project using Agile. We are doing that in a large project at the NYC DOE and it seems to work well.

Your Name (Full):*

Your Email:*

Send me an email notification on new replies.Send me an email notification upon approval.