This is the second Advisor in the series, “Ingredients for Enterprise Agility,” in which I outline practical lessons from leading Agile transformations as a coach. Enterprise coaching combines an in-depth knowledge of contextual Agile with cultural change techniques. As I described in Part I, enterprise agility in most business sectors means fundamental organizational change, not just using Agile in IT. Enterprise agility means changing the organizational culture to serve customers better with lower operational costs and greater customer and employee satisfaction. Agility also means having the desire, culture, and capability to change direction to respond rapidly to market conditions or opportunities.

Changing the organizational culture is one of the most, if not the most, difficult leadership challenges because the organizational culture of an enterprise is its DNA. This DNA distinguishes your enterprise from your competitors in the eyes of consumers and employees. It is essential that in organizing and planning for enterprise agility, care is taken to preserve the positive cultural elements that enable your brand promise’s fulfilment. This is important because, in all but startup situations, a transformation must occur while serving customers and generating revenues.

To create a transformation plan, the organization must understand its starting point. It has to know which aspects of the enterprise need to change and which aspects must be preserved. Making these decisions often requires candor and objectivity. C-suite executives may need facilitation to understand how much change is required to get from where they are now to where they wish to be. At the outset, few c-suite executives will understand the personal and foundational impact required to create agility. For this degree of sacrifice and organizational disruption, the potential gain must be clear for all. But establishing enterprise agility is not a strategy. Agility is the enabler of strategy. We want to become more agile because new market entrants have created a disruption to which we must respond to survive. How the organization plans to respond is the strategy; being agile facilitates that response.

If c-suite executives are unsure of the organization’s strategic goals, this will be exposed. However, the situation of not having a “grand strategic plan” may not be that big an issue. In 1978, Henry Mintzberg introduced an emergent strategy concept (a strategy emerging not from original intent but the sum of reactions to events). In many significant organizations, the strategy is emergent unless there is a seismic market shift. An excellent example of seismic change is British Petroleum’s strategy to move from an oil company to a carbon-neutral energy company by 2050. Irrespective of a grand plan or a strategy created by emergent steps, the transformational objectives and the organizational strategy must be strongly aligned, or both could fail.

An enterprise comprises interlocking sets of operational and personal goals, roles and responsibilities, behaviors, processes, values, communication practices, attitudes, and assumptions at a foundational level. These elements blend with the priorities assigned to each, forming the organizational culture. That culture is what makes one firm different from another firm. An Agile transformation replaces and reformats many of these elements, and it is the transformation’s job to stitch all elements back together to create the new Agile enterprise.

If the organization continues to function, serve customers, and generate revenues while transitioning, two things are required: a working hypothesis and a plan. The working hypothesis describes a target operating model for the organization at the next stage of the transformation; the plan describes the journey to get there.

The target operating model working hypothesis takes the high-level visionary statements probably identified in board minutes or a business case to the next level of detail. If the c-suite executives have not been explicit about the objectives, then the working hypothesis serves to clarify the intent. I have found many business leaders adjusting scope, breadth, and depth of a transformation once they see their instructions played out as a visual or written hypothesis.

The working hypothesis creates an initial set of assumptions for the new target operating model. It broadly describes the organization, outlining the split of functional responsibilities between the Agile and traditional organization. The act of defining a working hypothesis grounds the statements of intent in the organizational and high-level process designs. Discussing the working hypothesis enables senior and middle leaders to evaluate the degree of change and adjust to its consequences before the change starts. There is a balance here. Discussing the changes while they have been envisaged assists with change readiness and enables preparation; it also provides opportunities for adversaries to block or deflect. The key is to ensure that everyone affected understands the enterprise journey and the strategic imperatives of the chosen path. For some, that understanding will not reduce the personal pain they will feel in the transition. As the transformation progresses, the working hypothesis is enhanced and adapted based upon the lessons learned, challenges encountered, and achievements made.

