Scaling Agile Part I: The Games We Play

Pete Behrens provides a history lesson on scaling agile and the key lessons  challenging all organizations - getting leaders and teams to play the same game.

Pete shares some personal success and failure stories in scaling agile from his own journey as well as others, and the secrets to enabling more effective agility at scale.

This is part 1 of a 2-part series exploring agile at scale.
In part 2, we explore how agile scaling frameworks are not enough.

Transcript

Pete Behrens:
What does it take to scale Agile?

Welcome to another episode of (Re)Learning Leadership, where we explore a specific leadership challenge and break it down to help improve your leadership, your organization, and, just possibly, your personal life.

I’m Pete Behrens, and today I want to talk about scaling. This is Part One of a two-part series. We call this one The Games We Play.

Now, let me take you back on a bit of a history tour of my leadership and coaching journey.

Over 20 years ago, I had my first try at Agile, putting Agile in my company. I was a VP of Engineering in a small startup, and we experimented with Scrum. Now, the successes and failures of that four-year experience left me with one key thought. “If I, as a fairly experienced process expert and leader, struggle to put out-of-the-box Scrum in a fairly simple startup system, I bet less experienced leaders in more complex systems are going to struggle.”

And not only was I right, that thought kicked off my coaching career in 2005. And I might argue my entire career since that point has been dedicated to helping companies scale Agile ways of working.

To put you in the mindset of 2005—I mean, Scrum was in its infancy. Lean and Kanban were still in the manufacturing facilities. There were simply no books, frameworks, or tools to help scale Agile ways of working. We were essentially on our own.

So, my first scaling assignment came in 2006. A retail tech company asked me to help them apply Scrum across 20 teams, a few hundred people. And so, that’s what I did. I essentially taught the rules of Scrum and gave each team a bit of autonomy in the way they interpret and apply those rules. And I might suggest we had an effective team-level Scrum. But the leaders were confused. They didn’t see—they couldn’t see what was going on. They had no way to compare and connect and relate to the programs that they were trying to execute. And, to be honest, I couldn’t blame them. I didn’t optimize for a leader game. I optimized for my coaching and that team game.

And what I didn’t realize at the time—which I’ve come to realize—is likely the number one rule in scaling. Leaders and teams have to play the same game! Let me repeat. Leaders and teams have to play the same game.

Now, as I get into my second scaled coaching experience—now, this was also the end of 2006 as I’m finishing up my other assignment. Yet, this one lasted me for about six years. And I’m talking about Salesforce. Now, Salesforce Research & Development at that time was approximately the same size. We had two dozen teams; we had a few hundred people in product development. But this time I’m brought in as a subject-matter expert on a change team. And that change team had access to not only the team layer, but also the leader layer.

Coming off my first assignment, I knew we had to integrate that team layer and the leader layer. And the good news is: Salesforce and I both had experience with, maybe, when we gave individuals and teams maybe a little bit too much autonomy. I shared my experience. But Salesforce was coming off a couple years of pretty dramatic growth. And what worked when they were a startup started to fail as they scaled. And, you know, that individualism and local teamwork was starting to break down at scale. Yet, Salesforce leaders were desperately worried and fearful of an over-controlling of that system and something they like to call tops down. And I could empathize with that fear.

But it was through this tension, you know, between this autonomy and control, that—I don’t know—only what I could describe as “beauty” emerged. I look back at the Salesforce transformation, and I see it as probably one of the most successful, impactful, and, maybe to this day, enduring transformations in my entire career. Why?

So, let’s take a look at scaling today. I might suggest there’s two predominant ways or approaches to scale Agile ways of working.

Pattern 1. Let’s call that Spotify. Spotify is likely one of the most successful Agile transformations, popularized through some brilliant videos with Henrik Kniberg that describes a value-based system, where we align on values and we allow autonomy on the practices and the way teams operate, somewhat similar to my first experience I shared.

Pattern 2. Let’s call that SAFe. The Scaled Agile Framework, on the other hand, is built on consistent processes, where all teams share the same rules and processes and cadence.

