Why the Dual Operating Model Impedes Enterprise Agility

It is a popular trope that most organizations will adopt a "dual" approach to agility, with some parts of the organization working in an agile/empirical way that delivers value in small increments, measures the response, and adapts accordingly, while the "traditional" organization continues to work as it always has, in a relatively top-down, plan-driven way. In this model, the two organizations remain relatively separate, with interactions only at key touch-points; the agile organization acts, in many ways, like a wholly-owned but relatively independent subsidiary. This model is perhaps best described by management guru John Kotter in his Harvard Business Review article Accelerate! and is depicted in Figure 1.

Figure 1: The Dual Operating Model, as described by Kotter

Agile sub-organizations working within a traditional organization have special challenges, including building an empirically-driven culture, creating and empowering self-managing teams, and nurturing their nascent way of working. We have previously described how an organization can set up an agile "cell" within a larger traditional organism.

While the dual operating model approach is essential when an organization is just getting started trying out an agile approach, it eventually must be left behind, and sooner than most organizations think. Once an agile organization hits its stride, it will constantly chafe against the constraints imposed by the traditional organization. If agility is to thrive, the entire organization needs to embrace agility, not treat it like a special case only for some hyper-competitive segments of its business.

What is agility?

Some organizations confuse a particular approach to agility (such as Scrum) with agility itself. They focus on specific roles or events or artifacts, and say things like "you will never get the lawyers in our legal department to hold a Daily Scrum" for example. That isn’t really true, because we know that some lawyers working on a big case actually do use techniques very much like a Daily Scrum, but that’s beside the point. The true essence of agility is:

• a self-managing team delivers value in small increments (or at least what they think is valuable),
• they measure whether what they delivered really was valuable,
• and they inspect the result and adapt their next delivery based on what they learned.

A lot of organizations who think they are being agile really aren’t, because while they deliver in small increments, they never measure the result. Inspecting and adapting is essential to an agile approach; it’s what helps the organization improve their ability to deliver value. An organization that is not doing this is probably simply producing waste at a faster rate.

What is value?

Value is an improvement in an experience that customers value enough to be willing to pay for, either monetarily or with their time. It is not increasing ROI, EPS, or revenue, although those things usually increase when customer experiences improve, because there are many ways to increase ROI and other aggregate measures that don’t improve customer experiences (think about how easy it is to game ROI or EPS in ways that will actually make customers less happy.)

Traditional and agile approaches approach value in very different, even incompatible, ways. The traditional organization assumes that it knows what customers want. It has "experts" who can describe what teams need to deliver to customers for them to experience value. Teams simply need to deliver those things as completely, efficiently, and quickly as possible. Traditional organizations don’t feel the need to measure the value that customers experience because their "experts" have deep knowledge of customers. As a result, a traditional organization focuses on creating plans for the work that needs to be done to deliver value, and measuring the effectiveness with which those plans are executed.

The problem is that if and when these organizations measure the value that customers actually experience, they find that much of what they delivered to customers was, in fact, of little value. In short, the "experts" can’t effectively predict what customers find valuable, perhaps because customers or markets are changing too fast, or perhaps because customers don’t really know what they want or need until they experience it. It’s not the fault of the "experts"; the very idea that there are people who can predict what customers want seems to be wrong.

How is an agile approach different from the traditional approach?

In place of having people who can predict what customers want and then planning around these predictions, teams using agile approaches form small experiments about value and then run them as quickly as they can, with as little investment as they can get by with. These teams adapt their course of action based on what they learn from these experiments by forming new experiments which result in new learning. They never reach a point at which they have learned enough to stop experimenting and start making longer-range plans, because each time they learn something new, they have more questions.  At the same time, some, or maybe even many, of these experiments result in customers experiencing something valuable.

The traditional organization, steeped as they are in their own perceptions of certainty, view the agile approach as wasteful and unnecessary. They simply don’t understand or accept that learning, and therefore experimentation, is necessary. They believe that it is possible to plan for success, and that any deviation from the plan is a sign of failure. This collision of world views, one founded on the belief that certainty is both possible and necessary, and the other based on the idea that we don’t know many of the things we need to know and the only way to learn is to run experiments, leads to tacit conflicts that undermine the organization’s ability to grow their agility.

How does this conflict show itself?

In the traditional organization, waiting for things (or queueing) is the norm: waiting for people to respond to emails, waiting days or weeks for a meeting because that’s the first open time on everyone’s calendar, or waiting for someone else to finish their part of a project so you can start yours. But waiting is death for agile teams; it wastes valuable time and diverts their focus. And when I say "death", I am not exaggerating for effect. Waiting makes agile teams ineffective, and over time it will kill the agile team’s ability to get things done. If an agile team has to wait every time it needs something from the rest of the organization, pretty soon it will act just like any other team. This is one reason why agile teams only seem to work on new initiatives that are completely disconnected from the existing organization: so long as they don’t have to interact with the rest of the organization, so long as they are completely self-contained, they don’t waste time waiting and they can work in an agile way.  But once they need expertise or authority they don’t have, it all starts to fall apart.

