Revenge of the PMO

UPDATE 2: Another name for this article could be “Product Teams vs Delivery Teams”.  That’s because since this article was published, I wrote articles describing the difference between product teams vs feature teams, and product teams vs project teams.  And in those articles, I referenced the model described here as delivery teams.

UPDATE 1: I just want to make very clear that I am in no way affiliated with any of the various Agile organizations or alliances.  We receive nor provide any funds to any of them.  That is our firm policy at SVPG.  My thoughts below are purely in the spirit of helping companies make informed choices on what processes or tools might best serve their needs.

I was first introduced to Agile methods about 15 years ago, when I first encountered some product teams that were experimenting with new ways of producing software.  I’ve been a long-time student of processes and tools for product development, and since the origin of these methods were from the custom solutions/projects world, I was asked early on about my thoughts on how to leverage these methods for the product world.

I was immediately attracted to several of the core principles of Agile, as they attempted to institutionalize several of what I considered the most important traits of the best product teams.

While there’s lots of rituals around almost any process, the essence of Agile, from my perspective as it pertains to product teams, was really around two things:

The first, which usually gets the most attention, is the notion that it is better for us, and better for our customers, to release a steady stream of smaller releases – generally on the order of releasing every week or two (the more frequent the better).

For companies used to releasing monthly or even quarterly (the norm back then) this meant some big changes in how they built, tested and released their work.  While this was a non-trivial hurdle for many teams, which usually meant they had to invest in test and release automation, teams came out the other end better for it.

The second, less obvious but in my view the most profound, is that Agile would empower a team to actually go figure out how to solve a problem.  That may sound like it should have been obvious, but back then, this was generally not how the world worked. Instead, stakeholders would give the teams very specific lists of features to go implement (i.e. roadmaps) and then project managers would very explicitly assign and track tasks to specific people, and shepherd the release to production (output). 

So while the first change represented a significant difference to how software was actually produced and released, the second change was more about how teams actually work and solve problems, and who takes responsibility for the outcome.

The first change didn’t really bother most companies.  Sometimes their marketing people struggled with the much more frequent releases, and sometimes customers struggled with change fatigue, but good techniques emerged to deal with these second-order effects.

The second change, however, is a different story.  The politics inside companies became clear with the second change. 

Many stakeholders were not comfortable turning over responsibility to the product teams, especially when they had ill-equipped “product owners” that were more about the process and the backlog, and much less about the deep knowledge of customers, data, business and industry necessary to enable the team to effectively solve hard problems in ways that worked for the business. 

So then – and still today – in most companies, the stakeholders still provide the teams with roadmaps of what features and projects the stakeholders think best.  Even though the teams use Agile methods, the teams are not empowered and accountable in the sense I’m describing.  They are there to implement.

But aside from still getting the roadmaps, the teams were largely able to self-organize and run their teams as they best saw fit, which definitely has some significant benefits, including in productivity and team morale.

But there was another faction in most companies that was decidedly not happy with Agile.

Most larger companies in the pre-Agile days had a fairly powerful organization called a “PMO” which stands for Program Management Office (program management is essentially project management for very large projects). 

This is the group of project managers that are responsible for herding the cats (product, design, engineering, QA, operations, etc.) and ensuring that the roadmaps get delivered “on time and on budget.”  They are the personification of project-mindset organizations.

When most companies moved to Agile, this PMO group was intentionally sidelined.  The argument was that the product teams should step up and take responsibility for this.

In some companies the PMO jobs were actually eliminated, but in others they were largely pushed aside from the software efforts and relegated to things like orchestrating moves from one building to another.

As you might imagine, this didn’t sit too well with the PMO organizations of the world, but the momentum behind Agile was too great, and the frustrations with the old ways of working too real, so they spent nearly a decade trying to figure out their place in the tech world.

But they have returned.

Over the past few years, a number of companies have asked me about this notion of processes that focus on “Agile at Scale,” the most heavily marketed (judging in part by the amount of spam I receive) such process is SAFe (Scaled Agile Framework).

Now I need to be clear on something here. 

Normally I only write about processes and techniques that I can vouch for first-hand.  The problem here is that I don’t personally know of a single leading tech product company that is using SAFe. 

So while I have read the white papers, and watched the videos, and have spoken to many people now that have been trained on and been forced to use SAFe, everything I know about this is all second-hand.

All the examples I have found are big IT, project-mindset organizations – big banks and insurance companies – not technology-powered product-mindset companies – so not the type of company that I would normally work with.

