Agile Zone is brought to you in partnership with:

Jim Highsmith is an executive consultant at ThoughtWorks, Inc. He has 30-plus years experience as an IT manager, product manager, project manager, consultant, and software developer. Jim is the author of Agile Project Management: Creating Innovative Products, Addis Wesley 2004; Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House 2000 and winner of the prestigious Jolt Award, and Agile Software Development Ecosystems, Addison Wesley 2002. Jim is also the recipient of the 2005 international Stevens Award. Jim is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

The Ambidextrous Organization

  • submit to reddit
The Agile community has struggled to find a model for transforming large organizations to an Agile approach to software delivery and face a more daunting struggle in striving towards enterprise agility. Should we strive to convert everyone in a large organization to Agile? If not, what parts should be converted and which left to their traditional mode? If there is a partial conversion will part of the organization feel as if it’s second class—not on the cutting edge? If the converted piece of the organization is too small, doesn’t it face the organizational antibodies undoing the transformation?

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, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)