The Ambidextrous Organization
Join the DZone community and get the full member experience.Join For Free
These are all organizational questions that have been considered as big organizations have tried to “go Agile.” I recently read several articles about an organizational concept called the Ambidextrous Organization, written about in a Harvard Business Review article in 2004. The authors define two types of initiatives—exploitive ones that focus on the present and exploring ones that focus on the future. I’ve used the words efficiency and responsiveness to describe these types of initiatives.
As we know, the cultures for these two types of endeavors are very different and therefore cause problems in transformational efforts. One historical solution to this problem was to establish a “skunk works,” a separate small group that operated outside normal organization boundaries, processes and procedures. The problem with these groups is that they were often too small and not supported by other parts of the organization. For example, a “rouge” software development group might use Agile methods for a project or two, but not be supported by product management, operations, or the data base management group. Similarly, a separate new product organization might not be adequately supported by manufacturing or sales.
As shown in the figure, the ambidextrous approach focuses on setting up a separate organization—with all necessary functional units within it—and connected to the larger organization at the executive level. In the author’s studies over 90% of the companies that used an ambidextrous approach met their goals. The exploring organization has enough resources to go to market without help from the exploitive part of the organization. It is a separate business unit that can create different processes and grow a different culture.
This dual organizational structure may have a place in certain Agile transformations, particularly in very large organizations that have a need to balance both exploitive and exploring initiatives. It could also be used as an early Agile transformation strategy, beyond the more common strategy of just building from one to several Agile teams. The Agile team building strategy often runs into problems because it doesn’t involve enough other functional groups and the Agile teams become isolated, and discouraged. There are some downsides to this approach, but it is worth investigating for your Agile transformation.
Published at DZone with permission of Jim Highsmith, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Transactional Outbox Patterns Step by Step With Spring and Kotlin
Operator Overloading in Java
DevOps Midwest: A Community Event Full of DevSecOps Best Practices
What Is Istio Service Mesh?