By George Pitagorsky | Follow on Twitter!
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!
You may also like:
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.