Scaling Agile – Don’t scale; but reframe

As we already know, organizations worldwide realize that they need to DO things differently. They create new processes and new workflows on how they should collaborate differently. They call those change management approaches Agile transformations.

Agile coaches constantly remind, that Agile is rather a mindset and not a process or just a framework. It shouldn’t be only about DOING our work. It should also be on how we THINK differently about work.

If we want to change the way we work, we need to change the way on how we think about work.

Agile and Scrum were born as team-based approaches. One individual team can self-organize, receive customer feedback and have all the power to inspect & adapt to improve the work output and outcome. But organizations rarely exist of only one team. Typically, they exist of a number of teams with different specialties and competences. They might even have different goals and missions.

Scaling Agile Frameworks were created exactly for the reason. To be able to deal with the realities in organizations, which go beyond an individual Agile team.

Scaling Agile – with Frameworks?

Scaling Agile frameworks do have flaws:

• The SAFe approach has been becoming the most popular framework for enterprises. Based on some great ideas, the whole framework has developed into a monstrosity of Agility with a clear receipt for organizations to follow. But same as with everything increasing its popularity, quality assurance becomes equally increasingly difficult. The successful implementation is hard to ensure when practitioners follow the instructions without living the values behind. Also, it requires an army of consultants to implement in the organization. There is a lot of specific knowledge to be transferred to the client. And most of the time, it is imposed from someone on top.
• Frameworks like LeSS or Scrum@Scale are based on the popular Scrum framework. They help to ensure alignment on an organizational level to develop and deliver a product or service. But the change from a pure delivery framework to an organizational framework seems… well… abstract. How can we implement it into Marketing & HR? Albeit possible, it requires a rethinking on how to approach those frameworks.
• The Spotify Engineering Culture was introduced by this video (part 2) and shows how we can build an Agile organization specific to the need of the organization. According to an urban myth, the video and approach is based on a doodling on a napkin. And the video even clarifies the presented approach to be a mix of how they wanted Agile to be and how it was at that time. That might just be the key for Agile at Spotify. It is focusing more on evolving, than on becoming Agile. And Agile probably looks entirely different at Spotify today.
  But Organizations rather just copy & paste what they see in the video and call it the Spotify model (which never really existed). Most famously and radically done at ING Bank. Agile thought leader Steven Denning criticized that approach in his Forbes article from December 2021.
• Jurgen Appelo’s unFix model might probably be the scaling agile framework which is taking the mindset most into account. It does not tell people, what to do. It changes the understanding of roles and expectations in an organization instead. And that foundation enables each person in the organization to think differently about their work.
  But also SAFe was off to a good start. Now the website signals it to be a silver bullet for all the agility you need for any organization. Only the future will show, how the unFix model will evolve.

Facts are always from the past; never from the future

There are other approaches for implementing an Agile mindset in the organization. Niels Pflaeging & Silke Hermann use for example the Open Space Technology. But this approach does not show organizations, what the future might bring. It focuses on the process and the experimentation on doing things differently. It dances with complexity, instead of trying to control it. And only doing it will give you practices and tools to become Agile. There is no picture drawn on how an ideal implementation of the framework would look like. And this can be scary.

But I usually say: Facts are always from the past; never from the future. We do not know what the future brings. So, how does the picture on the SAFe website help us to be responsive to tomorrow’s challenges? How does the drawing of a complete future help us overcome the challenges, we do not even know about yet?

Challenges in Scaling Agile

We at semdi already experienced several challenges for beginning an Agile transformation:

• Lack of understanding of complexity and how certainty will never be 100% as long as the context is complex. Approaching a complex issue with tools from complicated contexts, will only lead to “lucky shot results”.
• Lack of an Agile mindset and using a waterfall approach with milestones and deliveries for Agile transformations, mainly:
  • Imposing how Agile has to look like from top to bottom; not taking individual’s need and mindset into account.
  • Neglect of feedback cycles in the transformation process. Because we do know how the future design should look like, we just follow the receipt. The Comic Agilé’s take on the Agile Release Train shows it humorously.
