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:
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.
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.
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
This is not to say that all reorgs are bad; it's just that we probably need to be more careful in our use of this management tool:
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.
Determine how much of a new structure is required. If a change is required, can we minimize the “blast radius” of the change by:
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.
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.
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.