Working with the Agile Strategy Map™
The Agile Strategy Map is a tool that enables a leadership team to align and coordinate their efforts both on a strategic and tactical level. Not only does it act as a guidelines for the organization’s Strategy, but it also allows you to visualize and track progress.
Elements of an Agile Strategy Map
After adopting the Agile Strategy Map with dozens of clients, we came to appreciate it also as a powerful Enterprise and Leadership Coaching Tool: the outcome is important, but the conversation is even more important. The impact in terms of sense of ownership and momentum determined by leaders co-creating and collaborating around a common goal greatly increases focus on the business goals, and offers unique opportunities to coach the leadership team towards becoming a more resilient organization.
The Agile Strategy Map is a real visual map that includes the elements of anchor, position, and movement. In principle it is a way to visualize a goal, as well as the success factors and dependencies that are relevant to moving in the right direction. The anchor of an Agile Strategy Map is a Goal, which can be expressed as a specific target, measurable and timed, or simply as a direction towards which to move. It represents the business goal and creates focus for the strategy, orienting all other elements. Since the Map is also context-specific, the Goal will need to fit the context of where the organization is and where it intends to go.
It is also very important for the Goal to be outcome-based, not output-based, which means that it must be connected to creating value to users, customers, and/or employees. Stakeholder value is a product of the fact that customers and users are satisfied and employees are engaged.
If the Goal is a specific target, it is possible to use different techniques to formulate it, such as the SMART checklist. An example of such a Goal can be: “Strengthening our position in mobile services by increasing the number of annual mobile service’s customers by 20% over the next 12 months”. Alternatively, we have in the past successfully used the “Remember the future” technique, which is based on numerous studies in cognitive psychology investigating how we think about the future: “Imagine that you fall asleep now and wake up in 12-18 months. What key changes do you see around that make you happy?” These kind of questions generate more richly detailed and sensible goals, because it is easier to understand and describe a future event in the past tense than a possible future event, even if neither has occurred. By thinking of a future event as one that has already occurred, we also pave the way for imagining possible factors that will enable or accelerate generating the event.
In the case of the Goal as a direction, according to complexity thinking, it can be expressed and measured in terms of Vector Tracking (as direction and speed of change). The target for the organization can then be the direction and speed of change. For instance: “We want to increase our customer satisfaction 20% faster than it is currently growing, so we will be outpace out competition and increase our market share significantly”.
Even if we have defined the Goal, we want a way of reminding ourselves that we should challenge what we are trying to achieve as often as possible, because reality and conditions around us change very quickly. The volatility we are dealing with nowadays is such that it is very risky to base medium- and long-term plans on current situational analysis without planning for continuous adaptations. The Goal itself might be discovered over time, or at least refined, if not reshaped, by integrating new insights. The Agile Strategy Map process is supportive of continuous adaptations and injections of new insights, allowing us to maintain coherence and transparency at the same time.
Exploring the existing Landscape: Confirmed Success Factors
Virtually every organization has some kind of strategy, or at least has a plan to get to some definition of success. We recognize that most organizations have achieved some level of success in the past, whether intentionally or just out of luck. Even when these strategies are very static and expose an underlying linear and mechanical thinking, it is important to show appreciation for what the organization has achieved, and identify what has helped the company be successful in the past.
Confirmed Success Factors (CSFs) are an expression of the successful factors that have led company to its current state and will provide a picture of the past Landscape and Patterns (to refer back to the concept of the map). These - in line with the ORGANIC metaphor - could be considered like an organism’s acquired capabilities, which became part of its DNA as a result of an evolutionary process. The CSFs might be in the form of processes, rules, policies, constraints, approaches, in short everything that is established as a way of working within the organization, as well as established value propositions to existing customers. All these things, learned over time and validated, are assets to the organization, and are probably responsible for a significant part of the overall revenue. Given the defined Goal, we may be able to identify a subset of CSFs that will be enablers for achieving the goal. We want to be clear about focusing on those that we believe to be relevant to the Goal and its specific context. This might seem like a hard decision, but if you want to achieve success you need to focus on what is most important to you and relevant to your business.
The term “Confirmed Success Factor” emphasizes that we have attained some knowledge and that this lesson has been retained and consolidated into an organizational asset. A CSF is, then, always in the Obvious or Complicated domain according to the Cynefin framework. Read more about the Cynefin framework domains.
A Confirmed Success Factor may be expressed in the following form:
By <…> We learned <…> And this helped us <...>
As mentioned previously, it represents an acquired capability for the organization that can act as an enabler towards achieving the goal. The fact that the CSF is achieved and known doesn’t mean that we won’t have to do anything about it. On the contrary, a CSF is like a lever that we can use to enable our organization to achieve success and needs to be oiled and maintained, or it will decay and lose relevance. To maintain and continuously evolve a CSF we require at least one Necessary Condition. This can act as an anticipatory trigger, reacting to or prompting specific events/needs, for example periodically reviewing a policy to check how it’s performing against some Key Performance Indicators (KPIs). We can create triggers in the form of Necessary Conditions, connected to the KPIs or to a specific moment in time. The dimension of time is also integrated into the Strategy Map, so if the NCs are connected to a date (likely at some point in the future), they should be placed in the Future column of the strategy map, while still being linked to the relevant CSF. If we are unable to define what is necessary for maintaining the Confirmed Success Factors, this may be a sign that they have not actually been confirmed/validated or perhaps that they are no longer relevant.
Define hypotheses to test explicitly: Potential Success Factors
Going back to the Cynefin framework, and looking deeper into the Unordered Domains, or the domains in which it is impossible to determine causality without uncertainty, we can recognize two different domains: Complex and Chaotic. In the Complex Domain, because we do not yet know what we don’t know, the path towards validating a Goal is never straightforward. Most of the time we have to understand and analyze our hypotheses and challenge our assumptions in order to figure out our next move. For this reason, the next step in the creation of an Agile Strategy Map is the definition of those hypotheses that might help us move towards the Goal. These hypotheses need to be made explicit, so that through transparency dependencies can be made visible. The primary purpose of declaring explicitly what could be helpful towards achieving the goal, is to identify changes or adaptations that can be used to our advantage. Ideally we would want to have many alternative hypotheses available, and we shouldn’t discard them right away. At this level a good set of 10 to 14 different hypotheses, would provide enough options to explore and avoid focusing only on the obvious ones. Hypotheses can be naive, or even completely stretched: as long as they are plausible and coherent, they are good. These hypotheses are captured using Potential Success Factors (PSFs). The name is a reminder that they are still to be validated.
A Potential Success Factor is expressed in the following form:
By <…> We expect <…> Which will help us <...>
Given the example of Goal: “Increase by 20% the number of annual mobile service’s customers”, an example of a PSF can be: “By creating new free services, we expect to attract more people to our platform, which will help us increase the potential for conversion into paying customers”.
PSFs are designed to be validated or invalidated through rapid experimentation. After they are validated, they will provide more insight into our strategy and increase or decrease the level of confidence in moving forward in one direction or another. If we feel confident about a PSF then it will eventually be converted into a Confirmed Success Factor (CSF). Once we have defined the PSFs, we visualize them underneath the goal to make them transparent and take full advantage of the visual capabilities of the tool. Since it is important to base decision-making on context, we have to make explicit which kind of hypothesis is described in each PSF: The Potential Success Factors either represent known unknowns (which then means we are in the Complicated domain), or unknown unknowns (in which case we are in a Complex domain).
Decide what to focus on
As we said at the beginning, if we want to be able to focus on small validated changes, we must decide which PSFs we want to work on first. Contrary to a more traditional way, we don’t want to actually prioritize the PSFs but rather make them smaller so that we validate their impact on the goal faster and more effectively. Every Success Factor (PSF or CSF) should have a Champion, who will work to build a cohort that can collaborate and focus on moving the PSF forward, and who will remain the Champion if the PSF becomes a CSF. The cohort is what we call an Improvement Squad, as its objective is to improve the organization and the work of everyone involved, not to mention the results, by exploiting new capabilities or leveraging existing ones.
Validate the hypothesis: Necessary Conditions
We need to find ways to validate our hypotheses as fast as possible, empirically, and without relying on assumptions that ultimately increase risk. This can be achieved by designing small, safe-to-fail experiments. Before getting there though, we need to identify what it is necessary in order to be able to define such experiments. What do we need to have in place or deal with in order to be able to validate the hypothesis? These may be things we need to change or implement, or they may be constraints that we must address in some way. These “necessities” will also be captured using Necessary Conditions (NCs) which should also highlight (in the Experiment Canvas capability of the Agile Strategy Map) what could go wrong if they aren’t fulfilled. This helps prioritizing and identifying dependencies. Once all the NCs have been fulfilled, we should be able to define one or more experiment(s).
A Necessary Condition may be expressed in the following form:
We need to <....> Otherwise <…>.
Given the example of the PSF above, an example of NC can be: “We need to create at least one additional free service in order to measure increased subscriptions, otherwise we won’t be able to understand the impact”, or “We need to measure existing conversion rates, otherwise we won’t be able to set an appropriate target and measure the increased conversion because of free services”.
In short, the Necessary Conditions will bring the strategy to a tactical level and allow operational work to start. They help in either validating a PSF, in planning the roll-out of a newly identified CSF, or in structuring the management of an existing CSF.
Relationships between Necessary Conditions and PSFs/CSFs/Experiment Canvas give different meaning to a NC depending on where it is visualized on the Strategy Map. Here is a summary table defining the meaning of each specific relationship.
Tip 1: If we see the pattern of a NC being applicable across multiple PSFs, we can have a reasonably high level of confidence that we will get a high return on effort if we manage to effectively address that condition. In this case it doesn’t matter in which order we tackle the Success Factors, because the first one will need to address the NC, and therefore the second one will need less work to move forward.
Tip 2: What level of granularity makes sense in the Agile Strategy Map? This is a very common question and there isn’t a clear answer. However, there are some considerations that can help answer the question on a contextual basis:
- If the level of granularity of Success Factors is too low, we might end up with uncertainty regarding whether we are dealing with a CSF or a PSF, because it might be both. To make it clearer, here is an example Success factor from a Car manufacturer: “Cars with low emissions are easier to sell”. “We learned from experience that this is true”, “We have data backing this fact”, “We know how to reduce emissions today”. The above three statements are verified. “We need to keep researching how to make cars more efficient in the future”. This is not verified and requires experimentation. We don’t know yet the how but we know that this might be important for continuing to sell. So how would we represent this on the Agile Strategy Map?
Option A: This could be a Confirmed Success Factor (known knowns) with a Necessary condition that states the need to review the technology every three months, which in turn could start a research initiative on the portfolio.
Option B: Break the CSF down into multiple and more specific CSFs, which highlight what is currently known, and a PSF for the hypothesis. Option A is preferable because this stays at a level where it avoids getting bogged down in technical details. It would also allow the same Champion and Improvement Squad to maintain control of what is known, but also keep growing the acquired knowledge so that it never becomes obsolete and irrelevant.
As soon as you have identified which are the Potential Success Factors you want to focus on, you pull those from the Future/Potential position to the Present/On going position of the Agile Strategy Map and start creating experiments to validate those hypotheses. To get quick feedback and make decisions, the recommended duration of the experiments is 4 to 12 weeks.
If we go back to Cynefin and complexity thinking, we can see that experiments in the complicated domain are meant to evaluate possible options, while experiments in the complex domain are meant to let new options emerge. Therefore, for the complicated domain, we run one experiment and validate it. When dealing with situations in the complex domain, we suggest running multiple parallel experiments, as the context in which the experiments are executed might change quite rapidly. By having multiple parallel experiments, we will be able to recognize recurring pattern(s) across those experiments, identify the possible catalysts that sustain those patterns, and finally validate that what we have identified are actual catalysts by testing those on all the experiments in parallel. This type of approach isn’t possible when running a single experiment. The quality of the situational analysis will also be greatly amplified by having multiple different datasets. The recurring patterns might lead to options (the identified catalysts) for which we want to define additional experiments, now in the complicated domain, in order to evaluate the most appropriate one(s). We use an Experiment Canvas, integrated in the Agile Strategy Map framework, to help articulate what are the things we need to know and measure when running an experiment.
Decide which experiments to start
With small validated changes in mind, we probably won’t start running all experiments at once, but decide which are the most appropriate to run first, pull them into the central column of the Agile Strategy Map, which is the present/validation column, and place the others in the future/potential column. The faster you can validate or invalidate your hypotheses, the earlier you will have an understanding of how to develop your strategy. In this phase more Necessary Conditions might emerge as preconditions for experimentation, depending on the level of complexity you are dealing with. As soon as you have fulfilled all the NCs required for the current experiments, there should be no further delays. Every experiment should have predefined success and failure conditions, as well as amplifying and dampening actions. Identifying those before you start helps you make validated choices without unnecessary interference and track progress over time. It will also help to empower the team which will run the experiment, by providing clear boundaries and suggestions on what to do when specific success or failure conditions are met.
Reporting on experiments’ results
When running an experiment we don’t want to wait 8-12 weeks to assess and communicate if it was a success or a failure. You can instead visualize the real-time status for each experiment: Each time the experiment team decides that one of the success conditions in the experiment is fulfilled, they are empowered to tick it off. The same applies to failure conditions. This is mapped by a line moving upwards or downwards to indicate the level of success/failure over time, which can increase confidence in making decisions on how to move forward.
Agile Strategy Map Roles
The following roles connected to the Agile Strategy Map are not mandatory, but we have found them critical for the success of any strategic change:
Sponsor: The Sponsor is usually at the C-level or an executive leader. The Agile Strategy Map Sponsor is the person responsible for the budget the organization needs to invest in change. She advocates for the overall strategy and supports the Champions and the Improvement Squads in their initiatives. In some cases, depending on the size and complexity of the organization, we may form a Guiding Coalition of leaders who are responsible for dealing with large organizational constraints and insuring overall strategic coherence.
Champions: Each PSF or CSF has a Champion who advocates for it and ensures that it is getting the proper attention. They are usually a senior leader or an opinion maker, who can influence others and help create the proper environments for feedback and learning. Champions will recruit an Improvement Squad as they feel appropriate. All Champions together will form a team to collaborate on the overall strategy map, focusing on individual Success Factors as well as overall map design and movement.
Improvement squad: In most cases, the Success Factor Champion will need help to define and accomplish the NCs, design any experiments needed, or deal with constraints or prerequisites for an experiment to start. Each Champion should recruit an Improvement Squad, a cohort of people who can contribute to moving forward with the necessary actions. Notice that it is a Squad and not a Team because it will change composition over time, depending on what is necessary for supporting the change.
Experiment team: Once an Experiment Canvas is designed, a volunteer-based experiment team is formed to carry out the experiment. This team remains stable for the whole duration of the experiment. While they run the experiment, the Improvement Squad supports the process and monitors the outcome. The same experiment team may be able to run more than one experiment as long as they aren’t dependent on each other.
Evaluate and Validate
Collect data at regular intervals
Make sure the Strategy Map is visible to the whole organization and set up a system so that everyone can contribute. There are multiple ways to leverage the collective intelligence and cognitive diversity in your organization. For instance, create a straightforward way for anyone to give feedback on the strategy in terms of Goals, PSFs/CSFs, and NCs. The Improvement Squad discussed in “Roles” is an additional way to involve more people. They can visualize the activities related to the different NCs on a Tactical Board, which is both a way to move from strategy to operations and a very powerful information radiator.
Once the experiments have started, you should be able to collect up-to-date metrics regularly. This can happen at very fast intervals, or even in cycles of 1 to 2 weeks. The data should help us understand in which direction and at which speed the experiments are moving (Vector Tracking, as described above), which should allow us to make decisions faster.
In complex environments we have multiple safe-to-fail experiments/options for each success factor. Here, we are trying to understand what patterns emerge, so that we can start amplifying the good (those that give us the results we are looking for) and dampening the bad. Occasionally we discover unintended consequences or hidden patterns that impact parts of the organization or factors that we did not consider. We could end up solving additional problems in this way.
In complicated environments we gather data and evaluate the options. We can then decide if the Potential Success Factor can become a Confirmed Success Factor and how to close the feedback loop to check on the necessary conditions.
Observe the projects interfering as little as possible
We define amplifying actions and dampening actions before the experiment starts. Note that some experiments might be designed to fail, so in that case the “success conditions” will be about failing. The creation of these conditions and actions provides a set of enabling constraints with triggers to action, which helps create a safe-to-fail environment for the experiment team.
Validate the results and learnings
While experiments are running - particularly in the Complex Domain of Cynefin - we have to constantly monitor the emerging patterns. To be sure they are actual patterns, we need to evaluate their stability and validate their repeatability by identifying which enabling constraints can reproduce them. These constraints can take the form of catalysts, which can both amplify the effects of positive patterns, as well as dampen the effects of negative ones. Will these catalysts help to reproduce the positive effects we have observed during the experiment? How could we transfer those learnings and benefit to the organization as a whole? The answer to these questions will help us make decisions about whether to roll out the learnings or not. Remember that we are talking about a Success Factor, which should be leveraged to achieve our goal, so if we are unsure about it, then there is no benefit to rolling it out.
Engage with all relevant stakeholders
Engage with all relevant stakeholders and parties in the organization to initially set up the Agile Strategy Map and to understand the implications of a roll-out. Make sure all necessary preparation is complete before roll-out, so that the transition to the new system is as quick as possible. Use the stakeholders to support the transition and engage with all involved to increase acceptance and reduce resistance.
Roll out the change
By supporting everyone involved, finding out fast what works and what doesn’t, and providing support where problems arise, you will make your roll-out smoother and more effective. In this phase it is very important to handle all impediments promptly by ensuring through frequent meetings that they are removed as fast as possible to maintain momentum.
Download the full Agile Strategy Map document in PDF format.