The Agile Strategy Map™ and its background

The Agile Strategy Map is a way to map and design the changes in an organization in a way that makes the process transparent, incremental, available to everyone, and based on continuous experimentation and adaptation. This framework has been developed by agile42 through our experiences with clients and the help of many coaches who contributed over time to refine and improve its usability.

Agile teams deliver in small and frequent increments

One of the strengths of any team or organization working in an agile way is their capability to deliver value in frequent iterations and in smaller increments. This capability has significant advantages compared to a more common “large batch” approach. First of all, it allows teams to go through the problems they will face from top to bottom and deal with all technical and functional difficulties very early. Moreover, it enables faster feedback loops, which contribute to maintaining focus and directing the team towards what matters to customers and stakeholders. 

Agile vs

In a nutshell, this means that working with smaller and frequent releases significantly helps reduce business and technical risk, by delivering what the customers expect and constantly ensuring that we are using the appropriate technical approach. Moreover, the frequent release of value-focused increments also helps mitigate social risk, by fostering the need for collaboration and trust between team members from the early phases, which avoids stress down the line. Finally, the frequent involvement of customers and stakeholders allows teams to better control both costs and value delivered and enables better expectations management and an agreement on what to invest in next, reducing cost and schedule risk. These benefits apply whether we are developing a new product or introducing an organizational change. 

Engaging people with a change initiative

The advantages of an agile approach have often led to Agile being considered as a goal in itself rather than a means of achieving your business goals. Even if this problem is known in theory, in helping many organizations start the journey towards becoming more agile, we have often seen a push towards “making the organization agile” in practice. 

When the Agile Manifesto was written, the underlying thought was never about working faster, or being more efficient, or writing more code lines per hour. In fact, the manifesto tells us quite the opposite, by proclaiming the importance of achieving what is called a “sustainable pace”. This is of course relative to the context and the people involved, and it is something to aim for, not a given, or something that can be calculated, exploited, or standardized across an organization. Every team will normally find their own sustainable pace over time, a working speed at which nobody feels stressed, but also not too relaxed. (This speed is, by the way, something you measure, not something you define before you start). The idea of the sustainable pace also has to do with the capability to sustain that pace indefinitely. This last element is quite important, as in most organizations the belief that we can push people to work above their capacity, even if just for a while, seems to be accepted as the norm. 

Pushing people in general is not a good choice, in particular when we are dealing with knowledge work. It has been demonstrated that when working under stress, our brain capabilities degrade significantly, and a significant reason for people working over capacity is being planned on multiple projects. Under stress, the part of our brain that takes control is the instinctive one, also known as System 1 Thinking. System 1 is very efficient, but not very flexible, and normally resorts to known patterns and mechanical reactions to known “threats”. When we need to be creative, we need the slower part of our brain to work for us, which is part of System 2. This is the part that is in charge of our analytical thinking, of our dreaming and creative ideas, the one that allows us to invent new things, instead of efficiently processing known ones.

If we understand the deep connection between the constraints and structures that we build into an environment, and the behaviors these structures produce - in terms of human reactions to stressors - then we will want to make sure that changes happen without too much pressure. Even though we all know the benefits of working without pressure, or after a good night’s sleep, as soon as we are again in an environment where we are pushed to do things fast, we inevitably fall back into compliance mode and retreat into behaviors and habits that are typical of our traditional way of working. 

Let’s assume for a moment that your organization is willing to go through a change initiative, and the benefits are perceived as so valuable that nobody doubts that it will be worth pursuing. Even in this hypothetical and very unlikely thought experiment, how much could we resist pushing people through it, instead of allowing people to internalize the change at their own speed and co-evolve with the system? Since we know the answer, we feel that allowing people to move towards accepting the change, as a first step, would be a waste of time. 

This is the moment when, instead of being supportive and respectful of everyone’s need to understand and adapt, we inadvertently begin generating what we call “resistance to change”. Continuing with our thought experiment, what if we were able to share a common and measurable goal that everyone would understand and would be willing to pursue over time? What if, instead of telling people what to do, we would allow them to try safe-to-fail experiments geared toward achieving that goal? Based on the results of these experiments, we would encourage people to share their approaches and replicate these conditions across the whole organization. As crazy as it sounds, you will be surprised about how much faster and more sustainably these changes will grow within your organization. 

Back to reality, we all know that finding ourselves in a situation in which everyone within an organization, no matter the size, agrees to change or to a common approach to change is very rare. This next section is about identifying ways to create the sense of urgency that will allow us to initiate change. Instead of making it explicit, or a mandate, we will explore ways in which it can emerge by analyzing common needs or dissatisfactions. Any change requires a motive, and this motive needs to be internalized by as many people as possible in order to make the change not only accepted, but also thoroughly lived. In this way we can also avoid the risk of local optimization, which can be a result of naive efforts to increase local efficiency, rather than focusing on client value delivery by taking the client or market perspective. We want to find ways in which we can engage step by step the whole organization, and align it behind a common agreed direction.

Managing uncertainty through experimentation

The idea of experimenting is quite interesting and engaging for most of us coaches, but it is more often than not a tough sell for leadership teams within organizations. It is really hard to convince hard driven managers, with targets and deadlines, to experiment on something without knowing what the outcomes will be. It ultimately boils down to one of the hardest things to accept: uncertainty. When talking to top managers and C-Level people instead, the level of acceptance is much higher due to their natural predisposition to keep multiple options open. Paradoxically, it is easier to sell top managers a portfolio of safe-to-fail experiments with different probabilities of success and a clear strategy to manage the risk, than to discuss starting or not a single experiment.

