Scaling Agile FAQ

Recently I published an article Revenge of the PMO that argues against a particular framework for agile at scale known as SAFe. 

This was a bit unusual for me in that I normally don’t like to write much about process because the topic is so religious to so many people. 

But occasionally a particular process will rise in popularity to the point where I worry it might infect companies I care about, so that’s what pushed me to share my thoughts in spite of my reluctance.

I also did this about 10 years ago when the rise of Six Sigma threatened to destroy innovation at several companies I cared about.

But judging by the response to the article, clearly the topic of Agile at Scale, or more generally, producing technology at scale, is an area with a lot of pain and confusion.

For those that don’t know me, my main thing is that I get to work with many of the very best technology-powered teams and companies, and I am continuously amazed at how different the best companies work compared to how most companies work.  And that’s true at every size, from startups, to growth stage, to enterprise. 

This topic demonstrated this yet again.  I try to share the practices of the best companies with the rest.

I received quite a few questions on Twitter and also via e-mail, so I thought I’d share the main questions and my answers in a follow-up post on this topic:

You’ve said yourself that innovation isn’t about process, it’s about culture.  So why is this process such a big deal?

It is all about culture.  This is precisely why I am so concerned if a company makes an explicit choice to move to something like SAFe.  This is a very clear and loud statement about culture to the company.  It tells me the company does not understand or appreciate the role of engineers or designers in innovation. It tells me they are all about top-down control.  Most importantly, it tells me the leaders don’t understand what they need to do to compete against the likes of Amazon.

What about the idea of using a process like SAFe as a first step towards where you describe?

In theory I want to like this argument.  I have seen many very strong teams start with Scrum and after 6-12 months moved on to more streamlined versions of Agile.  Scrum served a useful purpose for them, especially in establishing a little structure and discipline across the organization, but then the team realized they could work even better.

But moving to SAFe does not feel the same.  It is so big and heavy, much bigger and heavier than what good companies use.  And it doesn’t address the real issues that need to be addressed if the company wants to make meaningful progress.  Also concerning to me is that I have not found anyone that said they were successful in using it as this first step and then progressed on to a product-mindset model.

We’re not a startup; we’re a big company with lots of stakeholders and constraints.  Don’t we need to use a heavyweight process like this?

Let’s consider three of my favorite enterprise-class tech companies: Google, Amazon and Netflix.  All three are at massive scale, very likely beyond anyone using SAFe.  Google alone has seven different products with more than a billion users each.  Amazon is an innovation machine, with products and services for consumers, businesses, and developers.  And Netflix continues to reinvent itself, bigger and better each time.

As I’m sure you can imagine, just like your company, they each have many stakeholders and many constraints.  Amazon and Google both also provide services to businesses, some of which are in regulated industries, so this introduces constraints on them too.

Now each of these companies has their own favorite techniques, and each has a different company culture, but all three have built their businesses on the concept of hiring skilled people – especially engineers, designers and product managers – and then empowering them to solve hard problems. 

That is why I can’t conceive of any of these companies ever moving to a process anywhere even close to SAFe.  Maybe more importantly, they are an existence proof that you don’t need to.

Isn’t SAFe just a tool?  As such, can’t it be used for good or evil, like any tool?

This is one of the most dangerous misconceptions, that tools, frameworks and processes are somehow agnostic.  I am definitely planning to write more about this (update: I did write about this here), but it’s important to realize that tools, frameworks, methodologies and processes are all trying to encourage certain types of use and discourage other types of use.  I don’t necessarily mean this in a bad way.  Sometimes I love the behaviors they encourage (like Slack regarding team communication) and other times I hate the behaviors they are encouraging (like most roadmap tools).

It’s also true that any tool can be used incorrectly.  For example, I advocate the OKR system for focus, alignment and team empowerment, yet many teams don’t get the real value because they make the very common but serious mistake of putting output as their key results.

But it’s critical to realize that most tools are not agnostic.  Their creators are trying to facilitate a certain way of thinking or working.  You need to ensure that’s how you want to think or work.

You called out the PMO as personifying the project mindset.  Is all project and program management bad?

Most definitely not.  The program/project mindset is the problem, however, there are many people out there today that are critically necessary when dealing with product at scale.  I am actually a big advocate for this role, but I prefer to refer to them now as Delivery Managers. 

What if we’re a regulated industry?

This is an orthogonal point.  I work with teams and companies in regulated industries and the constraints introduced apply whether they’re a startup, growth stage or enterprise.  Many people mistakenly believe that you can’t use modern practices in a regulated industry.  This is not true.  My partner Chris wrote an article about this recently.

What do you mean by project-mindset vs. product-mindset?

This is really the core of the topic, and I have written several articles about this and I know I need to write several more.  In fact, maybe even a book.  Here are several places to learn more:

• https://svpg.com/product-vs-it-mindset/
• https://svpg.com/good-product-team-bad-product-team/
• https://svpg.com/product-fail/
• https://svpg.com/product-success/

Update: I wrote a major piece on the topic here.

What are the alternatives to SAFe?

Dan North reached out to me after I published this article and pointed me to an article he wrote on the same topic, but he spent more time talking about the alternative, and less time beating up on SAFe.  I thought his article is excellent and wish I had seen it earlier.

I also describe the best practices I know of and advocate in my book: INSPIRED V2.  One of the main themes of the book is “Product @ Scale.”

Why is this topic even important?

First, I will confess that as a product person, I’m fairly paranoid that someone else will come along and take my customers.  And today, more often than not, that someone is Amazon.  I know first hand that they are very good.  I also know that if your company has not learned how to leverage technology and put technology-powered innovation at the very heart of your company, then you will not be able to respond when they come after you.  I also believe they would love it if you continued to use SAFe, and they’re betting you will.

I’d like to close this with a quote from Jeff Bezos’ annual shareholder letter:

“If you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.”