Hybrid Project Models — Doomed to Fail? Or Can They Work?

Hybrid project models are gaining popularity with organizations that are not yet able to get rid of the traditional stage-gate model for funding and reporting projects. They are particularly popular with large companies that have long-established processes, tools, and practices, making the switch to pure Agile a long, tenuous process. 

A Hewlett Packard survey suggests that pure Agile is far more successful, yet hybrid project models make up a majority percentage of models used. Waterfall and Agile hybrid project models are particularly common. But are hybrid project models always unsuccessful and doomed to fail or can we use them to improve the world stage by stage? Let’s dive into the concept and find out.

A hybrid project model is a project model that tries to combine methodology and an Agile mindset with traditional project management practices.

First, let’s define what a Project is:

• Project Management Institute (PMI) defines “Project” as: Any temporary endeavor with a definite beginning and end.
• Wikipedia defines “Project” as: Any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned to achieve a particular aim.
• Scaled Agile Framework doesn’t define the word, but uses the term “Epic” as a parallel: An Epic is a container for a significant solution development initiative that captures the more substantial investments that occur within a portfolio.

In my words, a project is an investment to create business value during a timeboxed period. Often, the project holds a temporary staffing profile, meaning that teams are orchestrated for the specific investment and the team is dissolved when the project is completed.

On top of that, projects are typically (and historically) governed by a stage-gate model where work is approved for the next stage by stakeholders. If the approval is not attained, the stage cannot be completed and rework must be done. 

An example of stages for Waterfall projects are:

1. Requirements: Collect business needs and desires for the project
2. Design: Design the solution and how to develop the project
3. Implementation: Develop and implement the project
4. Verification: Verify that the implementation matches the business needs and desires
5. Maintenance: Hand over the solution to maintenance.

Stage-Gate Model

Stage gates are governed by project managers, stakeholders, and business owners. Traditional stage-gate models are well suited for projects where you are able to identify the requirements upfront and define how to solve them early. 

By default, the content shared at stage-gate meetings is not value-adding. It consists of a set of documents defined as something that eventually will add value.

Ralph Douglas Stacey labels these projects as simple. This coincides with Dave Snowden’s sense-making Cynefin framework where these simple, or obvious, problems can be handled using a straightforward approach: sense, categorize, and respond. This means that you’re able to sense what the customer needs, categorize the needed work, and respond by executing the work—exactly what you want when working with a stage-gated model. You need to predict the future and act with a low degree of freedom.

Another example of such stages from Scaled Agile Framework is seen in the Portfolio Kanban governing Epics:

• Funnel: Identify new epics and define hypothesis statement
• Reviewing: Review cost, impact, and suggested business value
• Analyzing: Look at alternative solutions, detail cost, define MVP/prototype
• Portfolio Backlog: Approved work adopted in roadmap ready for teams to start work
• Implementing: Develop and implement the solution
• Done: All governance stages are completed and work is done.

The Portfolio Kanban gates are governed by Epic owners, business owners, product management, and architects.

Hybrid project models combine the above behavior with mindset and methodology from the Agile world. The Agile mindset is centered around increasing collaboration, frequent delivery, continuous reflection, and improvements. We often see hybrid models as stage-gated projects with Scrum as the way of working for the teams.

This gives some immediate challenges that are highlighted by definitions of projects, Agile, and Scrum.

Projects: A project is any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned by a project team, but sometimes by a project manager or by a project planner to achieve a particular aim.

Agile: Ways of planning and doing work in which it is understood that making changes as they are needed is an important part of the job.

Scrum: Scrum is an iterative and incremental way of working in a team to deliver value. While DevOps eliminates the project manager role, they are often redefined with Scrum Masters.

The main issue with hybrid project models is that the perception of what they are depends on the individual. The teams may think they’re in an Agile environment, while the surrounding organization may think they are in a stable and predictable environment.

It’s no simple task to make the type of large-scale cultural and technical changes to be successful. And if you’re looking to succeed with a hybrid project model, you need to manage the conflict of making changes, thinking in an iterative manner, and delivering value incrementally. 

The short answer is: it depends.

It depends on what you want to achieve and how engaged you, your team, and your organization is in trying to be slightly more Agile than normal.

From experience, hybrid project models work when:

• You are able to deliver in small batches and allow the business to change direction as you go along.
• You have open and honest communication with your customers and stakeholders. It is not about playing blame games nor a question of the team not being able to commit to delivering value.
• You are not obliged to predict the future. Not even the best project managers are able to predict what will happen over time.
• You want transparency and visualize risks and progress to deliver value. Plans are made, changes happen; be open and transparent about it

Some obstacles I’ve observed in hybrid project models include:

• Challenges become visible.
• Consequences of stalling decisions by stakeholders and the business become transparent.
• Customers may think they want a detailed plan upfront, which will not be delivered.
• A project manager is not in control of all details.
• A project manager is not the center of the project, many of his tasks are decentralized.
• Management and stakeholders are not engaged in the hybrid project model and do not understand the new way of working.
• Management and stakeholders have an “I want one of those” mentality to agility, but do not want to change.
• Governance models stay the same but the ways of working change.

Hybrid project models can certainly cause disruption, but you can still find success if you take all of the necessary steps toward an open, trusting, iterative approach. If you can relate to some of these last points, then you may be in trouble. Be sure to take the time to reflect with all parties to strive for continuous improvement together.

Rasmus Kaae is working world wide as an agile coach, mentor, presenter, facilitator and trainer. As a certified Scrum Master, Scrum Product Owner and Scrum Professional, Rasmus is dedicated to bring Scrum and agility into organisations by having a full stack end-to-end and top-to-bottom approach. He is a member of the national board of Round Table Denmark, and primary driver of an internal agile community in Danske Bank.

You can find more of his writing at https://agilerasmus.com/wordpress/