Note: This page is written from the perspective of structuring or restructuring an ART (Train, Program-level) organization. The ideas discussed here can be applied total re-organizations etc. but there will be additional considerations as the discussion scales.

Often times, when leadership looks at their organization, there is a feeling that the way things are structured at the moment is in fact the cause of many of the problems that are being faced by the organization. Leadership naturally is driven to re-structure the organization. However, the process that creates the new structure is often driven less by business needs and evidence-based thought. and more by politics, agendas, and emotion. Further it is treated as a secretive effort, by a small group of people, for fear that it will disrupt current efforts.

There are better ways to address these issues. Firstly, we need to understand that the instant there is a conversation about restructuring, everyone knows that this is happening. It’s as if the Zoom call has been broadcast to the organization, or the walls have ears. The result is that current efforts are already being disrupted, and probably not in a positive way. In the absence of information, rumors will be negative, no matter the intent of leadership. To address this, we need to have a more open, collaborative, and more engaging process.

Secondly, we need to get away from politics and agendas as the primary driver for the restructuring. To do this, we borrow from the thinking around “Wicked Problems” by ensuring we have a clear understanding of the problems we are solving. We start with an overall agreement that we are trying to improve the flow of business value (faster time to market, more per unit time) and then identify the problems that we think are related. We then use this to drive the rest of the discussion.

Thirdly, we need to acknowledge that there is a strong relationship between the way an organization is structured and the architecture of the product. For example, if you establish a set of 3 teams to build a product - one responsible for user interface, one for business logic, one for data - you will also end up with a 3-tiered software architecture no matter what the architectural “design” calls for. This is known as Conways Law. To get the architecture we want we need to apply a Reverse Conway manoeuvre and structure the organization so that it reflects the architecture we need. This means that architects have a huge role in the future structure of the organization. We need to support this thinking with key ideas from organizational design such as Team Topologies.

And finally, we need to work through a collaborative process both to determine what the structure is and to ensure that it is rolled out successfully. The following structure provides a view of the steps you can take to determine and roll out the new structure:

• Start with a view of the problems we are trying to solve based on improving flow of business value e.g.
  • Alignment (“are we all pulling in the same direction?”)
  • Common concern (“do we have to be in this meeting?”)
  • Too much WIP (“we cannot get things done”)
  • Dependency on small group of people (“Jill needs to be in every meeting” or “all work has to flow through the X team to deliver any value”)
  • Not able to complete enough work (“we aren’t getting enough done”)
  • Not able to make and meet commitments (“nobody trusts us to deliver”)
• Review current structure
  • Understand how business value maps to systems we have which in turn maps to teams (people) doing the work
• Develop possible structures to address these, based on core principles e.g.
  • Team Topologies to align structures to the flow of value and based on standard team archetypes and operational approach
  • Dunbars number to determine max size of Teams, trains (ARTs), etc.
  • Conways Law and the Reverse Conway maneuver to ensure organization reflects architecture we want
  • Distributed Teams to ensure effective use of remote operations
• What data do we need to have before making a decision e.g.
  • Dependency tracking to understand impact on flow
  • Capacity allocation to understand use of capacity
• Rank / rate each proposed structure vs problems we are addressing to determine experimental structure we will try
• Roll out new structure
  • Develop experiment(s) we are tracking
    • Use experiments and background above to help people understand the reason for the change, and the expectations
  • Steps for communication including
    • How teams are engaged in the implementation of the new process
      • Do not just hand down a result from “on high”
    • Not just what new structure is, but also how people are expected to work within this new structure
      • Do not leave this as “an exercise for our people”

• What is the Impact of a Reorg on an Agile Transformation?
• What are the Steps in a Value Stream Identification Workshop?
• What Is The Difference Between Value Stream Identification (VSID) and Value Stream Mapping (VSM)?
• Key concepts of Team Topologies