Blog

Pros and Cons of Centralized and Decentralized Transformations

By: Agile Velocity | Jan 13, 2022 |  Agile Transformation,  Business Agility,  Process

An image of small sections connected together to form a large structure, similar to the way information flows through an organization during an Agile transformation and influences the larger strategy.Autonomy with Alignment: Effective Approaches for Transformations

If your organization is planning an Agile transformation, you may be asking, or be expected to answer, the question of whether to take a centralized or decentralized approach.  Centralizing suggests assigning ownership and control to one or a few, while decentralizing means distributing responsibility and ownership to a broad group of people.

I wish I could definitively answer the question. An ardent agilist may reflexively lean toward a decentralized approach. Having been a part of many transformations over the years, I know it’s just not that simple. It got me thinking of how to respond to this from a pros and cons perspective. In sharing this topic with my Agile Velocity colleagues, who all have experience in this area, a more nuanced conversation emerged. 

The reality is that it depends on a variety of factors, many of which you may not be able to thoroughly understand until you actually get started. 

Where to begin 

There are many challenges to be considered when embarking on an Agile transformation. Why are we doing this? Do we go with a ‘big bang’ approach or start with a small pilot?  Do we centralize control and define best practices for everyone to follow?  Who’s in charge?  Do we have the expertise to take this on?  

The uncertainty and ambiguity of how to get started may be an impediment or it may be an opportunity. The first principle of Kanban, “Start with what you know”, can be a helpful reminder to begin with. What does your current organization structure and culture require? 

I think it’s important to make sure your approach aligns with your current organizational norms, at least initially, rather than trying to force something that might generate more friction and stress. As the transformation evolves, your approach will likely need to evolve.  

Starting with a centralized approach may fit the needs of an organization that has a strong orientation on stability and control. A decentralized approach may fit an organization that favors individuality and flexibility. 

Most Agile transformations have traditionally been IT specific initiatives. This may limit the transformation to just being applied to software teams or lacking alignment with business objectives and outcomes. Some may be centralized through a Program or Project Management Office (PMO). These may be beneficial in providing structure and clear ‘ownership’, but may also result in ‘doing’ agile or being too process focused.  

A decentralized approach may imply a grass-roots effort or an organically evolving approach.  This can work well to build foundational value and can generate some initial ground-level improvements. However, this often means there is no core leadership or guiding coalition, so it results in ‘pocket agility’ with localized benefits and incoherent practices and processes that are hard to sustain or optimize.  

In addition to the existing hierarchical structure, management philosophy and the current cultural profile, the size or scale of the organization and scope of the transformation are also big factors to consider. What is needed to support the pace of change or the growth factor if we’re transforming across multiple groups or business units?  

Breaking down some Pros and Cons  

One could argue that any transformation effort of significant scale may benefit from having some centralized controls, coordination, and execution. Dealing with agile at scale may require a certain set of practices that need to be put in place.  A smaller organization may have people wearing multiple hats, and the constraints of people’s bandwidth may force one approach over another. Centralizing may mean the burden falls on the shoulders of just a few, or one. Regardless of scale, having a centralized communication strategy and pool of knowledge can help with learning and dampen the anxiety that often accompanies early-stage transformations if people are lacking information.  

For every transformation, we strongly recommend the formation of a powerful guiding coalition, we refer to this as the Agile Leadership Team (ALT), who can help drive the transformation, foster feedback loops, and remove organizational impediments. Most transformations will have a single, central ALT, while in a few very large transformations there may be multiple ALTs across the enterprise. An ALT doesn’t solely ‘own’ or control the transformation, but they do guide the transformation blending strategic clarity and alignment with tactical coherence and energy needed to sustain the change.  

Centralized management of a transformation may also carry the risk of creating an “us versus them” divide where those ‘in charge’ are deemed to be forcing agile on the organization, with others being held to execute the plan or process. Centralization may feel disempowering and is often slow and bureaucratic. Conversely, decentralization can give more people a bigger stake in the transformation, it can often turn into the shotgun approach where every team is doing things a little differently, tooling is mixed, and metrics are inconsistent or non-existent. 