• Organizations believe in pilot projects to start transformations and rolling it out completely if successful. But there are several cognitive biases in place because each team will have different experiences. The statistics behind the potential success of the entire transformation won’t change, depending on the success of a pilot project. Also, such Agile projects might result in Agile bubbles or even in confirmation bias. If this teams fails, then all other teams will fail.
• Vulnerability and Transparency: Leadership teams feel “attackable”, when they approach uncertainty. This is often seen as a weakness rather than a strength.
  As mentioned, people are generally overwhelmed with complexity and uncertainty. This is why we look for certainty and are disappointed when the future does not turn out as desired. But in an increasingly complex world, leaders need to get comfortable with uncertainty and dance with the complexity and not trying to control it (see our 4 Pillars).
• Finally, the ever-present drive towards output over outcome and efficiency over effectiveness. Our daily pressure to be faster and more productive makes us focus on delivering something instead of more value to our customer.

So, what can we do about scaling Agile?

Change management approaches are too often about changing other people and organizations. We rarely think about the effect of change on us as leaders.

We already discussed in a past article the 7 principles we can follow on the leadership level. Instead of defining how the ideal future will look like and then work towards this, just start working in an Agile way. Look at working principles and see, what you can do in the next week to follow those principles more. Then review, reflect and improve. Improvement is exponential. The more you try to improve, the better and faster your improvement. And with the constant weekly feedback cycle, you can verify your assumptions. The Falsifiable Hypothesis will help you to design weekly experiments.

Not to Scale

I recently read the book “Not to scale” from Jamer Hunter. He describes, how humans are overwhelmed with the sheer scale of things. The bigger the company, the harder to initiate change.

We often just look at challenges from our perspective and the context we are in. A CEO of a company will look at organizational change only from her reference point. Directors and C-Level always focus on the bigger picture. This is why organizations decide on scaling agile frameworks and impose them on people. It becomes the big picture of Agile at the organization.

But this is also why a lot of them fail. The individual context, or sometimes even only the team’s context, is missing. The question should not be, how do we as an organization make the teams work differently. The question should be, how can we make them think differently about their work? Then they will change the way they work.

The Powers of Ten for context

Jamer Hunter uses the Video “Powers of Ten” as an example on how we can reframe the context on the change we want to bring.

Complexity and scale in organization is as exponential as the powers of ten. Only within 7 different scaling steps, the context of a small picnic in Chicago has turned into a picture of the whole world. Whereas the picture of the picnic is important for the context of the two participating in it, it is completely irrelevant for the entire world.

This can be transferred to a company. The context of the individual within an Agile transformation is entirely different from the context of a Group Board of Directors. Only because we are higher in the hierarchy does not mean, we can understand the context of each other level on the organization (see complex adaptive systems).

The role of an Agile transformation should be different from what we thought. Instead of supporting the change by facilitating (and often imposing) a new way of working onto others, it has to be around enabling the change mindset on each level of the organization. The challenge is not purely on alignment, it is also about sense-making. If we follow new principles (The aforementioned 7 principles, or the 12 Agile principles, or even the principles of SAFe), we need on each level of organization a sense-making mechanism within its own context.

Scalar Framing – Don’t Scale, Reframe

Don’t look just at Scaling Agile frameworks. Frameworks mostly focus on today’s challenges, not on tomorrow’s. Instead, look at each different organizational level and context. Then enable the sense-making mechanism for these levels of contexts in their current conditions. For example, start with a weekly Retrospective and enable inspection & adaptation on each level and context. Don’t impose changes or frameworks upon them. But let them see on how they can make sense in their own environment. And then they are thinking differently about the work.

They still might decide to go with LeSS or SAFe or Scrum@Scale, but then it is their response to their context and challenges. More likely is, that they will pick their own tools and practices from all the different frameworks and then create what makes sense for themselves.

In our next article, we will look at how we can use Jamer Hunter’s Scalar Framing technique for an organization to Scaling Agile.