The Agile Coaches' Coach Shares Her View on SAFe

This article conveys one agile coach’s journey coming to terms with Scaled Agile Framework™ (SAFe). Like pretty much everything I write, I’ll tell this story from my first-person perspective. I can’t help myself. I have an “I” perspective bias, which has me pay close attention to an individual’s internal experience, including my own. SAFe has an “ITS” perspective bias which is all about the external observation of a system or collection of things. We don’t always see the same world. More about the biases later.

When I first heard about SAFe, I was curious so I took a peek at the “Big Picture” diagram online. It gave me hives. It was just a little too much for me to take in and it looked way too much like those process and boundary diagrams I created when I was busy process-itizing software development as a Program Management Office (PMO) Director. Phrases like Program Portfolio Management were featured big and bold on the SAFe diagram; the very same words that I had unintentionally used to shackle people to a soul­killing process. I’m pretty sure one organization for which I was PMO Director is still struggling under the weight of the overly specified Sarbanes­Oxley (SOX) processes I was convinced we had to define in excruciating detail. You can probably tell that it brought back some not­too­pleasant memories. I have major karmic debt to work off there. Haunted by my past, I clicked the x at the top of the screen, and the Big Picture SAFe diagram disappeared. Whew! See? Gone. Now I could safely ignore it!

But I couldn’t escape it. SAFe kept coming up, most recently in our course, The Agile Facilitator, where every­so­often a student would ask, “Yeah, but how does that scale to our 150-person SAFe meetings?” 150-person meetings? You have to be kidding me! How many people do you think it takes to facilitate a 150­person meeting? I’ll give you a hint: more than one. Yet, this is exactly what SAFe was asking these Release Train Engineers to do! It became increasingly clear that the time for me to learn more had arrived.

Over the course of the next few months it would unfold that I would take a SAFe Program Consultant (SPC) course, as well as observe SAFe meetings in action. What I discovered is offered in this article; they are my thoughts alone, not an official “position” (no animals or corporations were harmed in the making of this article). I also need to disclose that I have not yet “done” SAFe. I am looking at it from the viewpoint of the discipline of agile coaching.

Direct Learning

I took the full SAFe Program Consultant course from the voice of SAFe itself, Dean Leffingwell. I wanted to hear it “from the horse’s mouth” as they say.

Based on the way the SAFe Big Picture looked to me, I walked into that class very concerned that SAFe would take away the teams’ creativity by “pre-chewing” the stories into requirements a la my project management days. I thought I might see the rebirth of “The system shall...” statements. I was also worried that SAFe would take away teams’ autonomy and reverse our still fragile belief in emergence; the diagram just looks so top down! These concerns put me on alert for anything that appeared to undermine the Agile Manifesto or the Scrum values.

A surprising thing happened in that class. Over the course of the next few days, the Big Picture morphed from being something ‘old-school’ that looked familiar, to something wholly unfamiliar, more multi­dimensional, and much more agile-expressive. Some of the old words were there, but they took on new meaning as we learned ways to help organizational managers decentralize decision-making and limit overall work-in-progress. These are the same things we espouse at the team level, just brought to a level where they can have positive systemic influence for all teams.

In class, I saw that the Agile Manifesto and Scrum values were alive and well and living inside SAFe. What Scrum gives to a team, SAFe gives to multiple teams working on the same product, or in the same value stream. When I later visited a large Fortune 500 company to see it in action, I witnessed a beautiful expression of these values in full bloom; far beyond what I had seen in my own work coaching groups of loosely confederated Scrum teams.

My direct learning yielded these thoughts about SAFe and the Agile Manifesto:

Individuals and interactions over processes and tools

SAFe maintains the safe haven for these precious individuals to collaborate within their intact Scrum teams, and at all levels of SAFe. I was skeptical about this, but then I saw a Release Planning session with 20­some teams and almost 200 people, and realized how SAFe is Scrum, just expanded to the program level. I became aware that Scrum itself scales beautifully.

Twenty­odd teams in the same room can do a wonderful job of simultaneous Release Planning. Going one better, SAFe upholds Scrum at this program level with the added structures of whole­ release­train cadence and synchronization, both of which get the product sprinting, not just the teams.

The people in the Release Planning meeting were not being told how to do their work, nor being given specifications at “The system shall...” level. The Product Manager ignited a fire of creativity and excitement by clearly articulating the vision for the product and disciplining herself to stay out of the “how”. It was music to my ears.

