Over my past few engagements I’ve noticed that the days of greenfield agile transformations are gone. I am increasingly seeing organizations where this is not the first or even second move to agile. But, for whatever reason, the results have not been what the organization expected and so the next round of “Agile transformation” is created.

To me this is a problem; we need to be asking why it is that so many Agile implementations are not producing the results expected. At the risk of sounding simplistic, I’ve come to believe that one key reason the Agile implementation fails to meet expectations is that organizations often reorganize multiple times as they are also expecting people to adopt new ways of working.

In many ways a reorg could be seen as the biggest impediment to sustaining an Agile transformation.

The reason for this is is straight-forward - a reorganization has a number of negative impacts on the Agile transformation:

1. The negative impact of fear. As the reorganization rolls out, the pervasive emotion of the people affected, either directly or indirectly, is fear. People worry about potential loss of job, loss of position, loss of status, and loss of all the relationships they have built up. To move to the new ways of working expected as a result of an Agile transformation people need to be able to experiment, to try things out, to fail, to learn. All of this is impossible when fear is the driving emotion. Instead people’s reaction will be the opposite of this; they will work to protect themselves and revert back to ways of working that have proven to be “safe” in the past.
2. The negative impact of the new structure. There is often a pendulum effect associated with reorgs. Today’s reorg might be about “centralization”; tomorrows is about “decentralization”; and then back again. The seeds of the next reorg are effectively being sown with this reorg. While it looks like something is “being done” to improve, what is not being addressed is the root problem that the organization is trying to solve.
3. The negative impact of being forced to change. Reorgs are often thrust on the organization. Rumors spread about the reorg, while management decide on the new structure, mostly in secret. When revealed, people are expected to work through the new approach. The reality is that there is a period of purgatory where people try to work through the changes. Capacity that could be focused on bringing value to market is lost while people work through the change. And since the change often affects the whole organization, the loss of capacity is significant, and unrecoverable. Worse since the change is thrust on the organization, while management will see compliance, they will typically see a reduction in engagement from their people - not something we want to see with our people.

Or as Charlton Ogburn states:

Reorgs are … a wonderful method for creating the illusion of progress while producing confusion, inefficiency, and demoralization

The above discussion is really about the general impacts of a reorg. Specific impacts that I've see with Agile transformations include:

• Competing or different visions of Agile, resulting in almost a religious stance from the coaches involved, rather than focusing on the business need to flow value.
• Leadership need to be “seen” to be doing something different, and agile is associated with the old regime and so needs to be reworked.
• Scarce leadership / management focus and attention moves to the reorg rather than the implementation of Agile
• Since Agile is “new” thing that we are working, when we lose attention on Agile, backsliding happens, as people fall back on existing and familiar behaviors; it is seen as safe behavior with the message that the “new behaviors didn’t last long here”.
• Agile is about transparency and in many ways a reorg encourages the opposite reaction - people want to hide in order to ensure changes don’t effect them adversely
• Specifics about decision making, roles, etc. are left as an “exercise for lower level management” resulting in confusion
• Perhaps the biggest impact is that re-org not aligned with ability to delivery value. The reorg often happens through pressure to solve a problem, with specifics of the implementation the result of politics, rather than focusing on improving how flow value to the customer

At the risk of sounding a little snarky one question I have is, and would love to ask prior to my involvement in the next reorg, is “what was the result of the last reorg - did it meet its goals and result in a positive substantial change?” To put it simply, I do not remember ever seeing a report card for any reorg. The loss of capacity, engagement, and so on are significant negatives. We need to be disciplined about ensuring the feedback cycle before moving on to the next reorg.

This is not to say that all reorgs are bad; it's just that we probably need to be more careful in out use of this management tool:

1. Determine whether a new structure is required. For example, you can leverage the idea of a “virtual” organization (teams, multi-teams, portfolio, etc.) so that no change in reporting structure is required. A number of Agile implementations I’ve worked on created, for example, virtual cross-functional teams and multi-team structures, producing profound changes in business outcomes while reducing the downside consequences of a reorg.
2. Determine how much of a new structure is required. If a change is required, can we minimize the “blast radius” of the change by:
   1. Applying lean-agile principles to the reorg. For example, based on the business outcome we are trying to address we could work toward a “minimal viable impact” of the reorg. Don’t change everything! Keep the things that are working well. Experiment.
   2. Leveraging organizational lean-agile organizational design tools to increase the chances that there will be an improvement as a result of the change. For example, line up the work in relationship to the value stream of the organization, incorporate an understanding of Conway's Law in the structure, understand the impact of changing team cognitive load as you work on your new design, leverage Organizational Network Analysis to really understand how work is done, and leverage tools like a Design Structure Matrix to understand impact of interdependencies in the system and reduce complexity.
3. Reduce fear and increase engagement in the change. Apply lean change management principles so that people can engage more effectively in the change. For example, allow people in the organization to co-create the new organization by providing input into the process before the final step. Specifically talk about impacts on things like psychological safety, expectations as a result of the change, changing roles and responsibilities, and the changing dynamics associated with decision making. At a minimum, make sure discussions about what is going to happen happen at all levels and that there is meaningful two-way discussion.

The bottom line is that reorgs, while common, are a pretty blunt instrument to use in our quest for improved business outcomes. This does not mean they are not necessary, but we can often get better outcomes, less invasively, by working the change through the Agile transformation.

• Original Blog Post
• HBR on Getting Reorgs Right
• Book: Lean Change Management - Jason Little