Should I Put Re-organization Plans on Hold?

Join the Discussion

Provide Feedback

Agile and Lean transformation compels profound and often unexpected changes to an organization. If you carry out other re-organization plans at the same time that you are undergoing this transformation, you will dilute the benefits of Agile and Lean, complicate and prolong the timeline for their adoption, and set up unnecessary conflicts.

Main Points

  • Agile and Lean have profound organizational effects.
  • It is hard to predict the exact timing of these changes.
  • The form may look similar across organizations, at the most general level, but the proverbial devil is in the details.

Agile and Lean are Your Next Re-Org Plan

There has not been a successful transformation of an organization to adopt Agile and Lean that did not compel substantial changes to responsibilities, roles, processes, reporting arrangements, and culture. Therefore, Agile and Lean are not just the next corporate initiative that you can juggle alongside other organizational changes. If you have plans to re-organize for other reasons, best to put those plans on hold.

Take, for example, the question of team stability and composition. In many organizations, employees split their time among multiple projects. Agile puts that arrangement at an end: to get the maximum benefit, most employees (with the exception of people who make infrequent contributions) need to dedicate themselves full-time to a team. It will take time for people in an organization habituated to project-juggling to learn why this dedicated effort is important. They might arrive at compromises, such as Scrum Masters or product owners who split their time between a couple of teams. It will take additional time to figure out whether these compromises are tenable or desirable.

Similarly, team composition requires an ongoing investigation and experimentation. For a complex product or project, is it better to have, say, an admittedly larger-than-normal team of 18 people, or two smaller teams? For a very large project, should the teams be purely cross-functional, or is there an argument for keeping some shared services, such as database development or UX design, as a separate group? While there are answers to these questions that work in most cases (for example, cross-functional teams are almost always a good idea), they may not work for a particular team or project.

The examples given above are just a small slice of the organizational questions that arise during Agile and Lean transformation. Thus far, we have only spoken about the team, but the value stream must change, too. Operations must prepare for more frequent and smaller releases. Internal customers of IT teams have to dedicate more time, on a regular basis, for feedback, instead of waiting for the big acceptance test jamboree at the end of a project. Product managers have to become very precise about the rationale behind including particular capabilities in the next release.


Given the scale of these changes, and the time required to work your way through them, running a parallel re-organization effort simultaneously puts both efforts at risk. Not only are you distracting from and putting constraints on the Agile and Lean transformation, but you are also pitting the Agile and Lean changes against whatever you hope to achieve from the other re-organization. Therefore, we strongly advise that you put other re-organization plans on hold, at least for the first year of any Agile or Lean adoption.