I will also admit to a strong bias.  From all that I have read and heard, I would not want to work in a company using a process like this.  I can’t imagine any of the strong tech product companies I know choosing to move to SAFe, and if for some reason they did, I’m pretty certain their top talent would leave.

Now the people behind this process are pretty savvy.  Rather than a frontal assault on Agile, they take an “embrace and extend” marketing strategy, so you will find every buzzword you’ve ever heard from the Agile and Lean worlds including Scrum, Kanban, XP, Lean Startup, Lean UX, Continuous Delivery, and DevOps.

But it’s just a marketing strategy.  Mostly they just redefine the meaning of these terms to obscure their purposes.  An Epic becomes a “mini business case;” the concept of governance sounds less onerous when called “lean governance;” and program management might cause less angst when positioned as “agile program management.”  The constant talk of iterations and agile obscures the reality that these “Agile Release Trains” are mostly happening every 10 weeks. 

I could go on, but hopefully you get the point.  The core benefits of Agile and Lean are lost.  More accurately, if you follow their process, I find it inconceivable that you’ll be able to achieve the underlying benefits of innovation that can come from effective use of Agile and Lean methods.

A couple years ago I wrote about the root causes of product failure in product companies and I identified ten key attributes of Waterfall and project-mindset.  I went through and compared this list with SAFe, and literally all ten problems exist in SAFe.  Indeed, I would argue that all ten problems are inherent in that process.

At its most fundamental, the critical notion of a dedicated product team (aka squad) has been gutted.  In SAFe, this concept of a true product team has been undermined and demoted, and the core concept is now a Program, which has a top-down model of a product manager, an architect, and a release train manager, and these people make all the key decisions, and then some number of engineering teams with a low-level product owner are assigned various parts to build.

There are several variations of SAFe depending on just how big you are, and just how much command and control you want to put in place.  But if you were an old-school PMO missing your classic portfolio, program and project management, you would probably love it.

The bottom line is that SAFe is very much a top-down, mercenary model; the role of design and especially engineering is not nearly as strong as it needs to be; it’s all about output and not outcome; and the real consequence is the obstacles to continuous innovation.

In fairness, I can imagine some scenarios where a process like this might be appropriate (or at least not much worse than the alternatives):

• an organization where most, if not all, of the engineers are outsourced, using an agency or contractors
• a big re-platforming effort (assuming the team had competently determined a suitable architecture and technology stack up front)
• an organization without true product managers or true product designers, and with very weak or inexperienced engineers

For large project-mindset organizations I can understand the appeal of the return to the command and control model, but for companies that depend on consistent innovation, and the critical role of engineering in invention and not just coding, I believe this represents a major step backwards.

When I first heard of this process from someone that was working in a company (a large bank) that had adopted it, I told them it just sounded like the death throes of Waterfall and I was pretty sure it wouldn’t go anywhere.  But in truth their message seems to have resonated with project-mindset organizations, and just because it may cause an allergic reaction in Silicon Valley doesn’t mean it won’t get traction elsewhere.

In particular, just about every large pre-Internet company out there today has some sort of “digital transformation initiative,” but what most of them don’t realize is that the heart of this transformation is moving from project-mindset to product-mindset.

When you combine the appeal of the message of “leveraging modern concepts of Agile and Lean” with the very real challenges that come with scale, it’s not too hard to see how big companies can fall prey to this marketing strategy, ironically often in the name of digital transformation.

The rise of these sorts of processes makes clear to me that large portions of the broader industry still don’t understand the difference between project-mindset and product-mindset, and so they don’t see the real value in Agile or Lean, or have such a superficial understanding that they’re easily swayed. 

So I am going to redouble my efforts to help make these points.  Watch for several more articles on this topic of the differences between project-mindset and product-mindset teams and organizations.

Special thanks for Jeff Patton for his comments on a draft of this article, and also to Ken Schwaber and Ron Jeffries for publishing their thoughts.

NOTE: I received many questions after the publication of this article, and I posted the follow on: Scaling Agile FAQ.

UPDATE SEPTEMBER 2020:

This article has now been out there for over two years, and has spread quite widely across the industry.  Hundreds of people have personally contacted me to tell me how this is unfortunately their reality, and their problems with SAFe were at least as bad as I described.

Interestingly, thus far, not a single person has reached out to tell me that they have had much better experiences.  I did learn of one true product company, Fitbit, that at one point did try to use SAFe.  When I followed up someone I know there, I was told that they had abandoned the process, and the person that had persuaded the company to try it had left the company as well.  My friend was surprised to hear that the SAFe marketing site still lists them as a reference customer for the process.  Very telling.  I ended up describing their experiences here.