For many traditional hierarchical organizations, with a need for control, a centralized approach translates into the transformation being treated as a project that has to be managed per a process and has a definitive start and end. It could also result in top-down governance and enforcement, with the focus being more on ‘doing’ and not ‘being’ agile. There have been many examples where attempts to standardize ways of working across disparate situations – e.g. “Everyone must do Scrum” or “Story points need to be normalized across all teams” – end up creating a host of antipatterns and anti-agile behaviors.  

Continuous Improvement is a core pillar of agile and lean but it can get lost in the chaos and stresses of a challenging transformation. Building a Culture of Learning is a key outcome that we advocate for with our engagements.  Taking a decentralized approach may promote more experimentation and ownership of learning. The overall cycle time of experimentation and learning may be shortened with less centralized committee approvals. Cross-fertilization of ideas from that learning can catalyze and expand improvements and innovation. 

Communities of Practice (CoPs) or Center of Excellence (CoE) are vital forums for learning and improvement. Both serve similar purposes and provide a balance of decentralized and centralized support. I tend to think of CoPs being less formal, more organic, providing a decentralized forum for sharing information and experiences that is open to anyone interested. CoEs are often more formal, having named committee members and may even be built into the organizational structure. These can be valuable for aggregating standards and practices where appropriate and providing long-term focus for large enterprises. A central Lean/Agile CoE may be a guiding coalition, of sorts, in service to CoPs that are distributed across different groups or roles and reducing the risk of knowledge silos. 

Pull models are a great manifestation of decentralization. We’ve learned that creating and optimizing a pull system is much better than a push model – e.g. allowing systems of teams to organize around value flow or teams to decide what they work on next versus assigning projects to teams or work to individuals. While this is becoming fairly standard practice with agile teams, it often does not get translated effectively at the enterprise or overall transformation level. 

Cultural Awareness and impact 

Peter Drucker famously said “Culture eats Strategy for breakfast”.  If so, agile transformations are a virtual smorgasbord. The very paradoxical challenge of shifting our way of working and thinking, as an organization, while trying to manage a seemingly increasing volume of demand, is evidenced by the few number of organizations that breakthrough the failed attempts or superficial success to see sustainable change and organizational agility.  

There are two models I frequently reference when relating to Culture in my coaching: 

  1. Pyramid of Results (Partners in Leadership) 
  2. Competing Values Framework (Cameron and Quinn) 

These two models combine to provide a simple way to begin creating cultural awareness and help provide a frame of reference for transformation leadership, including when and where to rely on centralized or decentralized models. As referenced above, knowing where to begin depends, in part, on knowing where the organization stands today as well as where it might evolve to in the future.  

Centralized approaches often translate into managing and dictating processes, practices, and resources. This may result in the false belief that we can simply manage our way to specific results. The reality is that bringing about change requires leadership to foster an environment where people can experiment and explore that leads to giving them new experiences. These new experiences can reshape the belief systems and behaviors that ultimately drive new actions and related results.

This all translates to a form of decentralization, since experiences are very localized to the team and individual level. As changes begin to take shape and patterns emerge that provide empirical evidence of the results that matter, we can, in some cases, create a unified, central understanding that can then permeate the broader organization. Where we see results that relate to clear or complicated domains, we can form some best or good practices. Centralizing these in some form might make sense.  

The Competing Values Framework (CVF) is an excellent model to understand the relationship between cultural profiles, leadership, and change within an organization. Attempting to apply Agile–either centralized or decentralized–that is misaligned with the cultural profile or leadership style of an organization will create more resistance and chaos. 

An image of Robert E. Quinn and Kim S. Cameron's four types of culture: Clan culture, Hierarchy culture, Market culture, and Adhocracy culture

A decentralized approach emphasizes distributed decision-making and more innovation, which are characteristics of an organization that favors individuality and flexibility. A centralized approach aligns with a preference for top-down control and risk-aversion, characteristic of an organization that has a strong orientation on stability and control.

