The Need for Responsive Roadmapping
Agile implementations have a big problem. When they bump up against an organization’s culture, progress can stop. It turns out, behaviors and practices can be a brick wall.
To me, it’s humorous to hear experts say Agile’s full benefits accrue only from “transformative implementations.” They declare an organization, from top to bottom and right to left, must embrace the Agile mindset. To do this, they tell us, organizations must change. But then how do they guide such change?
Agile vs. Culture
According to many, the biggest hurdle is to gain top management buy-in. Yet you’ll hear other experts say the same for different processes, methods, or initiatives. Consider the benefits of diversity, design thinking, and digitalization. Each is a big deal. And each demands management’s buy-in.
Perhaps the issue isn’t buy-in but figuring how to garner enough management mind share. Are Agilists going about it correctly?
It’s common to use a stepwise approach for Agile implementations. First, train a group of project doers and pilot Agile on a few product developments. These are usually software projects. But they can also be projects to build tangible products or services. A typical approach will ring-fence these pilot projects from organizational norms. The idea is to free the projects from older practices, what Agilists refer to as burdensome bureaucracy.
Next, declare the benefits gained from the new Agile practices. This means to discount any gains from ring-fencing the project. And then make the case that doing away with the slow, non-flexible project means setting up Agile is an easy decision.
But think about this for a second. Is this the best way to gain top management mind share? The biggest implementation problem is to change the organization. Yet the piloted test run separates projects from the organization. Does the stepwise piloting approach set up the big implementation problem? Yes. Most likely, it does. So does this help the mind share battle? Probably not.
How, then, can Agile win the mind share battle? The answer may seem divorced from the issue, but it’s not. It’s to understand the jobs that different parts of the organization need to do and the results they seek. For product development, the core job is to realize faster success in the market. But top management’s job is different. It’s delivering higher shareholder value. This is value both in the near- and long-term. You gain mind share by helping senior managers do that job better. It’s more than saying Agile delivers value so top management should be satisfied.
Doing the Job
The development job is project-centric. And the top management job is strategy-centric. The split creates a critical question. Will encouraging an Agile mindset among senior managers help them do their job?
The problem is that top management’s strategy job doesn’t place demands on flexibility or speed. Instead, the strategy job is to form deep business insights. And it’s to guide the discovery of innovations. Plus, you’ll see strategy help make trade-off decisions across projects.
Top management must deal with a range of issues. And these executives must lead strategy moves in response to competitors, customer opportunities, and economics. The job is continuous. It’s not a project that has a beginning and an end. Therefore, the key to gaining senior management mind share is to create an approach that connects agile work with the continuous strategy job. It’s to make sure top managers can do their strategy job better and with greater impact.
Agile and Beyond
Agile has made significant progress beyond its software origins. Nearly every practice and process has been shaped with an Agile mindset. This includes staged development, portfolio management, and concept generation. And I believe these changes are long overdue. But as the Agile manifesto spreads, there’s one corner of business that hasn’t mixed well. That’s the continuous shaping and leading of a strategy.
In Agile, it doesn’t matter if the project fits a strategy. And in strategy, it doesn’t matter how project teams carry out work. Yet Agile practices and Strategy moves can affect each other significantly. Both focus on success. Screw up one, and the other will also take a hit.
Agile implementations shouldn’t fail because top management doesn’t embrace the right mindset. The challenge is to bridge the Agile project management with the continuous strategy building. A good implementation will build that bridge. It won’t force the Agile approach onto strategy.
The bridge’s foundation is a shared understanding. It’s each side seeing the other side’s value and the problems that mount from their division.
Consider how, with every Agile development, the complexity of a company’s product offering grows more burdensome. Eventually, you must retire some offerings. But meanwhile, indirect costs will mount, and your product line will become vulnerable to competitors’ moves. The risk is that if you wait until after these problems arise, you’ll be late with your own strategy move. And being late to make a strategy move is a black cloud over senior management job performance. Agile only helps when directed to make good strategy moves.
An Agile-Strategy Union
Connecting the two worlds isn’t just to help top managers embrace an Agile mindset. It’s about building a two-way link between Agile and Strategy. Roadmaps are the bridge. But you need a special roadmap.
Let’s dig down to see why roadmapping is this bridge. But first, recognize the needed roadmap is not a roll up of project plans. That’s what several software vendors call the “product roadmap.” Instead, the solution is what I call Responsive Roadmapping. This is continuous roadmapping at a product line level, marked by scrum-like guidance sessions. And it’s tied to managing development projects and growth initiatives as portfolios. I know this is a significant undertaking, but it’s also valuable. For large companies, it can be invaluable.
Most managers understand how a roadmap lays out a game plan for project work. The assumption is that when management approves a project, it’s a declaration that the project fits a strategy. And a roadmap of approved projects is a game plan for carrying out the strategy.
Yet there’s a flaw in this thinking. A project’s approval is not a blanket declaration the project and strategy align and will remain aligned. This becomes clear when you dive into project details and work to decide what’s essential and what’s not. Product-to-strategy judgments need to be more fluid. These judgments will change with time and circumstances.
Agile methods do a nice job deciding what’s important for each product. And the strategy should influence a team’s judgment of what’s essential.
But an Agile approach doesn’t synchronize and align each project to a fixed plan. Nor does it try to roll up multiple projects into a coherent and coordinated game plan. Such work embodies the bureaucracy Agile seeks to avoid.
The implementation brick wall pops up as the regular business cadence marches on. It turns out an annual plan that feeds a budget cycle is the direct opposite of the scrum work organization. It’s old world versus new world. And most top managers know this, yet have no recourse. The agilist says the solution is to make planning fast and flexible by using Agile methods. Old world planners then say what’s the point of a strategy if you change it and re-prioritize investments every few weeks. The dilemma is that both are right.
Speeding a product to market is the key to success in fast growth markets with little competition. That’s where Agile-everything works the best, including with strategy.
But the story is different in established markets. Here, too many self-directed projects can paralyze a product line. Each adds its own direction and intent, adding chaos into a product line with each launch.
I call this product line entropy. It’s a natural force that adds chaos to product lines. The problem is that entropy spreads chaos in proportion to the number of projects underway. And self-directed projects add more entropy. The recourse is to gain better oversight based on a strategy.
The ugly part is that Agile entropy is real even when each development is financially successful. Consider an Agile team’s response to hearing their approach was stellar, but the results are killing the company. What do you do? Do you double down on Agile?
Responsive Roadmapping blends top-down guidance and bottom-up reality. This helps to decrease product line chaos. Plus, the practice uses another tool to reduce entropy. It sets innovation targets that drive front-end investments. The great news is how these targets match the projects to a strategy before agile development.
Innovation planning is crucial in product line dynamics. That’s because the work reduces an Agile team’s need to invent. And although self-directed invention might be needed for a project’s success, it’s also a prime source of product line entropy.
Tying to a product line strategy, not a business strategy, is important. Many managers think each Agile project should connect to a whole business strategy. But that’s more a long-distance jump than a connection. You seldom need to connect individual projects to a business strategy.
Sadly, many gurus describe a business strategy more like a philosophy than a game plan. It sounds intelligent. But it provides no means to connect projects.
But product line strategies are different. Every development projects either feeds or creates a product line. It’s at the product line level that product dynamics play out. And each project should play a role in the dynamics.
The Framework Matters
With the right framework, managers may codify projects. This allows managers to represent each project as an object on a product line roadmap — the strategy game plan. The key, though, is to understand product line strategy and its parts. The reactive nature of Responsive Roadmapping isn’t a one-way street. The approach allows Agile teams to influence product line strategy changes and strategies to course-correct Agile work. It’s a bridge between the project doer’s job and top management’s job, with the results best for both. And it lessens bureaucracy by using available project and portfolio data.
Responsive Roadmapping is an information and decision flow that energizes both agile projects and strategy. And yes, it does this by gaining continuous alignment between the two worlds. But more to the point, it doesn’t lock either side to fixed plans or fixed results. That’s important.
So what exactly is Responsive Roadmapping, and how do you bring it into an organization?
Building The Agile-Strategy Bridge
The approach moves product line strategies and their roadmaps into an active mode. It uses objects to coordinate strategy parts into a dynamic game plan. See figure 1. These parts include market segments and targets for innovation. Plus, they add platform-levers and products-in-development.
The bridge works by using roadmap-derived charters as guidelines for Agile project judgments. And it uses Agile backlogs and issues as lenses to shape the strategy’s direction and timing.
Learning both Agile and Product Line Strategy is key to Responsive Roadmapping. You’ll see that Scrum and time-boxed Sprints matter in its flow. They drive work on strategy lenses and judgments for advancing both the strategy and the projects that carry it out.
It’s best to set up Responsive Roadmapping one capability level at a time. Consider how a company might use interactive dashboards and AI to build out real-time scenarios. The problem is this demands a high capability level. A company has much change to make before this can be a reality. More likely, the starting point is to use excel and manually created timelines.
The key to good implementations is to learn and build skills one level at a time. And it’s to do so without slowing down projects and strategy responses.
Product Line Roadmap – The game plan for carrying out a product line strategy
A Product Line Roadmap lays out a project oriented game plan for carrying out a product line strategy. These Roadmaps emphasize both strategy realization through Project and Task coordination. CLICK PICTURE TO ENLARGE
Building a bridge between Agile practices and the Strategy job is a big topic. Those interested should learn more. This includes gaining a deeper understanding of Agile and the Agile mindset. Plus, it includes learning more about product line strategies and their roadmaps. Many managers understand one but not the other. But the bridge needs managers to understand both sides.
You’ll find many venues and opportunities to learn Agile. And most organizations have done so already. But understanding product line strategies and roadmaps isn’t as popular. Instead, managers focus on a single product’s strategy. They also seek to learn more about business strategy. But to unite the Agile and Strategy worlds, I encourage readers to learn more on product lines. Also please ask me as many questions as you have. I will try my best to answer you.
To learn more about Responsive Roadmapping, 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.
Whitepaper– Good Product Line Strategy Matters.