What is a hybrid Agile Approach? Is there such a thing? I recently came across an article on the Internet that was posted in several places entitled “The Moment of truth: There Is No Hybrid Agile“. This article is so full of stereotypes and misconceptions about “Agile” and “Waterfall” that I felt that I had to respond to it.  It is typical of many articles that position “Agile” and “Waterfall” as two binary and mutually-exclusive alternatives with no middle ground between the two.

What Are the Flaws in This Thinking?

Here are some of the flaws in this thinking:

    1. This article and many others like it treat “Agile” and “Waterfall” as if they were individual, discrete methodologies and they position “Agile” and “Waterfall”  as diametrical opposites of each other.  That’s not very accurate.

“Agile” and “Waterfall” are not really discrete, individual methodologies and both of those terms are used very loosely.  In common usage, neither of those are individual, discrete methodologies:

      • Many people  may think of “Agile” as being synonymous with Scrum but that is not really accurate.  “Agile” is much broader than Scrum – it is a way of thinking defined by the Agile Manifesto
      • “Waterfall” is also not a single, discrete methodology – in today’s world, many people use the term “Waterfall” for any plan-driven methodology that is not Agile.  What about RUP and other iterative approaches that probably wouldn’t be considered to be Agile?  Is that “Waterfall”?

Instead of thinking of what people commonly call “Agile and “Waterfall” as individual discrete methodologies, it is more accurate to see it as a continuous spectrum of approaches from heavily plan-driven at one extreme to heavily adaptive at the other extreme like this:

What is a hybrid agile approach?

If you think of it in that way, it is much easier to see the possibility for lots of approaches in the middle of that spectrum that blend the right level of plan-driven principles and practices with more adaptive principles and practices to fit a given situation.

Here’s what some methodologies would look like plotted on a spectrum of heavily plan-driven versus heavily adaptive:

Adaptive vs Plan-driven

As you can see from this diagram:

      • “Agile” is not a single approach and there is not just one way to do “Agile”:
        • Kanban is more adaptive than Scrum, and
        • Even within Scrum you will find different styles of implementation from simple team-level projects which may tend to be more adaptive to larger more complex multi-team projects which may tend to be somewhat more plan-driven
      • What people commonly call “Waterfall” is also not a single well-defined approach.
        • At one extreme, the original phase-gate model originally developed by Winston Royce in 1970 was very plan-driven but that approach is not widely-practiced any more in that form for software development
        • In the 1990’s and early 2000’s more iterative approaches such as RUP became much more popular for software development and provided a higher level of adaptivity

The most important point to get out of this is that there is not a clear and well-defined boundary line between “Agile” and what people commonly call “Waterfall” as many people seem to think.

  1. Many people make the mistake of performing a methodology mechanically and think they need to do it religiously and “by the book”(That’s true of both Agile and other non-Agile methodologies)
    • The right approach is to fit the methodology to the nature of the problem rather than force-fitting all problems to a given methodology (Agile or non-Agile).
    • It takes more skill to do that but it definitely can be done. It requires understanding the principles behind the methodology and why they make sense in a given situation rather than doing a given methodology mechanically.

    If you think of methodologies as being rigid and prescriptive, it will be difficult to see how two seemingly disparate methodologies could be blended together in the right proportions to fit a given situation. On the other hand, if you understand the principles behind the methodologies at a deeper level, it is much easier to see how they could be complementary to each other rather than competitive.

    Learning to be a “Chef”

    It can take a lot more skill to learn how to blend different approaches together in the right proportions to fit a given situation. In my book on Agile Project Management, I use the analogy of a project manager as a “cook” and a project manager as a “chef”.

    • “A good ‘cook’ may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.”
    • “A ‘chef’, on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.

    That’s the challenge for project managers and agile practitioners in today’s world – we need more chefs and fewer cooks.

What is a Hybrid Agile Approach?

In simple terms, a hybrid Agile approach is one that blends the plan-driven principles and practices with Agile (adaptive) principles and practices in the right proportions to fit a given situation. An example of that is the Managed Agile Development framework that I created. It simply wraps an outer layer of project-level planning around an Agile development process.

Managed Agile Development Framework

The outer layer can be as thick or thin as necessary to fit the situation. I originally developed this framework when I was managing a very large government program for a US government agency. The government agency had to have some level of predictability over the costs and schedules of the program. The program was so large that it actually had some level of congressional oversight so some level of predictability and control was essential; however, within that outer envelope, the government agency customer wanted to have flexibility in many of the detailed requirements. We were able to find the right balance of control and flexibility to satisfy both needs.

What Are Examples of Hybrid Agile Approaches?

Some of the most common examples of hybrid Agile approaches are:

    1. Agile Contracts
      • The government program I mentioned is a good example
      • I also have a case study in my book on General Dynamics UK, Ltd. who successfully used a hybrid Agile approach to manage a large defense contract for the ministry of defense in the UK
      • I just finished building a new house and I naturally had a contract with the builder that defined the cost and schedule for the home; however, the builder offered a lot of flexibility to make changes even as the construction of the house was in progress (He charges for changes, of course)
    2. Large, Enterprise-level Projects and ProgramsIt’s almost impossible to successfully implement some large complex enterprise-level projects and programs without integrating some level of project and program management. A good example of that is the Harvard Pilgrim Healthcare case study that is written up in my latest book. The project involved over 100 Agile teams and involved replacing almost everyone of HPHC’s most critical business systems over a period of time. The whole effort involved a lot of moving parts that had to be carefully planned and synchronized and it’s impossible to imagine how that could be done without a sufficient level of project and program management to guide and manage the overall effort.
    3. Other Business-driven Initiatives

Many people have the mistaken belief that you need to force the entire company to be agile in order to adopt an Agile development approach. That isn’t necessarily true. A business has to be designed around whatever critical success factors are most important for the business that they’re in and becoming agile may not be the only factor and may not even be the most significant factor. For example, some companies are in very cost-competitive industries and succeed primarily based on operational excellence to lower their costs as much as possible. Becoming more agile may play an indirect role in that but it isn’t necessarily the most important factor. On the other hand, in a company that is technology-driven that succeeds on bringing leading-edge products to market as quickly as possible, it’s much easier to see how a pure Agile approach might be a very strong and direct driver of the business.

Agile was originally developed for companies that do product development and that’s where it works best. In companies whose primary business is not developing products per se, there is typically more of a project-oriented approach. The company has to typically evaluate a potential portfolio of projects to determine what mix of projects and programs is going to have the greatest impact on their business and then they need to monitor the execution of those projects and programs to determine if it is really delivering the expected returns.

Leave a Reply