All Posts in Strategy and Tactics

|In: App Dev Methodologies|Last Updated:

If everyone did everything right from the beginning, it would be easy.

“It,” in this case, is automated regression testing. “Did everything right” is building a strong test plan every time IT put new software into production, and then added it to the existing regression test suite.

Easy peasy.

Easy peasy if, that is, you’re a management consultant like me and not CIO of an actual IT organization. Easier peasier than the alternatives, perhaps, but easy? There’s nothing about software quality assurance that’s easy.

But very few IT disciplines rank as high in importance when it comes to succeeding as a modern IT organization.

The IT pundit class has discovered the need for speed, and about time. Speed, more than any other single factor, is what lets businesses outmaneuver their competitors, thereby profitably selling more products to more customers.

And … in most businesses, most of the time, delivering needed information technology is what limits the pace of change. Speed up IT, speed up the business.

Not there aren’t any number of other factors waiting in the wings to keep things slow, because slow quickly becomes a habit, not a matter of critical path planning. But I digress …

For business to be faster, IT has to be faster at delivering changes to the applications portfolio.

Which in turn means DevOps is in your future, which in its turn means automated regression testing is in your future, if it isn’t an important part of your past and present.

Yes, DevOps. Call me a converted skeptic. Back when folks thought the lead DevOps story was that Dev and Ops were now collaborating, it earned a gigantic ho hum from yours truly.

But as it turns out, DevOps is the least interesting aspect of DevOps. What’s most interesting: DevOps blows up our old understanding of how to move software out of development and into production.

The Standard Model involves bundling software changes into major releases, which then are subjected, not only to the full range of test protocols (unit, integration, regression, stress, and user acceptance), but then have to run the Change Advisory Board (CAB) gauntlet.

The assumption behind this bulky approach to software implementation is that each new release carries with it the potential for blowing up production … either by sucking up server or network capacity so as to slow everything to a crawl; by corrupting one or more corporate databases; by opening up a gaping, easily exploited security hole; or by some other nasty consequence software defects can cause.

Not that these concerns are unfounded. Software defects can cause any or all of these problems, and the bigger the release, the more opportunities there are for bugs to be hiding that can cause them.

What DevOps does that’s truly interesting is stand this equation on its head: Instead of bundling changes into the major releases that create so much risk that drastic measures are called for, it puts changes into production in large numbers of small doses.

And because each release is small, and has been … and this is crucial … subjected to automated regression and stress testing, the risk of it blowing things up is so small that the whole CAB process becomes a fifty buck solution to a five buck problem, as it were.

The magic buzz-phrase is “continuous delivery,” and to give you an idea as to whether “continuous” is an exaggeration or not, way back in 2011 Amazon was making production changes every 11.6 seconds.

This incredibly rapid pace of change lets Amazon test different selling approaches, fine-tuning its merchandising to an astonishing, and, if you’re a competing retailer intimidating extent.

In your case?

Here’s where it gets interesting (or, depending on your level of interest, more interesting): As you know because you’re a regular reader here, there’s no such thing as an IT project, which means there’s no such thing as a software implementation.

This is something even the most advanced DevOps practitioners get wrong. When Amazon deploys its website changes, what’s changing is its selling approach to a large enough fraction of its online customers to provide a valid statistical comparison to its current practices.

When a DevOps team working on an internal application releases changes, for the most part they’re changes to internal business practices.

Which leads to this question: Should DevOps teams just slipstream changes into production as Amazon does on its website? If not …

* * *

Tell you what — I’m not going to do all the work on this. Post your thoughts on how IT should issue changes to internal business systems and the business processes and practices they support as Comments this week, and we’ll continue the conversation in next week’s KJR.

Comments

|In: Organizational Effectiveness|Last Updated:

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