Elusive Enterprise Agility

Michael Cote’ posted an interesting discussion about the difficulty in scaling agile to the enterprise in “Dysfunctional Agile, Agile-in-the-Large“.

In his discussion, Cote’ indicates that agile has been solved for the team, but is still an open question when applied in the large. I would argue that this is true for any process, not just agile. By definition, a process simply describes the procedures by which software (in this case) is created. By changing process, you are simply changing the behaviors (the way things are done) of the system. A process takes inputs, applies methods, and creates outputs. Agile processes include tight feedback loops which help with ill-defined inputs.

All processes can be quite elusive in larger organizations. The difficulty is that the larger an organization becomes, the more organizational structure is created to support its own weight, and the more communication paths are created to navigate that structure. Organizational structures define the roles, responsibilities, teams, departments, divisions etc. within the organization. A process is dependent on the organizational structures because it defines many of the bounds of communication, responsibilities of individual workers and teams, alignment to products and solutions, ownership of development and support, etc.

Waterfall “solved” this alignment problem by separating each phase with an organizational structure to support that phase – product management, development, test, documentation, support, etc. It localized communication intensity to each function to optimize them. However, we all know what happens between functions. Many organizations are still aligned to this structure – some of which are attempting agile transitions (possibly unsuccessfully).

Agile processes have not attempted to solve the enterprise whole-organization directly. Scrum comes closest in identifying key roles responsible for a team, but fails to extend these role definitions out through the organization other than to identify a Scrum of Scrums model. Scrum has also recognized that organizational impediments do exist and provide a process for identifying them.

But how do we resolve organizational impediments and poorly-aligned organizational structures that are limiting our success with agile or possibly causing it to fail? Better yet, how do we even identify the right solutions? It is relatively easy to identify the symptoms and surface problems, but very difficult determine a solution. And once a solution is identified, it is a political landmine field to implement because it means that someone is going to lose some power and someone else will gain power.

I have found that you have to start below the process – at the organizational structures. Before you can effectively scale an agile process, you must first evaluate and optimize the organizational structures. While there are a number of organizational analysis techniques, James Coplien and Neil Harrison, in their book Organizational Patterns of Agile Software Development, provide a very simple approach to recognizing the true structure of an organization and have also done the homework to distill effective structures into organizational patterns that we can leverage and apply within our organizations. I have found their techniques and patterns to be quite effective in the larger organizations that I have worked with to help us acheive successful results scaling agile.

I would be interested in hearing other approaches to achieve successful enterprise-level agile adoption. What has your organization done?

< Back to Blog Listing