Learning the Truth About “Agile” versus “Waterfall”

When I originally created this post, it drew almost 200 hits in the first day which is an indicator of how important this topic is! In response to that level of interest, I’ve expanded the original video I posted below on YouTube and turned it into a 30 minute Udemy course. The new Udemy course is at the following location:


This new course on Udemy is free. The original 10 minute video is still available on YouTube at the link shown at the end of this article. Here’s a summary of both the training course and the shorter video…

Many businesses and project managers are faced with a choice of choosing a traditional plan-driven approach (or what is sometimes called “Waterfall”) or a more Agile approach for critical projects which can be a very important decision with significant business impact but there are many misconceptions about “Agile versus Waterfall” that can be very misleading.

One of the big misconceptions is that “Agile” and “Waterfall” are often thought of as binary and mutually-exclusive alternatives. The result of that misconception is that businesses sometimes force-fit their business and projects to one of those extremes when the right solution is to go in the other direction and fit the approach to the project. Sometimes projects require a blend of both approaches – it takes more skill to do that, but it definitely can be done.

Since this is such a critical decision that has such a big impact, I think it’s very important to have a clear understanding of what we mean when we talk about “Agile versus Waterfall”. In this video, I want to try to help you see these two approaches in a fresh new perspective to get the best of both of these two worlds. You can view the video here (it is about 10 minutes long):


Agile Project Management for Executives

I have just finished developing a new online training course called “Agile Project Management Overview for Executives” and I’m looking for a few volunteers who might be willing to pilot this course and provide feedback and inputs. Here’s some background…

Anyone who has read any of my previous blog posts knows that I am passionate about closing the gap between Agile and traditional plan-driven project management. To that end, I have created an online course to help project managers see those two approaches in a new light as complementary to each other rather than competitive and to learn how to blend the two approaches together in the right proportions to fit a given situation.

I realize; however, that project managers might have difficulty implementing an Agile Project Management approach unless it is consistent with the strategy of their organization and there are many organizations that are heavily engrained in a traditional plan-driven project management strategy and scared to death of implementing an agile approach. They see “Agile” and “Waterfall” as binary, mutually-exclusive choices and think that they may have to completely unravel their existing management approach and potentially risk completely losing control of their business to adopt an agile approach and that isn’t necessarily the case.

Rather than force-fitting a business to one of those extremes, a better solution may be to go in the other direction and fit the approach to the business and it might require blending an Agile development approach with more traditional plan-driven project management in the right proportions to fit their business. That requires some skill and planning to do that successfully and the new online training course called is designed to address that need.

This new course is designed to help a senior manager develop an plan for designing enterprise-level management approach that blends an Agile and traditional plan-driven management approaches in the right proportions to be well-aligned and well-integrated with their business. The course would also be useful for project managers who play a leadership role in helping businesses develop an overall enterprise-level Agile Project Management strategy.

The course provides the material and tools for a manager to:

  • Evaluate and fine-tune their current business strategy and use an agile project management approach to maximize their focus on customer value and business results
  • Define and prioritize the specific benefits of an agile project management approach that are most important to their business
  • Develop an agile project management implementation plan that is well-aligned and well-integrated with maximizing the effectiveness of their business

If you would be interested in piloting this new course and providing feedback, please send me an email and I will provide a coupon code for you to take this new course at no cost. Since I’m looking to release this new course fairly quickly, please don’t volunteer to pilot this new course unless you can commit to completing it quickly (the new course consists of 8 lessons totaling a little over an hour altogether).

What is The Role of a PMO in an Agile/Lean Organization?

I recently saw a question on a LinkedIn discussion group asking:

What is role of a PMO in an Agile/Lean organization? 

There are many people in the Agile community who might say that there is no role for a PMO in an Agile/Lean environment and that the whole concept of a PMO is inconsistent with Agile.  That opinion is based on a stereotype that the role of the PMO is heavily associated with controlling and enforcing rigid waterfall-style policies for selecting and managing the execution of projects and programs.  In that kind of environment, a PMO might require:

  • Very thorough and detailed upfront planning to justify the ROI on projects to support rigorous project/product portfolio management decisions
  • Rigid control of project execution to ensure that projects meet their cost and schedule goals and deliver the expected ROI

