A transformation should have specific goals for a business:
Agile transformations are no different, and many of them turn out to be failures. There are three common reasons organizations fail to realize business value from their agile-transformation investments:
Establishing Clear Business-Value Goals Many agile transformation leaders don't comprehend how their transformation efforts will deliver business value. They don't incorporate business value in their measurement strategies, and they don't specify any concrete business-value goals that will make a real difference for the organization. To be clear, I am NOT saying they don't have goals. I am saying their goals don't go far enough in expressing how the transformation is expected to add value. For example, an agile transformation that increases an organization's ability to absorb late-breaking software changes does not, by itself, deliver increased business value. If the organization operates in a dynamic, competitive environment, the ability to apply agility to quickly sense and respond to opportunities and threats would be good, but that still isn't enough. If the organization is at risk of losing market share to more nimble competitors, we are starting to get somewhere. In this context, the ability to respond more quickly and effectively to market opportunities and threats would be beneficial for cash flow. Increased market responsiveness would also be beneficial for long-term competitiveness if the company expects to face an array of new and unforeseen opportunities and threats in the future. The bottom line is transformation goals must be tied to enterprise mission impact, cash-flow improvements, or sustainable competitiveness for them to matter. Let's look at another example— An agile transformation that improves employee fulfillment and engagement won't be valuable by itself unless the ultimate mission of the enterprise is to provide an environment for employees to experience joy at work. For most organizations, the business value from greater employee engagement and fulfillment might come from various things:
As companies embark on agile-transformation journeys, it is important for them to take the time—ideally up front—to include true business-value goals. This is key to ensuring transformation efforts are focused on what really matters to the organization as a whole. Connecting Operating Models to Business-Value Goals Once leaders are clear on business-value goals, they can be deliberate about designing operating models that will get them there. Many agile transformations are centered around software development, which makes sense being that the Agile Manifesto—the catalyst for the broader Agile movement—was written to address software development agility. The challenge, in the software development context, is business-value goals often require operating-model changes, beyond software development. The same is true for many agile transformation efforts beyond the software-development domain, although the issue tends to be less acute in some other areas. Consider an organization that wants to increase revenue from software products. They may, in turn, intend to increase the rate at which the organization learns and adjusts to changing customer needs, which would be enabled by software-development agility. For example, if product managers don't change their approach to defining and managing product roadmaps, it won't matter that the software-development teams are more agile. Product managers would need to agree to exploit software development agility in an effort to actively learn and adjust their product roadmaps based on in-market customer feedback. Otherwise, they would simply have rigid product plans, being delivered in smaller software batches, without any opportunity to learn and adjust by putting features in front of customers sooner. Granted, they might get some value from a better feedback cycle between the product managers and software developers, assuming the product managers are willing to engage more frequently, but they won't get the overall business value benefits from more agile product development. Moreover, even if the product leaders are onboard and the operating model incorporates agile product management, that still won't be enough. They will probably also need to consider implications for the marketing, sales, and customer service organizations who may NOT be setup to do key steps, such as:
In any situation, with significant dependencies between functions, dependencies need to be actively managed to achieve business value. The target operating model must acknowledge and account for these dependencies, even if the initial scope of the transformation is intended to simply prove the concept of agility will work. The problem with many agile transformations is they seem to completely ignore these dependencies. This isn't because sponsoring leaders are blind to the dependencies. More often, it is because:
One of the common issues we find, in the software product-development context, applies to the allocation of product owners. If product leaders are unconvinced about the benefits of agility, they are unlikely to work with technology leaders to make the necessary changes needed to have their people engage differently. After all, if there is no intention to roll-out features more quickly, to learn from customer feedback, nor to adjust roadmaps accordingly, why should "their" people spend more time with software development teams? In some situations, technology leaders will simply argue that development teams need more frequent feedback and will skip providing needed business-value context. Sometimes this works, but the product leaders often remain skeptical, ready to revert to familiar practices at the first hint of trouble. In other situations, the technology leaders end up allocating technology people to play "proxy product owner" roles. This isn't ideal, unless these people are given the space to engage customers and play the role effectively—which is rarely the case. For some of these reasons it is better to be deliberate in defining business-value goals and in identifying how the operating model will need to change broadly—even if you intend to "stay in your lane" initially as a sponsoring leader. Moreover, being clear about the business-value context and associated goals tends to drive better decisions throughout the transformation. For example, In many large organizations, a business-value focus typically exposes the fact that sources of that value vary significantly across business units and functions. Recognizing this fact helps transformation leaders avoid the trap of designing a rigid, one-size-fits-all, target operating model that cannot possibly meet all business-value goals for all the relevant stakeholder groups. Establishing Effective Transformation Plans for Achieving Business-Value Goals Once you are clear about business-value goals and the target agile-operating models, it is possible to define a transformation roadmap that is focused on overcoming impediments to success. Rather than defining a transformation plan that includes the need to overcome political, cultural, mindset, and structural barriers, many agile-transformation leaders simply operate as if these barriers don't exist. When it comes to agile transformations, (and most other transformations for that matter,) it is generally better to determine what needs to be accomplished to maximize value while considering barriers to success. The alternative is to start with the barriers and ask yourself, "What can I successfully take on to be 100% safe and avoid the barriers?" The problem with the latter is you will inevitably have to answer a question about the value that has been realized from agile-transformation investments. Whether the question comes early in the process or much later, it inevitably will come. If you don't have a good answer, you may be exposing yourself to even greater risk than if you had started with the intention of generating meaningful business value. None of this is to say that leaders should rush full-speed ahead, without caution, and make changes purely through superior influencing skills and force of will. While that is one approach, it often ends badly. The better approach is to start by assessing your current level of control and influence and using those findings to build a plan that will systematically build momentum and expand influence over time, where needed. In many cases, the plan will call for demonstrating value in small, yet tangible ways to help convince skeptical colleagues. In other cases, it will call for educating colleagues in a more compelling manner. Consider one more point. Any transformation plan you develop needs to be executed in an agile manner. In other words, you need to always have clear, near-term goals and plans that you will execute in small batches. You will observe whether your execution is taking you in the direction you intended. If not, you will adjust your plans to get back on track towards your overall business-value goals. The bottom line is... If you start with the end in mind and determine clear business-value goals, define target operating models for achieving those goals, execute a pragmatic plan for building momentum and influence, you will be able to drive meaningful business value for the enterprise. Feedback is welcomed. We would love to hear about your experiences in working to generate business value from agile-transformation investments.
5 Comments
In an age of rapid change and disruption, in which complacency often means failure, it is critical for leaders to be decisive. They need to make good innovation decisions and execute well to compete and win.
So what does it take to make good innovation decisions? In some cases you must conduct rigorous analysis to get to the right answer e.g. applying Six-Sigma analysis to identify specific ways to reduce unwanted process variability. In other cases you need to conduct experiments to validate assumptions that help narrow your focus towards a better, if not perfect, answer. Both approaches are valid, but context matters. The problem is some companies only value rigorous analysis and right answers, regardless of context. Successful leaders in these companies value analyzing situations, making decisions, and executing with precision. To get funding for their initiatives they produce strong, confident business cases. They learn, through experience, that expressing doubt is a sure way to lose the funding battle. Accordingly, they include assumptions in their business cases that are treated like facts. The problem is most meaningful innovation is inherently uncertain. Assumptions are essentially hypotheses to be validated. Companies that refuse to acknowledge this fact end up making wasteful investments that ultimately don’t pay off. Invariably one or more of their assumptions turns out to be wrong. They also end up with watered-down investments that don’t sufficiently move the innovation results needle. It is much harder for leaders to be bold and take risks if they need to be certain about results. Perhaps the biggest problem is their unwillingness to change plans in the face of new information. An important side effect of valuing certainty is that any change you make to your plans simply confirms you had a bad plan. You must have missed something, which means you were wrong. Being wrong is not well tolerated in a company that values certainty. The bottom line is companies that only value certainty are increasingly struggling to survive. They aren’t bold enough with their innovation decisions because risk-taking is inherently uncertain. They are slow to respond to emerging threats because they need to be certain the threat is significant before starting to mount a response. They waste a lot of money on investments where they should have more cautiously validated assumptions. They refuse to learn and improve because learning, by definition, means they weren't certain to begin with. For companies that acknowledge and manage uncertainty, agile approaches to innovation provide a framework within which they can:
For companies that only value certainty, agile approaches are less meaningful. |