Then, the Release Train Engineer said, “OK, it’s time to plan for the next Product Increment, you all know what to do” and people jumped to action. I’m not kidding. They actually jumped out of their seats. The energy in the room went through the roof. Within 45 minutes, a couple dozen teams had draft release plans and were working out interdependencies with one another. The Product Manager was bopping around as teams asked questions, making sure they were aligned with the product vision. Each Product Owner was embedded with their team, explaining business intent and making tradeoffs.

The Release Train Engineer and one of the ScrumMasters facilitated the session with skill and full presence, attending to the many seen and unseen aspects that make a huge meeting clear, engaging and productive.

It went well because teams had the benefit of a well-facilitated meeting and full access to the product visionary. In addition, they made good use of technology and business managers, who were able to clear impediments on the spot. I only wish the loosely confederated groups of teams I coached in the past had access to this kind of “flow accelerant.” It was great.

Working software over comprehensive documentation

Since SAFe gets the entire product (or value stream) sprinting, working software comes out, integrated and done­done, on a regular cadence. Just like it does on Scrum teams, only now at the level of many teams. SAFe uses epics at the portfolio level, features at the program level, and user stories at the team level. No extra documentation required. Just the same structures we have always been using with Scrum, except that epics get expressed by the people who have their finger on the overall intent of the product/value stream (portfolio level), features get expressed by product management (program level), and user stories get expressed by the product owner and team (team level). Each level expresses what it best knows, closest to the source, and the voice of the overall product gets heard directly.

Customer collaboration over contract negotiation

A lot of people think about this Agile Manifesto statement as being about collaboration and contracts with outside customers or partners. That’s a worthwhile angle, but the angle I want to address is what happens within an organization.

An incredibly frustrating aspect of multiple Scrum teams in the same product area is the interdependencies between them, which can easily turn into interdependency gridlock. The cause of this is the way organizations organize. Most don’t yet organize in a way that lets us slice the Wedding Cake into thin slices of actual customer value. I can rail against that all day long, but in the meantime, interdependencies between teams flourish and can result in unexpressed contracts -- think of them as informal Service Level Agreements (SLAs) between teams. This offers life­saving mouth-to-mouth resuscitation for intermediary roles such as Business Analysts and Project Managers, as they run around coordinating these squishy SLAs.

What I observed is that SAFe brings all the players into synchronization on a regular Release Planning cadence, allowing teams to collaborate on the overall product(s) together. In doing so, the teams recognize interdependencies and work them out themselves, team­to­team. Interdependencies that could not be worked out were escalated to the technology and business managers right there in the room. This is an incredible short­cut. No Business Analysts or Project Managers (or ScrumMasters) need to navigate the organizational hierarchy to get these problems addressed over the course of many days or weeks. Instead, they get resolved as they are identified, giving everyone a clear view into the straight-line logic between interdependencies and trade-offs. Namely, interdependencies that cannot easily be accommodated are simply business trade­off decisions waiting to be made. With the synchronization of Release Planning, the people who can make those decisions are right there at hand. I saw such interdependencies get resolved as the product manager, aided by program-­level managers, made trade­off decisions on the spot.

Responding to change over following a plan

I haven’t yet seen evidence of this one in action, although I can imagine it. To do so, my horizon has to expand from the cadence of one or a few Scrum teams, to the longer cadence of a Release Train Product Increment. Just the same way that Scrum allows quick product adjustments at the border of every sprint, SAFe allows adjustments at the whole-product or value stream level at each Product Increment. And, adjustments still happen within each Scrum team during each sprint, as well.

Lean in the Lead

Perhaps one reason people assert that SAFe violates Agile values is that it focuses on Lean principles first and foremost, throughout an organization. It has a greater allegiance to an entire product sprinting, an entire business area ordering their work on business value, and an entire management team limiting how much WIP they put into an organization. SAFe simply gives more weight to Lean, which puts the focus on the product or value-stream rather than on teams.

At the same time, SAFe is 100% reliant on functional Scrum teams and their ability to live fully into the Agile Manifesto and Scrum values. There need not be an argument between Scrum and SAFe. It’s “both / and”. If the teams cannot deliver quality product within a timebox with regularity and sustainability, SAFe will not work. Period.

Just like Scrum, though, SAFe isn’t easy. It has some built-in assumptions and treacheries.

SAFe Relies on Agile-Acting People

SAFe completely relies on “agile-acting” people. All the way up, all the way down. The difference between a generative, full­of­energy Agile Release Train planning session and one where teams just come to “get their marching orders” cannot be seen on the page. The agenda for the meeting is the same in both cases. The difference is how much agility the people participating in the meeting already possess. For SAFe to work well, that level of agility and strong personal agile mindset needs to be quite high.

