The Agile Strategy Map
The Agile Strategy Map
While becoming more Agile, it is difficult for organizations to continue to use traditional tools. Learn more about strategy maps and short-term decisions.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Agile Strategy Map™ explained
published under Creative Commons License 3.0
While becoming more Agile, it is difficult for organizations to continue to use traditional tools to steer their business. Traditional yearly or quarterly planning, as well as long-term strategies are not sufficient to address rapidly changing market conditions. Moreover, it is becoming more difficult to stay up to date with the latest changes happening inside an organization and to make decisions based on the latest available information. This is not only due to the size of the organization and requires a continuous trade-off between feedback speed and accuracy of the information.
On the way towards becoming more agile, many organizations realize that the need to commit to decisions as late as possible, and to explore multiple options before committing to one option, is a fundamentally safer approach. Considering this scenario, and also with the intention of helping companies achieve growing confidence about their new potential during an Agile Transition, agile42 coaches have developed - out of their own need - the Agile Strategy Map™.
What is it?
The Agile Strategy Map™ is an Agile tool that allows a leadership team to align and coordinate their organizational continuous improvement efforts. It supports work on both the strategic level and the tactical level. The Agile Strategy Map™ provides a framework for designing an organization’s Strategy as well as visualizing and tracking progress and evolution. As such the Agile Strategy Map™ supports decision making, and, according to an Agile approach, provides a controlled and safe way to run experiments and learn from them, becoming a fundamental tool for organizational improvement.
Why another tool?
As agile42 coaches, we found ourselves trapped all too often in the belief that everything can be accomplished by finding out what to do and sorting it into a Backlog. We realized that when it comes to coordinating efforts which require interventions in multiple parts of an organization, with multiple interdependencies, it becomes very hard to use a linear tool — like a Backlog — to organize the work. Backlogs are tools meant to improve focus, and concentrating on one thing after another. In some situations though — and organizational development would be one of those — if you want to increase your chances to win, at least on the strategic level, you need to run multiple experiments in parallel and bet on multiple horses at the same time. Once you are clear about your priority and chances of success, then the Backlog will came in handy again.
When thinking about organizational change, we use the Agile Strategy Map to reflect on multiple dimensions. As we know, changing an organization entails more than changing processes or an organizational chart, and these types of dependencies should be more clearly visible. We needed a tool which will allow us to visualize multiple dependencies at once, support decision making based on options, and also consider dependencies.
Where does it come from?
The Strategy Map was born out of experience and is based on some well known theories:
- The Theory of Constraints (ToC) and in particular the work done by Eliyahu Goldratt, in defining the difference and the dependencies between Strategic long term aspects and Tactical short term aspects. We are referring in particular to the Strategy & Tactic Map, which allows us to visualize dependencies between elements important to achieve Success and the necessary preconditions that would lead to that success.
- The Lean Disciplines, in particular Defer Commitment, also known as “Decide as late as possible” or "The latest responsible moment". Through the visualization of the dependencies we also want to support the principle that decisions should be made when there is the greatest amount of knowledge available about a specific topic. Because of this we try to Create Knowledge and we try to do it as fast as possible by Delivering Fast, something which would allow us to validate our learning, as taught in the Lean Startup philosophy.
- The Cynefin Framework from Dave Snowden, and in particular the idea of using Safe-to-Failexperiments as probes to validate a system behavior, and drive change. Following the Cynefin Framework, this changes depending on the domain in which the system resides at any point in time: Simple, Complicated, Complex, Chaotic or Disordered.
All of these aspects have been used to create a tool which not only supports designing a Strategy, but also provides support in validating hypotheses for improvement, as well as tracking those improvements over time, while providing decision-making support.
The Agile Strategy Map™ is a toolset for defining a Strategy, identifying possible factors of success, and validating those factors and their impact in achieving the defined Goal. First things first, let’s introduce the Agile Strategy Map™ elements.
This is what you want to achieve. It is something which would represent a step forward between the current state and an ideal state defined by a higher level Vision. The Goal has to be something concrete, that can be measured in terms of being achieved or not. It is also important to relate the Goal to the existing current state, as improvement, rather than to external factors not directly influenceable by the organization defining the Strategy. For example, setting a Goal of ‘becoming number one on the market’ for a given market segment might be stimulating, but also dangerous, as the success in achieving that goal will be influenced by competitors and not only from one’s own organizational improvements. For this reason it would be better to express the goal as the improvement of some factors such as number of subscribers, users, paying customers, services… something like improving by 20% the number of paying customers, which in turn might convert to revenue stream changes, and also might bring your organization to achieve the first position in a specific market sector. So while being the best might be a motivating challenge, we can’t blame our organization for not making it if the competitors have been better than us. It would be like blaming someone for not winning the gold medal at the Olympics, and having reached only the silver one while still improving her own personal record.
Possible Success Factors (PSFs)
Once the Goal has been defined, we have to start formulating hypotheses about which Possible Success Factors (PSFs) would enable or accelerate the achievement of the defined Goal. At this stage you might be able to either identify a large amount of possible factors, or you might be fully convinced that there is a single simple thing which needs to happen for your organization to achieve the defined Goal. Both cases are extreme, but are exposing two problems: (a) you might not have the resources (time and money) to validate all these factors, and (b) at the same time, you might not know which one you would bet on without further analysis.
PSFs are designed to be validated or invalidated through rapid experiments. We will describe how this works later in this document.
Critical Success Factors (CSFs)
Once you have validated your hypothesis about a PSF, and you have verified that it has an impact on the achievement of your Goal, then you have to decide if that impact is significant enough to be considered a Critical Success Factor (CSF). While with PSFs we are testing a hypothesis, and we are trying to do it at the lowest possible cost, with CSFs we have to make investment decisions, and identify a plan to monitor these factors. If there is any action that we can take in order to improve the odds of a specific factor, then we will have to plan and track the dependencies between that factor and others, as well as visualize everything needed to fulfill it. Note in the example that the format for a CSF highlights the fact that a critical factor is a certainty, and not a possibility anymore.
Necessary Conditions (NCs)
For every Success Factor you need to identify the Necessary Conditions (NCs) which will allow you to either validate the hypothesis formulated (in case of PSF, through piloting and validated learning). Alternatively they will allow to highlight all the dependencies necessary in order to fulfill a given factor (in case of CSF, by implementing structures that would allow that success factor to be managed). These are the most common items you should find in your Agile Strategy Map, as they are the ones which are driving toward action. They represent the more tactical part of the map.
How to create an Agile Strategy Map™
Normally we suggest to start by following these simple steps:
1. Identify the Goal you want to reach: Ideally this Goal should be measurable in some way. The Goal should represent the step that you wish your organization to make within a defined period of time, and should be taken to your best knowledge in a direction that would fulfill the company Vision.
For example, consider “improving 30% new user subscriptions YOY”, that can be measured against an existing baseline. This will make the Goal more realistic.
2. Identify the Success Factors (both PSFs and CSFs): looking at the defined Goal, with the help and the expertise of your colleagues (normally by means of a facilitated workshop), identify the Success Factors that might help your organization reach the Goal. Some factors will inevitably be “known” and probably naturally associated with your Business model. These are probably common to many other organizations, possibly also your competitors. They need to be managed, but are not those which will make a difference: those which will allow you to perform better than the majority of the others in the same market segment. These factors will be called Critical Success Factors (CSFs) because their management is critical to your business goal, and you can’t afford to lose them on the way towards your Goal. At this point though, you might start identifying Possible Success Factors (PSFs) as new ways of differentiating your business, as well as innovating on existing field of expertise. These factors are called “possible” because you don’t know yet if they will turn out to be “critical”, and to find that out you will need to validate the hypothesis supporting their definition. Validating a PSF requires defining Pilot Projects that will allow you to validate the hypothesis of success that you identified through the PSFs. In case the piloting reveals that those are indeed “critical” factors for your Goal, then you will have to transform them into CSFs and start managing them. Normally we suggest to start with 8 to 12 factors that will help you structuring your strategy.
3. Identify the Necessary Conditions (NCs): The Necessary Conditions are bringing the strategy to a tactical level, and will allow operational work to start. They help in either validating a PSF, or in structuring the management of a CSF. Let’s try to describe one scenario at a time:
a. PSF: By definition, the “possible” success factor is something which is still hypothetical, and you are not sure it is an actual success factor, or you are not aware about the impact such a factor can have in achieving the Goal. In order to validate this hypothesis, and first focus on validating the factor and the relationship with the Goal, you want to focus on the minimal effort which gives you the fastest possible feedback. (The same concept is adopted in the Lean Startup to validate a Business Model, before investing money in scaling it). In this context, the NC will represent the Necessary Conditions that are REQUIRED to validate the hypothesis entailed in the PSF.
b. CSF: This represents a “critical” factor, meaning that it has already been validated as being very important to achieve your goal. Normally this validation is the result of having run some “pilot projects” out of a PSF, and successfully having verified the hypothesis, then transforming that PSF into a CSF. Otherwise the CSF can also come out of previous business experiences, or represent a known critical factor in the industry where the company operates. Given this context, the NC identify the conditions REQUIRED to achieve this success factor within your organization. This may include the infrastructure necessary to be able to measure the CSF, as well as the conditions needed to be able to leverage this factor. The same concept is adopted in the Lean Startup when it comes to validating whether a model can sustainably scale after having validated the business hypothesis.
Note: While success factors are preferably independent of each other, NCs will likely have dependencies. In fact you can keep on identifying what is necessary to have a NC to be verified, creating chains of NCs, till the point when one of these NCs would turn out to be actionable. Normally, in order to validate all the PSFs and CSFs identified you might want to create at least a couple of NCs for each of those. This process is very important, as the fact that you can define sensible NCs is a proof that the success factor has been well formulated and it is relevant.
4. Define priorities and highlight dependencies: at this stage you should have a well formed Agile Strategy Map™, with one clear Goal, up to 12 success factors (both PSFs and CSFs) linking to the Goal, and at least 1 level of NCs linking to the defined success factors. Now you need to focus on validating hypotheses, as well as making sure you can leverage the already identified CSFs. How would you prioritize your focus on the currently identified factors? Probably you are inclined to make sure the CSFs are under control first, and then you might want to start validating some PSFs, and see if you can find even more factors that you can leverage. Remember that focus is key. It is important to achieve certainty incrementally rather than parallelizing all the effort on all identified factors. Consider also that you intentionally limited yourself to work on the most important “12” for the moment, and as soon as you are done with some of them, you might identify others, and you also might want to drop some after you have learned that their impact will be minimal. Depending on your capacity, identify those factors you want to start with, and deepen the definition of the NCs, till the point that they become very close to actionable, meaning that someone in the organization would be able to execute some actions and validate the condition. (Think at this level as something more comparable to a User Story than a task.) In this process, it will become evident that some of the NCs are dependent on each other, not only in the natural flow of things that you are developing, but probably also between different success factors. This is normal as you are following common thinking patterns to approach all the factors, which might turn out to require common resources, or infrastructure. Take the time to reflect on these dependencies and link the NCs with one another, avoiding circular references.
5. Share and validate: now you have an Agile Strategy Map™ that will help you focus on the important things for your business as well as allow you to share the strategy with the rest of the organization and also with your partners. The map will provide great help and support in decision making at an operational level, as well as a structure for focused conversations. Sharing the map with the organization will serve as validation:
- On one side you will want to validate that the strategy is understandable, and also
- on the other side validate that the strategy makes sense, and the identified NCs are a good starting point
This is fundamental feedback to ensure that the Strategy won’t remain merely a nice artifact, but will actually be used to drive and support business decision throughout the organization. By sharing you are also opening the door to improvement and refinements, and while the success factors might remain stable over time (and probably for many colleagues too far reaching for their usual focus), the NCs will be often challenged and improved by those who will have the skills to execute on them.
By following these 5 steps, you will be able to build and improve your Agile Strategy Map™ over time, and react promptly to strategic changes, as well as to operational issues. The map serves as a bridge to actualize the connection between the overarching organizational Goal and the daily work of every person in the organization providing both support in decision making, as well as motivation by highlighting team and individual contribution to the organizational Goal.
How to use an Agile Strategy Map™
Now that you have created a map, and you should gain value from it in:
- Providing an effective way to share the strategy within an organization;
- Providing a powerful decision supporting tool;
- Providing a powerful alignment tool;
What else you can do with the map?. In this section you will learn how to use the Agile Strategy Map™ as a guiding tool to coordinate a variety of operational efforts, so to combine the strategic view with the tactical view in a very close loop. First things first, let’s remember that a well refined map should have leaf-level NCs which are “actionable”, meaning that someone can easily think about a sequence of actions required to validate the expressed condition (remember we mentioned that NCs might be close relatives with User Stories, more than with tasks). Now you want to start working on these NCs, and you want to track the progress and relate it to the Agile Strategy Map™ so to have a great overview and reporting tool. For this to happen, you will need to use an additional tool to track tasks progress, which we normally refer to as the Operational Board. This is nothing more than a specialized task board, which allows to track progress on specific NCs. You can make it as sophisticated as you wish, but simpler is better, at least for starting. Following the defined priorities on the PSFs and CSFs level, and honoring dependencies between NCs, you will have to identify which of those you can start working on. Now you can pull the NC you want to work with on the Operational Board, break that down into smaller tasks and then start working. You can report back to the Agile Strategy Map™ the status of completion of your work. Once the NC has been validated, then you can remove it from the Operational Board and also from the Map. Now have a look back to the Agile Strategy Map™ to check what’s next. In case you are not coming forward with one or more NCs you can visualize this on the Map as well to attract attention and prompt handling. Using this approach will allow a unique combination of focus - for the operational work - and overall view for the strategic work - and will enable rapid control over the progress, as well as prompt reaction to changes and impediments.
The Agile Strategy Map™ is a simple and yet powerful tool that will allow you to:
1.Share the organizational strategy with all parties involved and align;
2.Provide a decision-support tool for everyday operational work;
3.Provide a dependency management tool;
4.Relate strategy with tactics and visualize not only dependencies but also progress and issues;
Distributed free of charge in compliance with the Creative Commons License 3.0 (by: with attribution, nc: non commercial use, sa: share alike) and is intellectual property of agile42. Shortly means you can use it for free, you can’t resell it and you are required to share any further modification with the same license format.
Opinions expressed by DZone contributors are their own.