The other source of conflict between agile teams and the rest of the organization relates to the way that traditional organizations respond to transparency - they think it’s a great idea until it exposes something that makes them look bad. While agile teams rely on transparency to keep everyone aligned, traditional organizations kill it when it shows that key assumptions that the organization has used to make plans are shown to be incorrect, or when a feature that an important stakeholder insists must be delivered is shown to have no value. Traditional organizations invest a lot of effort in hiding information that might "make someone look bad", rather than using every new piece of information as an opportunity to learn and improve. Unfortunately for the agile team, when their need for transparency confronts the rest of the organization’s need to make itself look as good as possible, the agile team is going to lose. Once this happens, the agile team will abandon transparency and they will lose the ability to inspect and adapt.

Mistaken assumptions about agility limit its potential and, ultimately, its success

Superficially, agile approaches seem to be just processes with different roles, events, and artifacts. Organizations who take this view tend to focus on making sure the agile team is performing all the necessary events in the "right way". The result can become something that we call "Zombie Scrum", in which team members mindlessly stumble through agile events without understanding why, and usually without achieving anything useful.

The distinguishing feature of an agile approach is having a self-managing team that is using empiricism (i.e. experience) to guide its work. Put more bluntly, a team that is delivering in short cycles that never measures the value of what they produce, and never uses what they learn from measuring to adapt their approach is not agile, they are just working faster in a traditional way. The essence of agility is adapting based on feedback.

The "self-managing team" is important. A team that has to present what it learns to managers, who will interpret the data and tell the team what to do, will never be very effective; too much learning is lost in translation and presentation, and too much time elapses between when they learn something and when they take action on that learning. The team can never make up the lost time and lost information, and their performance will suffer. The more the team is self-sufficient and self-directed, the more effective they are at adapting based on new information.

If you doubt this, look at how organizations respond to crises: they bring together a small team with all the right skills and they empower them to act on what they learn. The organization suspends the usual chain-of-command to deal with the emergency. Only when the emergency passes do they revert to their normal management chains. The problem with reverting is that we live in a world of perpetual change that will never revert back to a steady-state. There is never a moment at which we can relax our attention. There is not a single organization that does not need to continually learn and adapt.  

Some other organizations think that innovation need only happen in one area, perhaps in product development, and that the rest of the organization can be run using processes optimized for an unchanging world. But ask yourself what part of the organization does not, in today’s world, need to continually adapt? Customer service? Talent acquisition? Strategy? I could go on, but I cannot think of any part of any organization that is not potentially affected by change in the world. In short, there is not a single part of any organization that does not need to continually learn and adapt.

Mistaken assumptions about scaling limits organizational agility

Most examples we have of large organizations are structured hierarchically into departments, sub-departments, and teams. As a result, most people think that hierarchy is essential to scaling, or growing large. But is it really?

Despite occasional failed attempts by authoritarian governments to control their society and its economy, societies and economies are fundamentally self-organizing. Family units are self-organizing. So are social networks (digital or otherwise). Nearly everything in our lives is "governed" by various informal self-organizing, self-managing systems. Even within most traditional hierarchical organizations, most things get done through informal networks of acquaintances and alliances. The formal hierarchy, even in totalitarian states, is but a thin veneer over the richer network of self-organizing networks that conduct the real work of living.

And, when thrown into a crisis, we seem to recognize that self-management is superior to centralized hierarchical control. Look at how people respond to emergencies such as fire, or flood, or earthquakes, or tsunamis: they band together to help each other and to get things done. They don’t wait for the emergency management authorities to show up and tell them what to do; they just start. And when emergency managers do show up, they are largely augmenting what people are doing for themselves, enhancing and amplifying it, but not taking over and controlling every last detail. Leadership, especially setting effective goals, and helping teams to grow in their ability to self-manage toward those goals, is essential, but management is not.

Organizational hierarchy actually gets in the way of agile response. We often label this problem "bureaucracy", and it emerges anytime someone who is far-removed from the actual situation needs to make a decision. Because they lack first-hand knowledge of the situation, they must be educated about the situation so they can make a decision. Except that no amount of briefings and summaries can provide them with the insights gained first-hand, and all those briefings and summary documents take time to prepare, and time to read. And at every step along the way, some knowledge and insight is lost. The decisions made by far-away decision-makers are typically late, simplistic, and maladapted to the situation on the ground. Decision latency kills responsiveness, and hierarchies are the source of decision latency.

