HomeOrganizational Effectiveness

De-scaling strategy

Like Tweet Pin it Share Share Email

Can strategy de-scale?

We’ve been looking at Scaled Agile over the past couple of weeks, and have reached two tentative conclusions:

1. Scaled Agile drains a lot of what makes Agile agile out of Agile.

2. In some cases it might make more sense to incorporate Agile principles into the business than to try to scale Agile to support waterfallish approaches to setting and implementing business strategy.

Businesses establish strategy by figuring out how they expect the future to be different from the present and how the business should respond to the changes. Strategy gives companies guidance regarding what to invest in, and, even more important, what not to invest in.

By extension, strategy means using a process of successive decomposition to develop a roadmap for turning strategic intent into a coordinated program of action to deliver the desired changes.

Strategy requires a roadmap. Roadmaps mean inter-project dependencies. Inter-project dependencies mean inter-project coordination and a PMO (program management office) to do the coordinating. If the individual projects are still to be Agile, this is why businesses are looking for ways to make Agile scale.

And it’s why last week’s column suggested the better alternative might be to reverse this whole equation: Instead of getting Agile to scale, find a way to build strategy on Agile principles instead of on large-scale strategic roadmaps.

Here’s how I think it can work, step by step:

Step 1: Business leaders clearly establish the heart of the business. It’s mission as the term ought to be used — the social value the business provides, as opposed to the mission statement, whose usual translation is “Blah, blah, blah.” The term “core business” fits this concept, too.

Step 2: Eliminate big strategy. Big plans that take a long time and a lot of labor and budget to implement have too much risk. They might turn out to be bad bets even if they’re successfully executed, and the bigger they are the less likely they are to be successfully executed.

Step 3: Encourage incremental improvement in the mission. These are projects whose goals are to make the company more competitive. There should be a way to tell if projects in this category have achieved their intended business improvements — they should be measurable in the broad sense of the word — and they should have a logically sound connection to revenue, cost, or risk.

Step 4: Encourage intrepreneurship (not a word, but I needed something suitable) — small-scale investments in opportunities that don’t hit the mission dead-center, but are closely related enough that they can take advantage of many or most of the company’s current capabilities.

It’s the business equivalent of an amoeba sending out pseudopods. The ones that encounter food … or that find customers when we’re talking about businesses and not amoebas … get more protoplasm (budget), and if at some point in the proceedings most of the food supply is where the pseudopod is, that’s where most of the protoplasm will end up too.

Intrapreneurial investments are a great way for a business to hedge its bets — they’re small and low-risk enough that a modest success rate is enough, and because they’re close to the core mission they don’t have a lot of ripple effect, either.

Because each one is small, relatively simple, and takes advantage of existing capabilities, you can use un-scaled Agile to make them happen.

Also, each time one succeeds it adds to the company’s base of capabilities future intrapreneurial efforts can take advantage of while broadening the company’s mission and diversifying its product portfolio and customer base. Do this enough times and over time the company might find itself having transformed into a completely different business.

Understand, there’s a big difference between this being a way to successfully de-scale strategy and recommending it as “best practice” (hah!) all companies should follow.

Quite the opposite. While this “amoeba strategy” can work, it’s hardly the only strategy that will work.

One thing it does have going for it is that we have a pretty good model that shows how an accumulation of individually unplanned changes can turn into very different and highly successful new forms. It’s called the theory of evolution by natural selection.

Not that natural selection results in infallible success. Quite the opposite. In nature, many species fail to adapt: Evolution’s successes drive less successful adaptations to extinction.

There’s a term for this in capitalism as well — creative destruction. In its own way capitalism is as red in tooth and claw as nature is. It’s just that with capitalism, what’s red isn’t blood.

It’s ink.

Comments (10)

  • Big plans that take a long time and a lot of labor and budget to implement have too much risk.
    Indeed. Over a period of a few years, the environment will have changed, the business will have changed and the technology will have changed (twice). This is one reason why outsourcing projects (even on those few occasions when they’re managed well) are rarely a success – they depend on being able to specify in precise detail what your business needs will be in five years’ time.

  • I recently read a related article on Forbes.com that talks about the impedance mismatch between typical top-down company management structures and Agile (and agile) projects. The author is also critical of “scaled Agile” for some of the same reasons you are (and some different ones) and his basic premise is, like yours, to change how business operates to be more in line with Agile. His strategy, however, centers on re-focusing the business on “delight the customer” rather than “increase shareholder value.” I think your strategy and his complement each other nicely.

    http://www.forbes.com/sites/stevedenning/2015/07/22/how-to-make-the-whole-organization-agile/

    • I missed this one. Thanks. Steve is usually on target and this post you linked to is no exception … but he did miss the essential challenge of figuring out what Agile Strategy might look like.

  • I never had the opportunity to use Agile methodologies before I left the IT world; my company hierarchy was pretty much dead set against any idea they didn’t come up with themselves. I say that because it’s entirely possible my concern is already accounted for and I just don’t know it.

    I’ve been reading this Scaled Agile series with interest, and one question has nagged at me throughout: how does the data model fit into the whole process? It does seem to me that when it comes to data things need to be considered at an enterprise level so it’s all kept not only current but concurrent. For example, you don’t want three different systems to have three different addresses for a customer just because only one is being updated (if you have a legitimate need for three different addresses, then the data model and the data base both need to take this into account).

    Not trying to be a rabble rouser here, just curious.

    • It isn’t just the data model. One of Agile’s ongoing challenges is conformance with the technical architecture at all layers. The solution: Make sure all developers understand the architecture, recognize when something they need to do will require extensions to it, and have access to an approach to architecture governance when that’s what’s needed, and have access to isolated computing resources they can use in the meantime so architecture governance doesn’t slow them down.

      If you read a bit of handwaving in the above explanation, it’s because while this reads simple, it isn’t at all simple in practice.

      But it sure does look good on my PowerPoint slides!

      • One strategy for addressing the problem is to include a member of [insert any “enterprise-scale” team here] in each Agile project. Depending on the skill level of the core team and the culture of the organization, this person might be a temporary “technical expert” that is rolled on for iterations/sprints where stories involving that area of expertise are planned, or a more consistent member of the core team. Yes, this relies on the teams recognizing when the need for such technical experts arises; but if your teams aren’t capable of identifying their own blind spots, you’ve got bigger problems…

        * Examples of “enterprise-scale” teams might include Enterprise Architecture, Data Architecture, Enterprise UX/Design, etc.

  • It’s great that you are sharing your thought development on with us. But, when you said, in part, in Step 1:

    “Business leaders clearly establish the heart of the business. It’s mission as the term ought to be used — the social value the business provides”,

    the term “the social value the business provides” is new to me. Would you say what you mean by this term, and maybe give a few brief examples? I taught math for a few years and found examples helpful for my students. Or, is this a term you want to get our definitions for?

  • I really like the amoeba comparison. I think it does a good job of simply expressing how small exploratory projects can drive big changes, or identify big opportunities.

Comments are closed.