Now, back in 2006, when we’re scaling at Salesforce, neither Spotify nor SAFe was in existence, right? This was happening before. Yet, we knew the strengths and weaknesses of both of these types of approaches. Spotify is rooted in creativity, but it borders on chaos. And SAFe is rooted in control, but it borders on bureaucracy. And we recognize their strengths and weaknesses in both of their systems. And Salesforce wanted something that integrated both of those.

If you look at it from a game perspective, you know, Spotify is that team game they want leaders to start to play. And SAFe, I would argue, is a leader game they want teams to play. We wanted an integrated system. So, what did we do?

So, let’s just look at one aspect of scaling at Salesforce: the rhythm and flow of work. You know, in Scrum, the rhythm is called—that sprint rhythm is called a heartbeat. And I might suggest that in SAFe, that heartbeat becomes more of a drumbeat, as you’re getting multiple teams to share a cadence in that same rhythm. And it’s overlaid with what they call a three-month release train. This centralized coordination and cadence, I hear from a lot of teams on the ground level, feels a bit overburdening and overbearing.

Now, on the other hand, Spotify is more of a value-based system, where the flow is really determined by the teams themselves. Some teams choose cadence, and some teams don’t use cadence at all, like Kanban, where flow is more valuable than cadence. This is a game where we’re giving a lot of freedom and autonomy at that team level, but again, leaders have trouble connecting with it.

So, as we think about the Salesforce rhythm and flow, what they decided to do is connect the leader game and the team game. So they decided on what’s called a monthly connection point, where these two games came together. They dictated centralized fashion. All teams must present their done at this monthly, coordinated session. And yet, within this month, teams were given the autonomy to figure their own cadence. So some used two-week sprints, some used four-week sprints, some used Kanban, some no Agile at all. The point was—we’re going to meet up at this point here, get there how you will.

So, at these monthly sessions, the teams had an accountability to the results and to get to done and demonstrate that in these meetings. And the leaders had the responsibility to show up, listen, and give their feedback. And we witnessed standing ovations; we witnessed harsh criticisms with tears. And, you know, some leaders would share with me—stakeholders would share with me—that this was shining a light on some very dark corners, dependencies, and other things they would not see otherwise. And at the same time, I would go back to some of these Scrum teams and just feel that energy coming off that, of seeing the standing ovation of another team, a little competitive edge, or getting some of that harsh criticism. And the drive towards accountability of that system.

So you would think, after 18 years, we’ve figured out how to integrate the team game and the leader game. I’m sad to say we haven’t. I’m continually invited into organizations where the two-game strategy is at play. We get Agile running at the team game, but leaders continue to play a different game of risk management.

Why? I believe it’s because leaders don’t recognize that the game they’re playing is counterproductive to the Agile game. And they spark an Agile transformation, but they fail to consider their own game. Organization transformation doesn’t happen without leadership transformation. So, while we can get an Agile transformation started, it is going to be limited by the game leaders are playing.

So, what do we do? Leaders, you need to get in the game. Now, your role is a bit different. So, while you could attend Scrum classes, Kanban classes, or SAFe classes, your role and your focus is different. You play a game of risk management and organizational systems theories, right? You need a class focused on mindset and culture that’s shaping the field the teams are playing on. The number one thing we hear from participants joining our workshops is, “I wish my manager could hear this.” I want you to see that as a call-to-action to get in the game.

So, I encourage you to be curious. “What is the role I’m playing in our Agile transformation? What is the role I have to help—not just impede, but to actually enable a more effective Agile way of working?” Not just for Agile delivery, but for true business agility and organizational agility.

So, I thank you for joining us today. And don’t forget: next episode, we’re going to explore this topic just a bit further in Frameworks Are Not Enough. Enjoy the journey!

(Re)Learning Leadership is the official podcast of the Agile Leadership Journey. Together, we build better leaders. It’s hosted by me, Pete Behrens, with contributions from our global Guide community. It’s produced by Ryan Dugan. With music by Joy Zimmerman. If you enjoyed this episode, please subscribe, leave us a review, or share a comment. And visit our website, agileleadershipjourney.com/podcast, for guest profiles, episode references, transcripts, and to explore more about your own leadership journey.