Scaling Agile seems to be a hot topic at the moment. A number of people are suggesting that “Agile doesn’t Scale”. They are right and they are wrong.

First, lets clarify what I mean by Scaling Agile. Scaling Agile does not mean a large organisation where all the teams use Scrum or Kanban. It means that the entire organisation is using Agile… The usual suspects of Development, Testing, Product Management, but also Finance, Marketing, Operations and Management. Scaling means that as an organisation grows in its use of Agile, it can do so fairly smoothly.

The “Agile doesn’t Scale” crowd are right!

Dave Snowden says that you cannot scale Agile using Recipes, you need Chefs. You need people who have done their apprenticeship for several years and studied the material. I agree with Dave. You need Chefs to Scale Agile. People with years of experience in Agile who understand the theory and principles. However, that is not enough. You also need people who understand organisations rather than development teams. People who have years of experience which involves understanding management, finance, operations and marketing.

The Chefs exist but there not that many of them about. A number of them are helping organisations to Scale. It will not be possible to determine whether they have successfully scaled Agile in a way that is sustainable for a few years. ( I remember a few years ago an Investment Bank in London had an entire department that was Agile but it did not survive for more than a couple of years as the developers had not incorporated the business analysts )

In order for the claim “Agile Scales” to be valid, we need a set of patterns or recipes that people can use without the need for a Chef.

Those recipes do not exist yet. So the “Agile does not scale” crowd are correct.

The “Agile doesn’t Scale” are wrong!

After the Chefs have scaled agile a number of times, it will be possible to examine their stories of success and failure to extract patterns for scaling Agile. It will not happen for a few years as it is necessary to establish whether the patterns are stable in the organisation, or whether they need the support of a powerful manager to ensure their success.

Even though the recipes do not exist yet, they will start to emerge over the coming years. So the “Agile does scale” crowd are correct as well.

You never know, some of the patterns in the Safe framework may turn out to be valid. (So far, listening to stories of people scaling Agile, you need to scale using the product management function who work on a single enterprise level backlog, with a development/testing group that has staff liquidity).

DISCLAIMER: These ideas are not fully formed. Please be gentle. 😉

For the past decade or so I have “known” that “Command AND Control” is the wrong way to run a team or organisation. To me, this meant that Commanding or Controlling was wrong wrong wrong.

I’ve recently been doing some work scaling Agile in the organisation. The role of management or executives is key. They are responsible for focusing the organisation. To ensure that its precious resources are focused in the right place. Some executives do the number crunching in their own heads, other distribute the cognition (self organisation) and some just make it up based on gut instinct. The decision of “what to do?” uses resources from across the organisation, marketing provide market intelligence, and development/operations determine what is possible. Once the decision is made, the executives need to ensure the organisation focuses on it.

There are two ways that the executive can instruct the organisation. They can “Command it” by setting it a set of goals, or they can “Control it” by organising it in such a way that it can be controlled from the top as the executive makes course corrections.

The Marines are an example of a “Command” organisation. The marines are given a clear objective such as “Secure that bridge” or “Destroy that factory”. One individual in the marines can make the difference. In order to do this, the marines are highly trained in a number of different disciplines so that they can “Adapt and Improvise”. A classic example in the business world is Jack Welch’s command to GE “Be the first or second in each market, otherwise exit the market”.

The infantry are an example of a “Control” organisation. Individuals have a lesser impact in a control organisation. The infantry are typically deployed on a battlefield where coordination is more important than individual acts. The training required for individuals in a control organisation is much more limited. The training does not encourage creativity but rather ensures consistency and conformance to the plan. A classic example in the business world is McDonalds. The value to the customer of a McDonalds is that the Big Mac is the same everywhere in the world… from Tokyo to Toronto and Paris, France to Paris, Texas. Creativity can destroy the value of a “control” organisation, imagine the typical customer’s response to a Big Mac made from raw fish or horse meat.

“Control” is important when cost control and consistency are important. They are only appropriate in software development when an effective mechanism to provide command is not available. For software development, “control” is a crude tool as much of the work requires a significant level of creativity. However, without an effective mechanism to coordinate and prioritise “Commands”, “Control” is the only way to provide focus in a large organisation.  Consider an investment bank. They will allocate a budget to each area of the IT development organisation… Bonds, Equity Derivatives, Fixed Income Derivatives, Operations, Finance, and  Compliance. Each department attempts to optimise the value it delivers. When there is not enough budget, the executive’s decide whether to provide more. Any large programmes requiring additional funding are escalated to Management. Within the organisation, the individual groups optimise their profit based on their constraints. This is achieved by providing bonus based on achievement of goals (profit). In effect, Investment Banks operate by getting each business to optimise within its constraints.

“Command” in the context of software may be functionality based such as “Deliver Product X/Component Y” or it may be metric based “Increase Revenue/Reduce Customer Defections in Asia”. Its important for each group to understand what their goal is, especially in a large organisation with multiple products and customers, where there are competing short term and long term priorities.The executive ensures the organisation is focused on the right thing. Once the goals have been set, the organisation should allign to optimise achieving the goals. Distributed approaches (self organisation) are the best… providing appropriate mechanisms exist to coordinate the activity. Organisations with more liquidity can more quickly respond.

So executives should ensure focus using command OR control as appropriate.

Unfortunately, executives will often command AND control. The problem comes that the control (budget) process is normally an annual process and as a result it reduces the liquidity of the organisation. Any changes needed in the control structure needed to deliver the command goals result in time consuming consultation with the executives.

So in summary, an executive needs to “command” OR “control” to ensure the organisation is focused on the right set of organisational goals. Executives should avoid “command AND control” and should speed the transition from one to the other to avoid organisational gridlock.

Like I say. Still getting these ideas clear in my mind. I would welcome feedback.