There is no doubt that some PMO’s have played that kind of role to some extent in the past; however, it is a stereotype to believe that is the only possible role for a PMO to play.  A related stereotype is that many people also see the choice between Waterfall and Agile methodologies for projects as a binary decision – that stereotype is that an organization is either:

  • Totally “Waterfall” with extensive upfront project planning as well as rigid policies and controls over how projects are executed, or
  • Totally “Agile” with zero upfront planning and no policies and controls over project execution

Neither of those extremes is realistic in actual practice and you have to use good common sense to fit the right level of upfront planning and control to the project and business environment that the company operates in. 

Many people make the mistake of seeing this as a binary decision and force-fit projects to one of those two extremes when the right solution is to fit the methodology (or combination of methodologies) to the project and business environment.  It takes more skill to do that – it requires knowledge of a broader range of methodologies as well as a deeper understanding of the principles behind them to know how to blend traditional project management and Agile principles and practices together in the right proportions and customize them as necessary to fit a given situation.

I believe the role of any PMO is to align the selection and execution of projects and programs with the organization’s business goals which includes Project/Product Portfolio Management, providing oversight of project execution and the overall interface for management and reporting of projects and programs to senior management and the business, and finally to provide coordination, guidance, and training to project teams as needed in the organization’s methodologies and standards for project management. 

Those general functions probably don’t change in an Agile/Lean project environment, but how a PMO performs those functions may change significantly depending on the organization’s overall strategy for implementing an Agile transformation. 

  • Some organizations may choose to implement a relatively complete top-to-bottom Agile transformation for their business – Dean Leffingwell’s Scaled Agile Framework (SAFe) is an example of such a model. 
  • However, that can be a very ambitious and gut-wrenching change for many organizations. It also may not be the best solution.  I think it is a mistake to believe that you have to force a company to do an extensive, top-to-bottom Agile transformation in order to adopt an Agile process at the development level.

Organizations typically have different layers of management as shown in the diagram below; and, at each level, there is a choice of taking more of an Agile approach or more of a traditional, plan-driven approach:

Enterprise Agile 3

At the business management level, the approach should be designed around what makes the most sense for the company’s business and that may or may not be exactly the same as the approach used to manage projects at the development level. 

  • An Agile development process is easiest to apply in companies whose primary business is developing software products (Such as Intuit QuickBooks and TurboTax) or companies where software development has a very direct and significant leverage effect on the company’s business (Such as Amazon.com).  In those companies, there is a fairly direct alignment between a company’s overall business management goals and an Agile development process. 
  • In companies where that is not the case, the alignment may be less direct.  For example, it may or may not be totally realistic for a company to adopt a complete, top-to-bottom Agile approach for their entire business and a more traditional, plan-driven approach may be appropriate at the higher levels (at least as an interim solution).  However, that doesn’t preclude implementing a totally Agile or hybrid Agile development process.  The Managed Agile Development process is an example of a hybrid Agile approach that can be used in that kind of environment.

The role of the PMO should be aligned with supporting whatever that overall strategy is.  For example,

  • The PMO may still be the focal point for Project/Product Portfolio Management, but a more agile approach might be used to perform that function.  Instead of very rigorous upfront planning that might be required to analyze project ROI to support a more traditional, plan-driven project/product portfolio management approach, a more dynamic decision-making process might be used at that level with a much more limited amount of upfront planning and less detailed ROI analysis.
  • In the other functions related to managing the execution of projects, the PMO probably would probably delegate more responsibility to project teams and  play more of a facilitative and consultative role to support the project teams rather than playing a controlling role.

In summary,

  • Agile certainly forces some rethinking of the role of a PMO but it doesn’t necessarily make the whole concept of a PMO obsolete and irrelevant, and
  • There are a wide range of strategies an organization can choose for implementing an Agile transformation at an enterprise level and it isn’t necessarily a binary choice between a pure “Waterfall approach from top-to-bottom or a totally “Agile” approach from top-to-bottom.  You have to choose the right approach to fit the business rather than attempting to force-fit the business to some kind of “textbook” approach. 

The important thing to recognize is that this is not a “one size fits all” decision.  What is the right approach for one company may not be the best approach for another.  It’s kind of like a chess game to choose the fit the right strategy to each level of the organization as shown in the diagram below:

Enterprise Agile 2