Agile Isn’t A Strategy

But Smart Strategy Drives Speed and Agility.

“Agile execution beats strategy.” It sounds good, but is it true? It is if you believe strategies are fixed and unresponsive to change. But it’s not true if you create the right strategy made responsive to new situations.

The biggest problem with strategies is that they don’t stand up to reality. At least they don’t the way many companies create and manage them. We’ve learned over the last several decades that strategy often fails in execution. Even going back to the 1800s a famous Prussian field marshal named Helmuth von Moltke the Elder (his nephew was the Younger) said that “No plan survives contact with the enemy.” The same is true for strategies. No strategy survives contact with reality.

And no one wants to spend months framing a plan that gives a great vision but has no action. Developers and innovators know their primary goal is to get a product out the door. To do that, they can’t carry the burden of a rigid strategy.

Masterclass

Confusion to Chaos

But here’s the problem. Work without a game plan can be directionless and create confusion. Choices and decisions take on a sense of randomness. But in large companies the absence of a strategy across many projects can turn the confusion into chaos.

Recognize the cause when a company is firefighting product quality, cost, or performance issues. It’s the absence of a good strategy.

Those in small companies don’t see the problems caused by not having a strategy like those in large companies. The curse of big companies with existing products is that issues get amplified. To use an old metaphor, correcting course in a large company can be like steering an ocean liner.

But it need not be so difficult. The strategy I’m talking about is not to guide the whole organization. It’s not an aspirational vision of how to conduct business. Unfortunately, many Agile team leaders think this is strategy and it’s disconnected from their reality. But that’s not the case. Rather, they need to understand the Product Line Strategy. You’ll see that product line strategies are more tangible and easier to get your arms around. You can pull apart a product line strategy, examine it, and put it back together. Some parts may be brilliant, while others not so much. But the key is that each product line strategy is traceable and measurable. They are not hopes and ambitions.

Product Line Strategies Matter

Product line strategies, as I discuss here, relate to all product and service types. It doesn’t matter if it’s software or hardware, B2C or B2B. Product line strategies come together just the same. And a key contributor, one of its parts, is what I refer to as a platform-lever. Anyone interested in development speed and flexibility should learn as much as they can about platform-levers. These are not the same as the eco-system platforms most business gurus discuss.

A platform-lever is a common factor cutting across products in a line. And it’s internal to the company. What’s important is that it delivers leverage, defined as faster development speed and greater performance per unit cost in resulting products. If you wish to develop products quickly, you’ll be advantaged with a smart platform-lever and disadvantaged without one. To see why, you need to dive into product line strategies.

A common platform-lever type, but not the only one, is a design lever. This is a hardware or physical component that finds reuse as a core design element in products that target multiple customer groups. It might be a motherboard, an engine block, or a molecular structure. Fast development and greater performance per unit cost, i.e., the leverage, comes from building on or working through the platform-lever. It’s from not having to create an entirely new product.

Pushing Design Limits

But in the Agile world things get sticky when developers push platform-levers beyond their design limits. It’s a common problem that shows up in project backlogs. This problem arose in much work during this last decade. Nearly every hardware offering was morphed into hardware plus software systems.

To build the system, development teams must add sensors and actuators to the hardware. These building blocks are independent of the design platform-lever. And to make the system work, programmers must add software modules to make the new building blocks do their job. Unfortunately, because the old hardware lever isn’t designed to be used with software, this causes a challenge.

Software driver development, the link between old hardware and new software, becomes a schedule interrupter. And when you see the challenge on a project, you can predict the problem. But there’s a deeper issue when the challenge is systemic across many projects.

The problem is the platform-lever. The old hardware platform-lever wasn’t designed with the software system in mind. An Agile software team gets called on to use their heroic mindset and flexibility to deal with that challenge. But while their job is to deliver a product, a first go-round is likely to be a patchwork solution. The full solution is to rework the product line strategy with a new platform-lever. This is a clean-slate design that can become the system’s core. It’s not a rework of the old hardware. Keeping a strategy fixed beyond the patchwork would be a continued burden to an Agile approach. Plus, it could be a death kneel to the product line.

A Common Scenario

The discussion here is about a simple union of hardware and software. But the scenario plays out across many platform-lever types. It could be a service lever, a software lever, or a production asset lever. And you’ll see similar events with all new technologies, whether machine learning or machined parts, artificial intelligence or artificial flavors. The new technologies start as building blocks, adding onto an existing platform-levers. And if the addition is kludgy, projects can stall and the end results may be less than desired.

Somehow the platform-lever must be changed for faster, more fluid development. This might mean adding the new technology into the platform-lever as part of a multi-generational plan. Or it might mean redesigning the platform-lever completely. You’ll see such changes are notable strategy moves, not to be taken lightly.

But that’s the point. Smart strategy moves improve agility and speed. And while I’ve discussed this as a strategy move that advances a product line platform-lever, more is involved. Two other strategy parts are also critical. The second is attribute positioning, and the third is cross-organizational alignment. All three product line strategy parts matter in making the move successful. The parts must work in unison to be fully effective. And orchestrating the parts is more than an Agile engineering exercise.

Flexible and Responsive

It’s important to see how developments, whether agile or not, gain more from tying to smart product line strategies. And, if a product line strategy is weak or nonexistent, you’ll see development teams forced to confront many more challenges. But while making a single platform-lever change to a strategy can be important, over time it’s seldom enough. Good product line strategies need to adapt to many situations.

The key is to add flexibility to the product line strategy’s substance and execution. Teams do this by creating proximate, not specific, goals and objectives. And they create work guidelines, not directives. Plus, good practice is to change strategies and how managers carry them out. Teams base the change on issues, opportunities, and constraints. This is in-motion management. I call it Responsive Roadmapping. The approach is to manage a full set of projects to drive product line gains. This goes farther than resource shifting that traditional portfolio management offers..

Responsive Roadmapping bridges project work and strategy. It uses Agile backlogs and development challenges to guide the strategy. And while teams continue to rank-order and groom their backlogs, they do so knowing strategy issues and opportunities across the product line. The goal is to remove roadblocks and minimize hindrances to carrying out the strategy. It’s to squash problems before they harm the product line and prevent developers from meeting their goals.

I know that sounds big. Sure, but it’s real and it’s doable. It’s a matter of putting the pieces together and moving them into practice. Usually when I say this to managers engulfed in all things Agile, they argue Responsive Roadmapping is a process and sharing backlogs is bureaucratic. And well-trained Agilists are taught to reject these approaches. I get it. But then the issue is whether Agile’s flexibility within an individual project translates to improving a whole product line? If you optimize the work for a single project, are you optimizing the whole? The answer is “no.”

Build Your Product Line Strategy

It’s a problem when Agile teams focus on getting a product out the door and not on improving the health of a whole product line. The good news is that Agile and hybrid development methods coupled to smart Product Line Strategies and Responsive Roadmapping corrects the problem.

My call to action is for developers and team leaders to learn product line strategy and its parts. Plus, it’s to learn Responsive Roadmapping. This knowledge will help you move your organization beyond Agile’s localized gains. And you’ll see how to use Smart Product Line Strategies to drive greater results from each Agile project.

Learn More

To learn more about Product Line Strategies, Responsive Roadmapping, and how they drive speed and agility, please consider several Adept Group venues.

Consider purchasing and reading my book, The Profound Impact of Product Line Strategy. Or consider my in-depth Masterclass. This 1-day class enables deep discussion specific to different product lines and organizations. You may also find our customized Seminar, held on-site at your offices, a perfect fit to your needs and your product lines.

———————————-