Jesse recently spoke at the PMO Conference in London about The Hybrid PMO and that is our topic for discussion today.
I started my journey as a software engineer and did that for about ten years. On one ill-fated project, I discovered that I could be the greatest engineer in the world and our project is still going to fail because of leadership issues.
I traded in my computer programmer t-shirt collection for the management placement, got a project management title and a PMP. It started me on the trajectory of being in the position of leadership and influence on projects, which I felt like was my calling.
Define Hybrid PMO
Hybrid PMO is in the eye of the beholder. In project management circles it takes on a different meaning depending on whom you talk with. My colleagues—Mark Price Perry and Andy Jordan—the ones doing this hybrid PMO workshop, they have their take on it.
For me, the context of hybrid is in my specialty around agile. A hybrid PMO in a classical definition might be one that utilizes a blend of techniques to solve a particular problem—that would be Mark’s emphasis. A hybrid PMO doesn’t just put the focus on portfolio management for project selection but also puts portfolio management on execution, transition, and the whole life cycle. For me, the hybrid is about blending agile techniques in a way that is fit for purpose and context specific rather than the one or two size fits all approach that a lot of people take with agile methods on their projects.
Is hybrid agile?
Hybrid by definition is agile. I believe this strongly because if you look at any given agile methodology, it is simply a mash up of disparate techniques put together in a way that makes it collectively better. The concept of a hybrid approach to projects where we’re doing a few traditional methods mixed with agile is consistent with the development of agile methods themselves. It’s also reflecting the agile values of a adapting to context. If you want to be super innovative and exhibit a startup culture, but you don’t work in that environment, then you’re going to adapt those techniques to your context. Agile is all about evolving, adapting, and providing value in a particular context. It’s not about shoehorning your pet methodology into your current work.
When do you believe agile fits for a given project? When doesn’t it fit?
My notion of agile methods is for them to be inserted in a hybrid fashion to add value in any context. I believe that agile methods can increase the value to any initiative it’s just the question of what degree of value and overhead. The community at large has settled on a consensus of when agile and when not agile. That’s being reflected coming up in the agile practice guide published by The Project Management Institute and the Agile Alliance—it was a joint effort.
The community understanding is that agile methods are best suited for high uncertainty, high degrees of change and conflict. It’s where you can get some early winds to generate alignment and insight. There’s overhead associated with that. On the other hand, if you’ve done project repeatedly with the same people, infrastructure, and outcomes traditional methods might be a better fit.
Origin of “Hybrid is a corrupt compromise.”
A lot of it originated in the actual genesis of the agile movement. The agile movement was formulated in 2001 by a collection of IT thought leaders, who were exhausted with traditional project management for the innovation space. They viewed a lot of traditional project management as the enemy.
Fun fact: The world waterfall was never used until agile people needed to put a label on the thing they were fighting against. The word waterfall comes from the agile community to describe anything that’s not agile.
Over the last couple of decades, this expectation among agile advocates and champions is that agile means exactly this. Agile means exactly that we’re operating in two-week cycles, using story points, burned down charts, and dedicated roles. For example: If you don’t do that, then that’s not agile.
The concern is that if we have a hybrid approach that we are losing out on an opportunity. We’re compromising on innovation and collaboration. There’s a sense of loss and opportunity miss. You hear a lot of people saying “if you use hybrid you’re going to be complacent with half measures.” I’m of the mindset that says, “The glass is half full.”
If you’re using a hybrid approach, then you’re injecting something different into the mix that will be evolving the program, project, or organisation into a positive direction. It goes both ways—agile methods can be viewed as wholly irresponsible and amateurish. The best leaders are the ones who have a “yes/and” mindset instead of an “either /or” mindset.
Are there statistics for hybrid success?
The hybrid community is relatively new. Finding stats on its success is hard. There is plenty of data available for a “pure agile approach” that says like 80% of everyone who ever used the most popular collection of agile techniques saw an improvement in time to market, and 75% an improvement in productivity. That’s articulated in The Annual State of Agile Survey.
There has yet to be any data that splits the demographic of pure agile and pure traditional hybrid that tells the story effectively. If you believe in that correlation and are going to try some of these techniques, then there’s a chance that you’ll be making sufficient changes to improve what’s been broken and that there will be value.
Agile methods encourage self-organizing teams. What’s the role and impact of the PMO or project manager?
This question still comes up 20 years into this conversation. I still see a lot of project managers scratching their heads. My first answer is, “this is your dream come true, project manager.” You get to delegate a lot of the busy work that you wish you didn’t have to do so that you can be freed up to do all the strategic work you’ve been waiting to do all the time.
If it comes down individual task assignments, formulating estimates, or things that can be delegated, then do that. Instead of doing the work of 3,4, or 5 people, delegate that works to the 3, 4, or 5 people that you have. Focus on only the work you could do that they cannot. This gives you more strategic visibility. It’s primarily the value proposition from a project, program, or line manager to go for self-organizing teams.
The upside for the team is that now they have higher morale and engagement. There’s no longer any bottleneck approval, which allows them to be faster. As soon as you empower, authorize, and delegate, then stuff starts moving. If it’s not moving, then at least you’ve identified that you’re not the bottleneck and what’s going on.
The value is the power to equip and delegate without micromanaging.
Actionable tips for involving your PMO to agile methods.
I would recommend a little reading to see what resonates with you and bring it to your leadership team. Introduce the material as something that could add value, not all of it, but to try something different.
• The Agile Manifesto—two-page website
• The Scrum Guide—official textbook for the most popular agile method and framework
You can also go to a two-day certification conference or read articles online. Dig a little, and find one or two things that are interesting to you, and bring it to your peers. Get some people on board to experiment with fixing the one or two problems once and for all.
What are the conflicts of going partially agile?
This is an issue that many agile experts have—that if you choose a hybrid approach, you’re doing more harm than good. For example, you might require that we do the overhead of agile methods on top of the same traditional methods we’re doing in parallel. Now we’re doing double overhead and double management. By blending these two techniques, there is a risk that you’re trying to force things that don’t match well. As long as you’re willing to have a candid conversation about trying the hybrid, then you can fix it.
Be ready for a bumpy ride. It’s not going to be perfect. If you believe in continuous improvement, then by definition whatever hybrid approach you have today is not what it should be—you should ruthlessly evolving your official processes throughout the PMO and organization every month.
The purist brings to the table the art of the possible. The purist brings a vision of what could be, and the realist is the one who has to take that, adapt it, and evolve it to more contexts. There’s a natural tension there, and that’s healthy and the definition of innovation. The job of a project leader is to bring both of those mindsets to the table—the purist and the realist—and facilitate that dialogue.
Project management gold rule.
Just go. Get started. A lot of us suffer from analysis paralysis where we want to plan everything before we do anything. If we don’t slow down, then we might make a mistake. To which I would say, “all great innovations are built on a giant heap of mistakes.” Embrace the fact that you need just enough to get started and that you can figure out the details just in time.