A very popular topic these days relates to how organizations involved in the delivery of waterfall projects can be more “Agile”. To many, this is tantamount to asking one to square a circle and is considered at best impractical but more often, considered heresy.
The underlying assumption is that some projects just can’t be delivered using an iterative approach as dictated by Agile methods and that as such, some waterfall projects can never derive the benefits of Agile since they cannot be delivered in an iterative fashion. But perhaps this assumption takes the meaning of Agile a bit too literally.
The concept of Agility relies on 4 values and 12 principles. Now, to be Agile, must we absolutely comply 100% with all these values and principles? Is Agile an “all-or-nothing” proposal? Is it possible to be, say 75% agile? Can someone be only 33% agile? If you are, is there a possibility that you could then derive at least “some” benefits from applying these values and principles?
Must we choose between Waterfall and Agile?
Let’s look at one of those principles, possibly my favorite, principle #5: “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.”
Who says this can only be applied successfully when delivering projects iteratively? What in your experience tells you that an organization should not apply this in the context of a truly waterfall project?
Let me get something out of the way here. Too often we hear of the contrast between Waterfall and Agile when, in fact, we should be contrasting Waterfall and Iterative. And if we need to contrast Agile Project Management with something, it should be with “Command-and-control”, “Top-down”or “Predictive” project management.
This can allow us to have both Waterfall-Predictive approaches and Iterative-Agile approaches but also would allow Waterfall-Agile combinations, no?
Going back to principle #5, is it possible to apply this principle to a waterfall project team? But if do so, what would the practical implications be on our project roles and responsibilities. Specifically, what would be the impact on the role of our planners and schedulers?
Planners vs Schedulers
The difference between Planners and Schedulers is often misunderstood and as a result, organizations and projects occasionally suffer. As we often say, words matter. Both planners and schedulers understand the rigors and discipline of project scheduling, critical path, proper WBS best practices, etc. In most cases both also possess some mastering of a project scheduling tool such as Microsoft Project or Oracle Primavera P6. The difference is that the planners have intimate knowledge about how the work is performed since they are folks who typically performed the work in a previous life or earlier in their career. Schedulers, on the other hand, are often recent graduates with little practical experience in the execution of the work but more intimate knowledge of the technology involved in creating and maintaining project schedules.
In other words, planners know a lot about laying pipes and erecting structures and a little about using MS Project but schedulers know a little about laying pipes and erecting structures and a lot about MS Project.
So while a scheduler must rely on the team to provide input on how to build the plan, a planner can be tempted to create the plan on behalf of the team. And here is the disconnect with the Agile philosophy. Planner-built schedules are just a bit less likely to benefit from Agile principle #5 but also #11: “The best architectures, requirements, and designs emerge from self-organizing teams” (here you must replace the words “architectures, requirements, and designs” with “plans and schedules” to apply this principle to waterfall projects).
A resulting argument could be that to be truly Agile in a waterfall project, one needs to rely less on project planners and more on schedulers.
What are your thoughts?
