Scaling agile should be easier

Scaling agile should be easier

Googling “agile” yields over 96,100,000 results. A lot has been written about agile methodologies, mainly around the workings of individual teams. People have also considered what it means to scale beyond one team, debating how to approach the task.

I’ve seen some comments in the agile for complex systems community recently expressing that:

  • Existing scaled frameworks don’t always work.
  • The frameworks have gotten too complicated and require too much overhead.
  • We’re being bombarded with new software tools and conceptual frameworks selling the new “best way” to get things done.

 

There’s a feeling that the influx of information is drowning out the signal. Some people advocate dealing with the framework feature creep by going back to the core agile mindsets.

We can agree that the more people, processes, and technologies you have in your enterprise, the more complex it gets. And the core goal of “scaling agile” is to transform that enterprise into a better one that achieves your desired purpose. By making changes incrementally over time.

 

Is it possible to simplify this complex problem?

There’s a popular metaphor for describing systems thinking. Imagine that you’re in a dark room. You’re told that there’s an object in the room and asked to determine what the object is, using only your sense of touch. You describe the object as rough. The other person in the room says that it’s smooth. It’s only when you shed light on the entire item that you can see that you were both describing the same thing: an elephant.

We pay attention to a small percentage of the information that we encounter. We remember even less. And that doesn’t count all of the possible data points across the world and throughout time.

Each of us is walking around with a small percentage of the “truth,” that can be completely different depending on our experiences and worldview. We take those inputs to build our own mental model of how things work.

So, shared mindsets can be important. Shared values can help the team prioritize and make some decisions.

But shared mindsets don’t necessarily lead to shared mental models.

Bounded rationality is a real problem. We’ve seen it in enterprises and politics. People operate within what they know and understand, instead of considering both the system view and their individual view. Sometimes people just can’t see the broader system until they view it from a different angle.

So it’s possible that your team is operating from completely different mental models of both what you’re building and how you’ll get it out the door.

The agile manifesto lists values like “respond to change” and “collaboration.” That might tell you generally how to deal with the system you’re working in, but not what to do.

An individual can figure out how to start from a mindset and create their own procedures. They can also discuss with others.

But when you move beyond a handful of people, trust and vocabulary become a larger problem. The more complex the work you’re taking on, the less information and control each individual has. When you’re dealing with an invisible elephant, you need different representations of the truth.

Scaling frameworks help provide a shared mental model by explicitly expressing a process to deliver value.

 

The question then is, which approach is faster and more effective? Detailed frameworks or going back to basics?

To think about this, let’s talk about food. When we start learning to cook we tend to follow recipes. Then we might learn a few cooking techniques and some typical food pairings. Great chefs can combine insights from experiments, research, feedback from their palate, and knowledge of food science to craft completely original (and delicious) dishes and menus.

Engineering is the same. We can take designs off the shelf and integrate them. We can study patterns that were effective in the past. Or we can learn the underlying science and derive our decisions from there.

It’s easy to forget the curse of knowledge. Your location on the learning curve impacts your perception of the system. When you’re new, you need more context and guidance to orient yourself. With more experience, you have a different mental model of the system and can more easily see how each action and decision impacts others.

Not everyone will be at the same point in the learning curve. So new team members might get more value out of more detailed frameworks than long-term employees or subject matter experts.

Whether we apply detailed frameworks or not, someone still has to make decisions about everything. Both the big picture and day-to-day operations. So picking a simpler framework is not really less work at all, it’s just a shifting of responsibility from learning and applying to designing and experimenting.

At some point, theory needs to meet implementation if we want to get anything done. That’s where most of the questions come up. “But what does this change mean for my daily job activities?”

Some frameworks try to address these questions by adding more details, based on what their creators have seen work. Those details can make the framework seem more complicated and difficult to implement. But they can also reduce barriers to change.

One of the biggest benefits of frameworks is that they help reduce procrastination. They give you a starting place to work from and also lighten the cognitive load for other tasks. Sometimes you just want to get something done without spending years learning and designing your own approach from scratch. We use tools to get things done faster.

However, there are assumptions embedded in frameworks. Like software or physical products, the designers embedded assumptions about desired workflows and context in the design itself. For example, one popular framework for scaling agile, SAFe, asserts that the portfolio exists to realize a set of technical solutions. It also assumes that the business has already figured out how these solutions fit into the business strategy. Some frameworks work better when there are many interdependencies than when there are fewer. Some assume that you have certain elements, people, or mindsets in place already.

Frameworks aren’t an excuse to stop thinking and questioning.

Scaled frameworks are embedded in broader systems. Questions can arise when working out how this framework interacts with other frameworks or the reality of the environment that it’s operating in.

Pick your frameworks and processes similarly to how you’d pick a technology stack. Technology is essentially a set of assumptions and processes embedded in a product. And when you apply that technology, it’s part of a larger business process and customer experience.

Routines, shared mental models, and questions are needed to scale agile:

  • Routines set a regular rhythm and cadence for work to occur, and align the activities of multiple people.
  • Shared mental models of the system you’re operating in and improving help to avoid bounded rationality and improve communication with a shared vocabulary.
  • And questions keep you from becoming complacent or sticking with frameworks that don’t serve you.

 

I’m not saying that all existing scaling frameworks are perfect or that they make sense for every setting. That’s why this blog covers a mix of frameworks, mindsets, and the science behind it all.

My point is that we need to look a layer beneath the reaction of “this seems too complicated” or “let’s implement this framework as-is” or “this framework is the best for everyone.” We need to really question the role that each element we’re advocating for or against plays. Designing how we work is just like any other engineering or design problem.

 

What’s your take on frameworks? Do you gravitate toward simpler or more detailed ones? When? Why?

Share your thoughts