Organizations who believe that they need to adapt their agile approach to their hierarchy have it backwards; what they really need to figure out are ways to break down hierarchy and complexity in order to increase the autonomy and empowerment of their agile teams. Organizations often think that they need the hierarchy to simplify communication networks that they need to build complex products, but hierarchical communication and decision networks are actually the source of the problem, not the solution. Complex hierarchies are often the reason why products are complex and take forever to develop and deliver. Because no one has a complete view of the customer, no one really understands what customers need. The resulting products are muddled messes of features that fail to meet any customer needs and that, once developed, can never be removed because no one understands why they are there to begin with. This is what makes "modernizing" legacy applications so difficult: most of what they do is outdated or useless, but no one knows what parts can be scrapped.

Increase team autonomy to improve your organizational agility

One barrier that can hold organizations back is when they see self-management in binary terms, that a team is either self-managing or it is not. In reality, all teams self-manage to some degree, and few teams are wholly self-managing; self-management is a spectrum, not a yes-or-no proposition. The challenge that agile leaders face is to gradually but purposefully improve the ability of their teams to self-manage by helping the team to take on more responsibility as it is ready to do so. An example of a technique that can help is delegation poker. The important thing is not so much the technique used, but the intent - to help a team understand what it is capable of deciding independently, and to help them grow their capability to make better decisions over time.

Sometimes, leaders need to help to remove organizational and technical impediments to increase team autonomy by making more sweeping changes:

• Change the reward system. Don’t reward individual performance through compensation and promotion. In modern organizations, no one achieves anything strictly on their own; even the smallest achievements require people to collaborate. Recognizing this explicitly, and by rewarding teams rather than individuals sends a powerful message about the importance of collaboration.
• Narrow and focus the scope of products. Products are often complex and confused bundles of functionality with no clear customer focus; they do a lot of things, but for no one in particular. Large, complex products tend to have large complex organizations that make untangling and focusing responsibilities challenging, at best. By breaking complex products into simpler, more focused products that serve a smaller set of customers and their unique outcomes, leaders can help teams to improve their autonomy and achieve better customer focus.
• Create shared services that link products together without creating inter-product dependencies. Shared services help teams by reducing duplication of effort across teams. To avoid creating dependencies on common components, leaders can foster an open-source-like approach where any team can add to a service, while rigorous automated testing prevents them from breaking committed interfaces and service-level agreements. Periodic review and refactoring helps to prevent shared services from becoming bloated and ineffective.
• Empower teams to take on "people development" responsibilities, supported by Communities of Practice. Traditionally, a centralized "human resources" department handles things like career and skills development, and recruiting and staffing. These tasks are actually better handled by teams themselves, who have a better understanding of the skills they need to develop, and the sort of people who will best fit in with the rest of the team. Long-term career development can be augmented by peer mentoring supported through Communities of Practice, since peers are more valuable sources of career advice than HR departments. HR specialists can help teams with recruiting and employment law expertise, but the teams themselves need to own their own membership.

Grow self-management one team at a time

Organizations transitioning from a traditional hierarchical organizational structure to one consisting of loosely-coupled self-managing teams must work team-by-team to gradually transfer accountability for sets of customer outcomes to the teams. As they do, they must shrink the existing organization at the same time (see Figure 2).

Figure 2: Over time, agile organizations must trim their hierarchy by transferring responsibility and authority to self-managing teams

The tricky part of this transition is that management cannot force team membership; self-managing teams must be free to choose their own members. And they must be given time to work through their own issues in coming together as a team.

Conventional wisdom says that there are only some areas of the organization that need the agility that a self-managing team provides, but in practical terms, everything in an organization is connected, and in order for agile teams to be successful, the rest of the organization must serve them and not the other way around.

It is better to think of self-management as something that is not binary, either or, but a capability that different teams will exhibit to differing degrees. The agile leader's challenge is to help teams grow in their ability to self-manage, gradually increasing their autonomy as they prove themselves worthy of the trust the organization is putting in them.

As more teams achieve higher degrees of autonomy, they are able to take on more work, enabling the organization’s senior leaders to transition accountability for more customer outcomes to these teams. As this progresses, there is less and less need for the two different ways of working that the dual operating model implies.

Conclusion

There’s no free lunch; you can’t keep your old organizational structure and culture and get the benefits of an agile way of working. The dual operating model, while unavoidable in the early stages of an organization’s agile transition, eventually becomes a barrier to achieving the benefits of agility. Only by being willing to let go of the old way of working can organizations truly achieve the agile benefits they seek. If you would like to learn more about improving organization agility, our new book, The Professional Agile Leader dives in deeper.