A centralized approach may be good for establishing needed structures, policies, and metrics. 

This could result in an ‘outside-in’ approach that feels like something being enforced on the organization and team. With proper cultural awareness and leadership mindset, it could also be used to shift to an ‘inside-out’ approach, effectively decentralizing decisions for structure, policies and metrics to the teams, and accelerating the transformation in some areas. This helps to create an evolving, better aligned transformation path rather than one that is pre-defined or enforced based on prescription. With respect to culture, parsing through the pros or cons of a particular approach requires an awareness of current norms and what the culture will support as well as what will enable a positive shift or result in a negative reaction. 

Organizational Structure Implications  

Taking on an Agile transformation inevitably confronts the impacts on the organizational structure. Traditional organizational design is intended to provide a level of control and ostensibly order. However, information and value tend to flow across hierarchical boundaries and silos. If the hierarchy is based on functional roles, then that creates some friction when confronted with creating cross-functional, product-aligned teams. 

To truly transform with Agile or Lean we need to align on and address the underlying questions of how the organization is designed today as well as what it may look like in the future. 

    • Does the current organizational structure enable or impede free flowing information and learning? 
    • Are people able to dynamically form teams or working groups freely or does it require a committee or governance process? 
    • Is the organization able to scale effectively in order to respond to market demands? 

The most common and immediate organizational structure challenge is at the team level. Agile and Scrum principles encourage cross-functional, self-organizing teams. Most coaches lead with this refrain. As obvious as this may be, it is often an immediate source of resistance.  

Even though we’ve been proving the value of this team structure for over two decades, it’s amazing how many organizations are still bound by single function or skill specific teams. 

But it’s not just a matter of restructuring teams. We need to consider organizational design as a multidimensional challenge. One of those dimensions is to view the organization in 3 levels – Organization, System, and Team. We can make the case that there may be different contexts for centralization and decentralization at each level.  

Centralize an Agile transformation at the org and system level and decentralized at the team level.

At the Org level we include Leadership, overall organizational structure, lines of business, etc. At this level, having a centralized way of aligning the Vision and Strategy, addressing overall communications, and allocation of budgets and other resources makes sense. 

At the System level, we’re dealing with value streams, teams-of-teams, programs, and middle management. This level is where we need a blend of strategic and tactical focus. Centralizing some elements of a major transformation can provide the scaffolding for safe experimentation, learning and scaling. Dealing with dependencies across teams or even across value streams likely means having to distribute decision-making and problem-solving so as not to create unnecessary bottlenecks. 

The Team level, as mentioned earlier, is obvious for most agilists. Empowering self-organizing teams equals decentralizing authority, skills, knowledge, etc. But you might be concerned that autonomy equals anarchy. We can maintain a light hierarchy from a leadership perspective but restructure the way teams interact and collaborate to enable value delivery. The structure, leadership styles, and mindsets are related but independent. However, this does require managers and leaders to rethink their role in the hierarchical structure.   

There is also the matter of being geographically centralized or distributed. The trend continues and has accelerated for most companies to be geographically distributed to some extent. Agile Velocity is no different. We have folks spread far and wide, like virtually all of our clients. So we know first-hand the necessity and challenge of figuring out when and where to centralize or decentralize in order to meet the demands we face.  

In addition to the question of changing the structure, we also may need to add new structures to the organization to enable a sustainable transformation. The first step for our approach is to create a guiding coalition, as John Kotter suggests in his 8 Steps for Organizational Change. As mentioned above a successful transformation depends on creating an Agile Leadership Team (ALT) in addition to CoEs and/or CoPs. If these structures are new to the organization they may take time to evolve and norm. These groups definitely need to transcend organizational silos or hierarchical boundaries to form a network that amplifies feedback and learning. Trying to contain these within a pre-existing or centralized structure will surely limit the success of a transformation.

Observe and learn, inspect and adapt  

So, the answer to the question of “should we take a centralized or decentralized approach for our Agile transformation?” is… “Both”.  A better framing of this question or topic may be – How do we balance autonomy with alignment for an effective transformation? 