A not so new approach to risk

Nowadays it is very hard to base our risk management strategy on robustness, in this case predicting and preventing failure. Risk used to be visualized as a bell curve, which makes its management complicated and slow, by focusing on what lies inside the bell curve alone. Rare, one-off events (Black Swans, in Nassim Nicholas Taleb’s terminology) are impossible to predict that way, and are therefore especially destructive — they have a greater impact. If we rely on what we think we “know”, what will potentially hit us the most is what we actually don’t know, or what we think we know just “ain’t” so. By accepting the possibility of failure, an organization can instead orient its strategy towards early detection, fast recovery and fast exploitation. Statistical techniques are still valuable for probable events, and simulations and scenario planning allow us to gain some clarity in the realm of possible events, but when it comes to the enormous number of plausible events, we need to use abductive logic to draw connections between multiple events and seeking coherent (but not necessarily true at this point) explanations. 

In order to broaden the spectrum of options available and to be able to discover what might help and what not, we need to approach risk management as a whole in a more experimental way. Focusing on probability alone will not work; we will have to learn what is possible and what is plausible. We can formulate hypotheses based on intuition, but those hypotheses will not be used to make decisions, but rather to start multiple parallel experiments to validate those hypotheses. This approach requires us to be open to observing and listening to everything that happens, especially if it is unexpected.

The comprehensive framework of the Agile Strategy Map has proven to serve as a good catalyst for change and coordinating multiple, parallel experiments. 

Roots of the Agile Strategy Map

Now we have learned something about incremental and iterative change, we have learned something about the importance of initiating change from the customer’s perspective, and about engaging people within the organization from the early stages, so that the need for change will emerge and will start to be “pulled” by volunteers who feel close to the improvements and feel they can contribute. We have also described the possibility of evolving incrementally, and using an experimental approach to validate hypotheses before getting started. These options are all built into the Agile Strategy Map. This framework has been developed through our experiences with clients and the help of many coaches who contributed over time to refine and improve its usability. 

The Strategy Cycle

Agile Strategy Map’s origins are rooted in Eliyahu Goldratt’s “Strategy and Tactics Tree”, a thinking process codified in his Theory of Constraints. This provides a model for aligning and synchronizing continuous improvement. The Agile Strategy Map tool evolved into a framework that can be used in multiple circumstances: it helps with maintaining coherence towards a common goal, aligns everyone on the current state of affairs, and allows us to straightforwardly track dependencies. It also merges strategic priorities with tactical and operational needs, allowing for a more focused approach. 

Additionally, the work of Peter Senge, presented in his book The Fifth Discipline, the Art and Practice of a Learning Organization, has been a significant influence. Validating change in small increments is essentially about building a culture and discipline of learning, rather than simply defining a plan that we presume will result in achieving our Goal. To quote Senge, “In the long run, the only sustainable source of competitive advantage is your organization’s ability to learn faster than its competition.[…] If there is one single thing a learning organization does well, it is helping people embrace change”. Furthermore, Senge’s “Wheel of Team Learning” provides a simple way to consider the process of collective learning and reflects the set-up and running of the Agile Strategy Map: we identify shared needs and goals (Shared Meaning, in Senge’s terms), co-create the Agile Strategy Map (Joint Planning), agree on validating through collaborative actions (Coordinated Action) and make it transparent for all to see (Public Reflection). 

This is not the first iteration of the Agile Strategy Map, so you might already be familiar with one of its previous versions. We have been using it for many years with multiple clients and have learned through these experiences. Common feedback included challenges of the map being too abstract or being difficult to understand how to take action based on it. Other feedback has included a sense that the organization feels like they need to start from scratch, ignoring things they’ve done in the past. As part of the response to this feedback, we have recently incorporated the work of Simon Wardley into the conception of the Strategy Map. The inclusion of new elements, such as Confirmed Success Factors (explained below) also goes a long way towards addressing these concerns.  By combining the thinking of Wardley with the strategy mapping tool, we believe we have significantly enhanced its expressivity and its ease of use. 

Wardley speaks of real maps not only being visual and context-specific, but also showing positioning in relation to an anchor and movement. Many things that we use and call maps in the workplace are not maps at all, lacking at least one of those elements. If they don’t include an anchor (that would be the North on a geographical map) to support clear direction and positioning to show us where we are in relation to other elements on the map, then how can we use the map to orientate ourselves? Wardley has combined the thinking of OODA loops (the decision-making cycle of observe, orient, decide, and act) from military strategist John Boyd and “The Art of War” from Chinese general Sun Tzu (VI-V century b.C.) to create a basic cycle for thinking about strategy.

Using this cycle we begin to see that the strategy changes based on the needs and the maturity of the market and where we want to go next. This has of course a significant impact on the way organizations are structured and operate.

Strategy tools

To sum up, based on Wardley’s insights, good strategy tools are:

  • Visual → easy and intuitive
  • Context specific → relevant to the context (different parts of the business might have a different strategy or different products and it is important to know what is universally applicable and what is not) 
  • Positional → displaying connections  and current state to help navigate the map
  • Anchor → acts as a reference for direction
  • Movement → suggested changes and where are we going / where have we been
Characteristics of good strategy tools

See how to put the Agile Strategy Map in action.

PDF icon Download the full Agile Strategy Map document in PDF format.