Senior executives sometimes want to adopt Agile but do not know precisely how to do it. The purpose of the plan is to provide them with the answers they need. Many executives typically want line-of-sight into how the transformation is likely to unfold. It is not enough to say, “We’re Agile, we don’t plan.” The plan must have credibility and be able to stand the test of scrutiny. You will need to decide how to give stakeholders safety and the economic view. To create a plan, the organization must agree on the place from where it is starting, which value stream can be a pilot for the new organization, and the new ways of working that need to be adopted. When changing business operations, business support activities will often have to be adapted or improved to align.

The transformation must be given sufficient structure, even if you believe in self-organization, exploration, and evolutionary planning. However, creating a traditional fixed plan would require the Agile transformation to leap three almost impossible hurdles:

1. The enterprise knows its exact destination

2. An understanding that this intent will not change over the time needed for the transformation

3. The enterprise has detailed knowledge of the precise steps required to reach the objectives, without the need to react to unexpected circumstances

Since these conditions are most unlikely to be reached in all but the most predictable industries, an alternative form of plan is required.

Just as with a traditional project plan with a detailed work breakdown structure, an Agile plan requires work to be completed or decisions to be made before it can be created. It is true that planning in the Agile context needs much less preparation than with traditional activities, but the saying “failing to plan is planning to fail” is also relevant to Agile transformational activities.

The transformation plan is made up of horizons defined by the outcomes. Activities organized by themes support these outcomes. The transformation plan used as an example in Figure 1 has five themes:

1. An HR theme entitled “Teams, job families, and competencies”

2. An organizational structure theme called “Agile handoffs and partnerships”

3. An Agile teaming and ways-of-working theme entitled “Agile methods/tools”

4. A value stream optimization theme called “Improved productivity”

5. A management information theme called “Measured outcomes”

An Agile transformation team should build out its plan in 90-day increments. An initial Agile journey will often take between 12 and 18 months, sometimes longer. As the team approaches each increment, it needs to identify the outcomes it proposes in 30-, 60-, and 90-day horizons. It uses the Deming cycle to plan, do, study, and adjust its planned actions using a Scrum format.

A transformation plan is created in a collaborative activity and is well suited to the big room planning technique. The horizon-based plan is used as a communication tool as well as a sundial that clearly indicates progress. The items you may wish to identify to a broader audience may be a mixture of the start of activities and others’ conclusions.

In big room planning, the transformation team and key stakeholders meet to create a high-level plan. The goal is to have a rolling 90-day plan with a reasonably specific view of what is likely to occur. In format, the 90-day plan is like an Agile release plan or a plan for a program increment. The planning activity will break down the themes and identify the change activities and expected outcomes for the next 90-day period. In line with Agile principles, activities in the near-time horizons are planned with greater detail than those farther away.

Stakeholders who are not closely associated with the transformation must make explicit the plan’s connections to the desired strategic vision. It may be obvious to say, but it is sometimes difficult to achieve: each outcome must be seen to combine to achieve the sum of enterprise objectives for the transformation. A test asks how this or that activity generates value or contributes to the desired transformational outcome. If this cannot be defined or a compelling reason cannot be found, then the transformation is probably doing work just for its own sake!

The reason for this initiative is to create better business. Although these objectives may pivot based on learning or changing market circumstances encountered on the journey, at least initially, stakeholders should relate to some if not all of the outcomes identified in the plan. They should view these outcomes as making potential progress toward their goal.

The plan will not be the same as a traditional plan but will evolve and be reshaped as each transformational theme progresses toward its desired outcome.

In this Advisor I have outlined how using a target operating model working hypothesis may help c-suite executives understand how adopting Agile can impact them and their organization. The working hypothesis develops incrementally as the activity progresses. I have also suggested how to plan a transformation based upon outcomes, 90-day horizons and themes, and offered an Agile sundial as a means of setting direction and illustrating progress.

In the next Advisor in this series, I will discuss mobilizing an executive team to guide the path to enterprise agility.