Could an Architect quash creativity by overly specifying architecture or coding standards in this meeting? Absolutely! Could a manager kill innovation by saying, “That HIP sprint demo is really great. It’s amazing what you guys created in just one Innovation week. The problem is that this means changes to our infrastructure. So, nice job but we won’t be putting it into production anytime soon.” Yeah, something like that could kill innovation pretty quickly.

With SAFe, you will likely have people participating who have never been on an agile team, never found the agile rhythm, the agile mojo. How in the world would they know which behaviors are agile-supporting and which are agile­killing? Going further, we want them to “be” agile, and SAFe needs them to “be” agile. That’s even a longer-term prospect. Possible, but a long road ahead and one that needs a guide.

SAFe is Likely to be Done Poorly

When I hear senior management say things like, “Scrum didn’t work, so now we’re trying SAFe” I get a chill up my spine. It causes me to think about the ways in which SAFe will likely be done poorly. Here are three:

Sheer veneer. Back to that manager who thinks SAFe is a substitute for Scrum. Managers who have this view clearly don’t understand SAFe, they probably didn’t understand Scrum, and here we go ‘round again. Because SAFe looks so familiar at the outset, it will be fairly simple to implement it with just a sheer veneer of understanding, housed within the same plan driven mindsets, with the end result not being agile at all. The nightmare scenario materializes: Product Owners turned into brainless minions and ScrumMasters into glorified gophers; top­down manipulation and pre­chewing the work resulting in a soulless human software factory. Could happen, but it’s not what SAFe is designed to do. That design intention probably won’t stop many organizations from creating the nightmare scenario, however.

Big means SAFe. Another pattern of SAFe done poorly arises with the unexamined assumption that just because we have a large organization we need SAFe to be agile. “Our organization is big, we need to scale,” they may say. Not necessarily so. Small clusters of teams very close to the business people may be far more effective, and may be all that some organizations really need. In these cases, SAFe would create process for process’ sake. If one, or a few, teams can get the job done, by all means stick with that; they don’t need to be “managed” within a SAFe process.

Brain-dead meetings. I have to be honest. Very few people I meet in my agile coaching classes have the facilitation skills it takes to pull off a large group meeting in a way that enhances creativity and provides the “flow accelerant” I mentioned earlier. By the time they leave class, they have many skills and techniques that will help but let me be clear here: facilitating a large group is an advanced facilitation situation. Experienced professional facilitators would find it challenging. In a poorly facilitated meeting, participants will be bored and disengaged which often leads to managers stepping in harder to “motivate” them or decide things for them. Managers, or the Release Train Engineer himself, may respond erroneously to the signals of boredom and disengagement, believing they have to step in because teams are clearly not able to “self-organize” on their own. All because the session is poorly facilitated.

Promotes bloat. Just because there are five layers of management today does not mean it has to be that way tomorrow. Just because there are 100 component teams for one product today does not mean that’s the best way to organize for a complex and ever-changing world. Perhaps these structures should be dismantled instead. Think back to that uninformed manager who thinks SAFe will cure the poor Scrum implementation. Her poor SAFe implementation would have the unintended consequence of propping up a bloated organizational design. I vote for letting those designs die a natural death, to be replaced by more modern, ecosystem-like organizational designs.

A Bigger Stage

None of this is different than before SAFe emerged. Managers and experts have always been able to energize creativity, or conversely, create zombie­like compliance for people on Scrum teams. The difference is that SAFe gives them a bigger stage on which to do so, and on a regular basis. If Scrum plays the community theater stage, then SAFe regularly plays Madison Square Garden. More spotlights, more people watching; greater possibilities for more impact and more danger.

I predict we will do SAFe with the same irregular amount of goodness and badness that we have done Scrum (and Agile at large) so far, only with higher stakes. People with agile coaching skills will likely have a job for at least the next 10 years, cleaning up and resetting things.

Back to the Biases

I mentioned at the beginning of this article that it was natural for me to write about my first-person experience learning about SAFe. I originally intended to write a more third-person, objective, maybe even somewhat scientific article about SAFe. I imagine I could force myself to do that, but every time I thought about it, I got an internal “Ugh!” It just seemed too daunting and I couldn’t see a way to even begin.

