Why training in SAFe or scaling agile is wrong for PMs early in their careers
It's good to learn processes, but knowing how to apply a formula isn't the same as understanding fundamental principles.
Last year, a senior product leader at a Fortune 500 company consulted me. He asked for help to comprehend SAFe (scaled agile framework), which his company adopted. He felt confused by its terminology and ceremonies. More importantly, he didn’t think the PMs following SAFe practices were “doing the right job.” But he couldn’t quite put his finger on the issue. He acknowledged he lacked a good understanding of SAFe, which made him feel at a disadvantage when challenging those “in the know.” I struggled to help him because I also didn’t really understand SAFe. I only knew that most large tech companies didn’t follow SAFe and startups with fewer people didn’t need all these processes.
Recently, I took the SAFe Product Owner/Product Manager training out of curiosity. Having earlier studied Scrum Alliance’s Product Owner training, I wanted to see what many aspiring and practicing product managers can learn from SAFe.
SAFe: an amalgamation
SAFe is an amalgamation of principles, ideas, and practices derived or adopted from lean manufacturing and Agile to address one problem: how do you apply lean and agile to software development with large, multi-teams?
Once you have a large number of people working together, the biggest problem is communication. As the number of people increases, the number of connections between people increases faster. As Brooks wrote in The Mythical Man-Month
Intercommunication is worse [when you add more people]. If each part of the task must be seprately coordinated with each other part, the effort increases as
n(n-1)/2.
Example:
2 people working with each other: 2(2-1)/2 = 1 connection
3 people: 3(3-1)/2 = 3 connections (e.g., Adam to Betty, Betty to Cameron, Adam to Cameron)
4 people: 4(4-1)/2 = 6 connections
A team of 50 people has an incredible 1,225 communication or 1:1 connection possibilities.
Managing all that communication is a big problem as team size increases. Now, one approach to solving this problem is adopting Bezo’s two-pizza rule instead. By reframing the problem and capping team sizes to that which can be feed by two pizzas (12 - 16 people), we reduce the connection and thus coordination among people.
But not everything can be accomplished by 16 people. SAFe, implicitly, tries to address the problem when software development requires coordination for large teams such as 50 or 100 people. If you can’t or won’t reduce the number of people, what do you do then? [Note: It’s a good question to ask, can you always reduce team size?]
Introduce processes to coordinate human intercommunication
When you have to coordinate 100s of people to achieve the same outcome, you have to introduce bureaucracy. SAFe has a decent amount of it. While we might initially react negatively to the word bureaucracy, there are many benefits. Bureaucracy brings:
order via hierarchy, centralized authority, narrow spans of control
predictability via formalized rules and processes
specialization via expertise and specific roles
SAFe has all of these.
It brings order to the often chaotic process of new software product with hierarchy, shared cadence, and centralized decision-making processes
It creates predictability with formalized rules and processes, which reduces variance among teams and people
It has specialized roles and responsibilities such as Product Owner, Product Manager, Scrum Master, Release Train Engineer
In short, people who prefer freedom/autonomy, variability, and generalists will naturally rebel against SAFe, as they rebel against bureaucracy. Recognize it isn’t the fault of SAFe.
Why PMs early in their careers shouldn’t be trained in SAFe
The problem isn’t that SAFe training is bad or wrong. There’s a place in a PM’s career to learn about good versus bad processes. But learning about a process and how to apply a process, as in what SAFe training teaches, misdirects the learner about the fundamental role of a product manager. For aspiring PMs and those early in their career, it can confuse or equate applying the SAFe process as the way to create a great product.
Having an efficient software development process with minimum production issues or work-in-progress code does not mean the final product will be valuable to customers. It’s like learning different painting techniques will not necessarily make you a good artist. And that’s the damage of this training too early in your career. It might be acceptable for PMs in large organizations, where order, predictability, and specialization are more valued. But this kind of training too early robs the growing PM of freedom, autonomy, variability, and creativity required to build great products.
I didn’t understand this early in my PM career and it’s very easy to fall into a “trap.”
Trapping of SAFe or scrum training
First, these courses offer certifications, which in a world where we use certifications as a signal of expertise and competence, is a big draw. But think about what you are being certified on.
Second, it’s easier to champion and follow a process than wade through the uncertainty and chaos that comes from exploration and creativity. Just as it is easier to learn and memorize a math formula than to understand first principles. But it’s the exploration and creativity that push boundaries when it comes to creating products.
Third, success in applying a process can fool us into believing we know what we’re doing. The order of comes from using a process may mask the uncomfortableness we experience when we’re trying new and different things (i.e, exploration), many of which will fail. But processes aren’t supposed to fail, so we lean more into those processes to cushion ourselves from failure.
Lastly, we forget that some of the principles of SAFe come from manufacturing, which focuses on creating repeatable products. For example, lean manufacturing has the concept of “just-in-time production”, where you only manufacture something at the time when you need it. SAFe applies this type of principle to software development by recommending limits to the number of simultaneous work items. “Stop starting, start finishing” is the motto.
But in creative endeavors, there are often the opposite recommendation. For example, in Stephen King’s book “On Writing”, he discussed the need to “let your book rest ---sort of like bread dough between kneading.” Instead, put it away long enough, even work on other writing projects so that when you come back, you can come back with a fresh perspective. He writes:
With six weeks' worth of recuperation time, you'll also be able to see any glaring holes ... And listen, if you spot a few of these big holes, you are forbidden to feel depressed about them or to beat up on yourself.
Recognize that while we want the outcome of our software to be consistent and repeatable, the process of creating new products or services isn’t always smooth and repeatable like in manufacturing. In my many years of working as a PM, I’ve yet to design the exact same product twice and rarely face the exact same problem. Similar, yes. But exactly the same, no.
What should PMs learn instead?
Design-thinking. By this, I mean developing various skills used in the creative process of building new things. Specifically, these involve areas such as:
Identifying, defining, framing, and reframing problems, especially problems that have incomplete, contradictory, and changing requirements
Improving written, verbal, and visual communication such as presentations, storytelling, sketching, prototyping
Understanding the variations in how humans think, behave, and respond to needs (e.g., observations and customer interviews)
Improving interpersonal skills (e.g., negotiation, conflict resolution) when working with people with different communication styles, personal values, and disciplines
Unless you happen to have taken classes in the above area, these are the things I believe would benefit a PM more in their careers even though these are typically not skills taught or used for junior PMs.
Disagree? Let me know your thoughts below. I’ll leave a video I always think about Steve Jobs talking in 1995.
Additional Reading