My colleague Andy Cleff came up with the “user story” – As a leader, I would like to understand how I can best influence my organization to change the way we do things so that I can help support the revolution. Which leads to the following questions: Are you seeing your transformation as a top-down, follow the leader initiative, or is it a grassroots movement? Both can exist at the same time, but each may have separate needs for centralization versus decentralization. 

Taking a balanced, pragmatic approach and recognizing where centralization makes sense and where decentralizing makes sense, can dramatically increase the chances of transformation success over any unilateral approach. One of the universal failure patterns we’ve seen over the years is that organizations attempt to “implement agile” and seek best practices as some easy-button approach. But the reality for most organizations is that there’s a mix of clear, complicated, complex, and chaotic conditions we have to deal with. 

You’ve probably heard, or said yourself, “Agile is simple, but it’s not easy”. One of my personal, and over used, clichés has been “Agile is not a silver bullet. It’s more of a spotlight”. Meaning it won’t solve organizational dysfunctions but it sure will highlight them. An Agile transformation tends to bring out some of the messiness in our organizations.  

Deciding whether or how to centralize or decentralize some or all of a transformation starts with aligning on why you’re taking this on in the first place. What is your compelling purpose and what outcome are you trying to achieve? There is a distinction between alignment and coherence. We need alignment upfront, but as we begin to navigate the transformation we may have a need for divergent approaches. There may be different paths we can take. What matters more than control or uniformity is that we see coherence in the decision making that gives us evidence and confidence that we’re working toward the same outcome. 

Communications and active feedback loops are a good example of this. I visualize it as a mindmap or an hourglass shape with multiple sources and channels for receiving and disseminating information and feedback about the transformation. 

An example of a mindmap with multiple sources and channels for receiving and disseminating information and feedback about the transformation.

I find it helpful to have a centralized strategy and hub model for communications, without restricting or choking it, that can then support creating decentralized mechanisms for gathering data and measuring progress. 

There’s also the reality that, depending on the characteristics of your organization and the transformation itself, there are different stages to a transformation and the decision to centralize or decentralize something may depend on where we are in our transformation journey. Another dimension to Path to Agility®, is the recognition of the relative stage of the transformation, which we have defined as Align, Learn, Predict, Accelerate and Adapt. 

I tend to refer to these more as relative ‘states’ than stages, because there may be different states of transformation progress across the organization. There may be some groups or teams that are further along on their journey, while others are just getting started.  

The 5 stages of an Agile transformation outlined on the Path to Agility.

Understanding the overall stage of transformation and relative state of the various groups or teams involved can enable centralization of the overall, enterprise level transformation with decentralized execution based on the context of the participating groups. 

Regardless of whether the initiation was a “shotgun” approach or a “wave” approach, the reality is that different groups/teams may be at different stages of their transformation journey.  Being able to see and respond to that is critical and will be made easier by having a balance of centralized and decentralized approaches and views. 

So, we use agile thinking, and models like PDCA or OODA Loop, to observe, learn, and adapt to what’s working or not working.   

I want to acknowledge and appreciate Andy Cleff, Marc Story, Claudia Orozco, Jonathan Schneider, and Mike Caddell for contributing their experiences and insights for this topic.  I had the pleasure recently to participate in a panel discussion hosted by the Agile Uprising podcast with this esteemed group of agilists. It was a great conversation and provided some real nuggets of wisdom that helped me round out my thinking on this topic. I encourage you to check out the podcast. 

References:

  • John Kotter – https://www.kotterinc.com/8-step-process-for-leading-change/
  • Partners in Leadership, Pyramid of Results – https://www.partnersinleadership.com/we-want-to-be-your-partner/ebrochure/models.html
  • Cameron and Quinn, Competing Values Framework – https://www.quinnassociation.com/en/culture_typology 
  • Dave Snowden, Cynefin Framework – https://thecynefin.co/about-us/about-cynefin-framework/
  • Path to Agility – https://pathtoagility.com/  
  • Agile Uprising – https://www.agileuprising.com/

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back