In contrast, the first-person version was a much easier undertaking because I have an “I” perspective bias. I see everything in the world through a window of the individual and the individual’s internal goings on, at least at first. In this case, I saw SAFe through my own eyes and my own internal experience. That was the most natural way for me to express it to you. You may have noticed that I even needed to personify SAFe to talk about it, as if it were a living, breathing being.

The “I” perspective is important. We’ve already discussed that managers evolving into a new state of agile-supporting mindsets are key, which is an “I” perspective issue.

SAFe comes from an “ITS” perspective bias. Again, an important view into what’s happening in an enterprise, and not the only one needed to achieve sustainable agility.

One perspective, or even two, is not enough. I must expand my awareness to include the other perspectives so that a more holistic, more complete view of the enterprise situation can come into focus. There’s also “IT” and “WE” to consider. Partial treatments are not nearly good enough.

Let me tell you about these perspectives and see if you can tell which one you are naturally akin to -- we all have one as our natural bias. These perspectives come from Michael K. Spayd’s work on Integral Agile and are much more fully (and objectively) articulated in the pre­release of his book excerpt from Coaching the Agile Enterprise. Integral Agile has been incredibly instructive for me as I try to get my arms around things like SAFe related to the complicated and complex aspects of agile in the enterprise. And, it explains why some people think SAFe will benefit agile, and others don’t.

Think of the perspectives as windows we look through. I’ve already mentioned the “I” perspective. It’s about an individual and what’s happening on the interior with them, inside themselves. When I think about enterprise agile, my first thoughts go to individuals; I often lament, “If only the leaders would evolve and shed command and control, agile would be great!”

Those with an “ITS” perspective bias are process thinkers at the whole systems level, and are attracted to things like theory of constraints and software development methodologies. They are into whole system measurement. If you find yourself saying some version of this, you might have an ITS perspective bias: “It’s the system that matters. If only we put people in a good system, they will be incentivized toward good behaviors and agile would be great!”

Those with an “IT” perspective bias are measurers of individual things: a behavior, a team, an engineering practice, or a product’s market share. They want to know if what we’re doing is working. Someone with an “IT” perspective bias may say, “If only we can get the metrics right, we can prove the results we’re getting from agile. Then, the right actions would spread like wildfire and agile would be great!”

Those with a “WE” perspective see systems of people. They are concerned with things like how groups and whole organizations build shared meaning, enact common values, express diversity and achieve a high performance state. Someone with a “WE” perspective bias might say, “If only we had a true, meaningful corporate vision, the teams would rally around it and nothing would stop them. Then agile would be great!”

One of these perspectives is not right and the others wrong. One is not even more preferred over the others. All are happening, all the time, and the limitation is that most of us agilists have a bias for one (or two); we don’t know that we’re not seeing the whole picture. For agile to be great, it will take thought and action from all four perspectives, yet most of us are looking only through one small window.

The SAFe conversation is commonly held from an ITS perspective orientation, since that is the underlying methodology it uses (like flow and process aspects of Lean). And, it’s not enough. In fact, no one thing is ever enough. No one thing covers all perspectives and matches the true complexity of the organizations we work with. All four perspectives are needed to match the complexity that actually exists, rather than reducing it to something easily explainable but utterly incomplete.

Let me bring in Rumi, a 13^th century poet philosopher, to explain:

An ant hurries along a threshing floor with its wheat grain,

moving between huge stacks of wheat,

not knowing the abundance all around.

It thinks its one grain is all there is to love.

We have so much more to love in the agile world! Rumi urges us not to become too attached to one “grain”; one teacher or one way, or, in our world, one agile framework or one perspective. I urge the same. Rather, let us look out wider and farther. That’s what an Integral Agile perspective offers us. It’s why I am investing my time in training that will bring this to the agile community. I have hope that it will propel us into a conversation that features “yes, and.” Yes, SAFe AND Scrum AND leadership development AND corporate vision AND measurement AND...

Begin by noticing what window you naturally look through. Then, start to look out wider and farther. When we meet one another in that expanded view, we will engage in far less argument and far more collaboration, yielding more sustainable results for the organizations we are called to assist. Yes AND…

About the Author

Lyssa Adkins believes that Agile is an emergent response that helps us thrive in our ever-increasingly complex, changeable and interconnected world. She is a passionate contributor to the discipline and profession of agile coaching and has trained over 2,000 agilists in the knowledge, skills, and mindsets needed to coach teams and organizations to get full benefits from agile. In 2010, she authored “Coaching Agile Teams,” which is still a best seller four years later. Lyssa blogs on AgileCoachingInstitute.com and CoachingAgileTeams.com, an important outlet for #WomeninAgile.