Option Orientation with Reverse Wardley Mapping

At the start of the year Mike Burrows posted about an idea he called Reverse Wardley, with some background to where it came from. As one of the sources of the idea I thought I should say some more about my thinking that led to it. Mike has also called the approach Option Visbility, and in writing this post I am preferring the name Option Orientation. Taking a set of existing options, and orientating oursleves with them such that we know how we should move next.

To explain the origins, lets first make a disctinction between sensemaking and categorisation.

  • Sensemaking is where the data precedes the framework. We position a set of data in a blank space, and then draw lines around it.
  • Categorisation is where the framework precedes the data. We draw lines in a blank space, and then position data between the lines.

Cynefin is intended to be a sensemaking framework, and exercises such as Four Points Contextualisation are designed to use it this way by placing items on a blank canvas, relative to the four corners, before any lines are drawn around them. The question that seeded the creation of Option Orientation is whether we can consider a Wardley Map to be a form of categorisation, in that data is added to a pre-defined evolutionary framework? And if it is, what would it look like to use a Sensemaking approach to create a Wardley Map? Hence the original name Reverse Wardley.

I should be clear that I am in no way saying that Wardley Mapping needs improving. Nor am I suggesting that sensemaking is any way superior to categorisation. Both are equally useful in context. These were just thoughts that occurred to me while listening to Dave and Simon talk at their “Snowden/Wardley Masterclass” last December.

I voiced these thoughts and discussed the questions with Liz Keogh, who came up with the idea of integrating with Agendashift. As I posted in the Agendashift Slack channel which Mike’s post references.

Liz and I have just figured out how to use Wardley Mapping to create the Transformation Map. Muwahahaha.

The basic idea is to take the FOTO outcomes that get used in 4-Points, and re-use them in a Wardley Map, so the Transformation Map is more of a Wardley Map than a Story Map.

Vertical axis is “distance” from the customer.

Horizontal axis is ambiguity of solution (which may or may not relate to the Cynefin domains)

I recommend reading Mike’s post for his interpretation of that quote and how he applied the thinking.

Here’s the way I have facilitated it.

  1. Rather than starting with a Blank Wardley Map and add the items starting from the top of the valeu chain (i.e. most visible) down, we start with a blank canvas, and an existing set of previously generated items (e.g. Agendashift outcomes)
  2. The items are first moved onto the hoizontal axis in order of relative ambiguity.  First I’ll ask for the most abmigious to be placed furthest left. Then for the least ambigious to be placed furthest righ. Then another random item to be placed relatively inbetween. Then another, and so on, until all have been placed realtively.
  3. The items are then moved vertically in order of visibility to the customer (which can generate a good discussion about who that is!). First I’ll ask for the most visible to be placed highest up, keeping its horizontal postion. Then for the least visible to be placed lowest down, still keeping its horizontal placement. Then another random item to placed relatively, and another, and so on, always maintaining the horizontal placement.

Now we have an Option Orientation Map such as the one below, which was generated with a Miro (aka Realtime) Board. Sorry that its (intentioanlly) not readable. The details are client specific, and it’s the overall look and effect that I hope is more useful.

Given something like the above we can now ask some questions about it:

  1. Which items would we like to move up/down/left/right? We can annotate this on the map with arrows to show desired movement.
  2. How do the items relate to each other? We can draw links between items to show relationships.
  3. Which items should we choose to work on? We can circle and name important groups or themes.

Thus the map gives us the context to make some strategic decisions on what needs to be done next as part of a continuous transformation effort, and can be revisited over time to re-align and renew direction.

Blending Agendashift and the Four Disciplines of Execution

Immersion blending a fruit smoothie with strawberries, raspberries, bananas and almond milkI’ve blogged about my thoughts on Strategy Deployment and Agendashift (as well as how to use Agendashift with the X-Matrix) some time ago, and more recently I wrote about Strategy Deployment and the Four Disciplines of Execution. Over the last few months I have had the opportunity to combine the two models, and this post will give a high level overview of how I did that.

TL;DR: I used the various elements and activities in Agendashift to generate the inputs into the Four Disciplines of Execution.

Here’s a longer explanation.

  1. The Agendashift Discovery exercises Celebration-5W, True North and FOTO lead to the Plan an a Page, which provides a set of outcomes that can be used to identify and define the 4DX Wildly Important Goal(s). One (or more) of the medium or long term outcomes can be selected and refined to use the 4DX template “from X to Y by When”. It’s also worth noting that the short term outcomes can also give some guidance towards the 4DX Leading Measures (see 3. below).
  2. Then the Agendashift Exploration activities of debriefing the assessment, selecting high leverage prompts to work on, and using FOTO again, generates more outcomes which can be used as input to identify the 4DX Leading Measures. Selected short term outcomes, either from the Plan on a Page (see point 1. above) or from the assessment prompts, can be used to feed an ODIM exercise, moving from the Outcomes, to Decisions, to Insights and finally to Measures.
  3. Both the WIG (from 1. above) and Leading Measures (from 2. above) inform the 4DX Compelling Scoreboard as usual with no additional work needed from Agendashift
  4. Agendashift Mapping and Elaboration lead to Experiment A3s, which is where the seeds for action can be found and around which people collaborate on discovering and evolving their own solutions.
  5. Finally, the Agendashift Operation element is implemented with the 4DX Cadence of Accountability. The weekly (or more frequently if appropriate) meetings review status of the A3s, look at the current scoreboard, and agree actions for the following period. As Experiment A3s are completed, or the WIG and Leading Measures are progressed, new experiments and indicators can be identified and chosen.

The two approaches worked together almost seamlessly with only minor modifications to the core Agendashift workshops being needed to launch the Four Disciplines of Execution. This is something I tend to do anyway, as I have a preference to identify Evidence (as per TASTE) before exploring Tactics to minimise measures being influenced by confirmation bias.

Its definitely something I’ll try again and would recommend giving it a go. Let me know if you’ve had similar experiences.

 

Strategy Deployment and the Agile Industrial Complex

RozgwiazdaThere has been much debate online, and in particular on Twitter recently, about the imposition of Agile and the Agile Industrial Complex. See Ron Jeffries’ recent blog for more context. It’s an important topic. I have seen plenty of imposed Agile which I would call Incoherent Agile. Agile processes imposed as Best Practice without any coherence or alignment with the challenges that they are intended to be addressing. As a result the promised benefits aren’t realised, the people become demoralised and ultimately Agile is blamed.

I’ve refrained from getting directly involved the debate so far, but I do have a view, which I hope to explain here.

Lets first look at the idea of imposition. As usual, Cynefin provides a useful lens to look through with its four domains and associated forms of constraints.

  1. The Obvious domain has Rigid Constraints, which allow no freedom of choice
  2. The Complicated domain has Governing Constraints, which allow a little freedom of choice
  3. The Complex domain has Enabling Constraints, which allow a bounded freedom of choice
  4. The Chaos domain has No Constraints, which allow complete freedom of choice

When we impose something, we are effectively imposing constraints. Cynefin suggests that imposing no constraints will lead to Chaos, which we generally don’t want to happen (unless it’s an intentional, short and transitionary state). Thus imposition is not necessarily good or bad and it’s more important to consider the nature of the imposition in context, and whether we are imposing the right degree of constraint.

That leads to the question of what we are imposing in an Agile Transformation.

Much of the backlash against imposed Agile is a reaction to Agile imposed as a Governing or Rigid Constraint, where leadership decides which frameworks, processes or practices are to be implemented as the standard approach, leaving little or no room for variation or experimentation by the people actually doing the work.

This is exactly the sort of experience which led my interest in Strategy Deployment and the X-Matrix. It’s why I am a proponent of Agendashift and why I like the concept of the Engagement Model. I regard a Strategic approach to Agile Transformation as one where leadership sets Enabling Constraints, within which the solutions can emerge from the people closest to the problem.

Therefore, by choosing to use an Engagement Model, whether it be Agendashift, OpenSpace Agility or my own TASTE approach, I believe you are still imposing that Engagement Model on an organisation. The important distinction is that with an Engagement Model you are imposing Enabling Constraints. With Agendashift, those constraints have a strong focus on outcomes. With Open Space Agility those constraints come from the chosen theme or purpose. With TASTE, those constraints are defined by strategies and evidence.

All this means that we can impose Enabling Constraints, and invite people to participate within those constraints. That’s not to say that everyone should always be an agreeable participant. We don’t necessarily want everyone to be obedient and compliant. Engagement should allow for rebels and cynics to question the approach and keep everyone honest.

Much of the debate I have observed has been between Invitation as a force for good, versus Imposition as a force for evil. What I have hopefully shown is that the two are not mutually exclusive and that instead of arguing and fighting we should be working to help organisations impose the right levels of constraints and inviting people to collaboratively engage within them.

How to use Agendashift with the X-Matrix

I first blogged about my early thoughts on Strategy Deployment and Agendashift nearly two years ago after some early experiments with Mike Burrows’ approach. Since then I’ve learned more, become an Agendashift partner, and co-taught a couple of “Lean-Agile Strategy Days” with Mike in June and October last year.

More recently I used some of the elements of Agendashift during an X-Matrix workshop at Agile Gurugram. This is an overview of how I currently see the various pieces fitting together from the perspective of the Agendashift workshop sections: Discovery, Exploration, Mapping, Elaboration, Operation.

Note that this assumes some familiarity with both Agendashift and the X-Matrix.

Discovery – Where would we like to get to

There are two primary exercises: Celebration and FOTO (From Obstacles To Outcomes). The output of Celebration can be thought of as a True North – the higher intent which is guiding the change. Note that this is not to be confused with Mike’s own Agendashift True North. From that, the outcomes which result from of FOTO, and in particular the longer term ones, can be used to identify the X-Matrix Aspirations.

Exploration – Prospecting for opportunities

The Agendashift unbenchmarking report, which is generated from participants assessments can be considered a form of diagnosis (as per Rumelt’s Strategy Kernel of Diagnosis, Guiding Policies and Coherent Action). It helps the participants identify the critical challenges or opportunities for change. Thus the 2nd round of FOTO along with the subsequent Cynefin Four Points Contextualisation exercise, can be used as a way of identifying the X-Matrix Strategies by naming the important clusters and themes that emerge.

Mapping – Plans and priorities visualised

In the context of Agendashift, the X-Matrix can be considered to be an alternative to transformation map which is typically created. However, the exercise used here known as POWT (Prompts, Obstacles, What would you like to have happen, Then what happens) is still useful as a means of identifying X-Matrix Evidence. The granular outcomes generated can feed into ODIM (Outcomes, Decisions, Insights, Metrics) to convert them to items which can be used to indicate progress (or otherwise).

Elaboration – Framing actions, testing our thinking

At this point, the options for change being generated are X-Matrix Tactics. Instead of diving down straight into the details of Experiment A3s, an alternative is to use Backbriefing A3s as a way of maintaining coherence and grouping options together with similar intents. Also at this point we can complete the X-Matrix correlations (or contributions as I’m increasingly calling them) which is another way of testing that there is sufficiently messy coherence.

Operation – Change as real work

Finally, we have a populated X-Matrix and the Agendashift tools become part of the Strategy Deployment Catchball process to further encourage participation in, and consensus on, the continuing work of transformation.

The Agile Gurugram experiment of more tightly integrating the elements of Agendashift with the X-Matrix was successful enough to encourage me to look for more opportunities to explore the synergies further. One such opportunity will be a 3 day Agendashift + X-Matrix Masterclass with Mike in Brighton, October 9-11 (just before the Lean Agile Brighton conference on October 12). Tickets are now on sale, with limited early bird places!

And if you’re like me to run an Agendashift X-Matrix workshop with your organisation, please get in touch.

In the Lap of the Agile Gods

Luck

I’ve noticed a lot of conversation recently (mostly on Twitter) debating how prescriptive, or not, we should be when helping teams through an Agile Transformation (i.e. helping them use Agile approaches to be more Agile)? Do we tell teams exactly what to do initially, or allow them complete freedom to figure it out for themselves? Or something else?

Worshipping False Gods

During World War 2, inhabitants of Melanesian islands in the Southwestern Pacific Ocean witnessed the Japanese & Allied forces using their homelands as military bases for troops, equipment and supplies. The troops would often share supplies with the native islander in return for support or assistance. After the war ended and the troops left, it was observed that the islanders would make copies of some items and mimic certain behaviours they had witnessed. For example recreating mock airfields and airplanes. Not understanding the technologies which had brought the cargo, these rituals were an attempt to attract more from the spiritual gods they thought had originally granted them.

This practice became knowns as a Cargo Cult, and has taken on a metaphorical use to describe the copying of conditions which are irrelevant or insufficient, in order to reproduce results without understanding the actual context. Thus we get Cargo Cult Agile, where the methods, practices and tools of successful teams and organisations are copied, irregardless of the original context. What has become known as the Spotify Method is a prime example, as are other attempts to reproduce the approaches used successful organisations such as Amazon, Apple or Netflix.

Trying to be Gods

In the 11th Century, legend has it that then King of England Canute the Great went to the sea shoreline to sit on his throne and command the tide not to come in. Unsurprisingly his orders had no effect and the tide continued to advance. His intent with the piece of theatre was to show that even Kings do not have the power of Gods. He was not, as is often thought, delusional enough to think that he did have such power.

This delusion is known as the God Complex, where people believe that they have the knowledge, skills, experience and power to design and predict solutions to the challenges we face. Further, they refuse to accept the fact that they might be wrong. Thus we get the Agile God Complex, where Agile is imposed on teams and organisations by managers and consultants in the belief that it will solve all problems. If people would just do it right!

Daniel Mezick has also been referring to something similar as the Agile Industrial Complex. And for the Cynefin crowd, this is of course treating a complex problem as if it were complicated. And while the use of expertise is valid for complicated problems, it still shouldn’t be confused with having god-like power!

Leaving it in the Lap of the Gods

This leaves a potential quandary. If we shouldn’t worship false gods, and we shouldn’t try to be gods, what should we do? Leave it in the lap of the gods? In other words, should we just leave it to chance and hope people will figure things our for themselves?

This is where Strategy Deployment comes in to play; allowing solutions to emerge from the people closest to the problem. We don’t need to leave it in the lap of the gods because we can provide clarity of intent and strategic guidance which informs the co-creation of experiments. Thus we can deliberately discover what action we can take to TASTE success.

Put another way, we enable Outcome-Oriented Change. Mike Burrows has recently used this term to described his Agendashift approach, and the following definition nicely sums up for me how we should be help teams through an Agile Transformation.

By building agreement on outcomes we facilitate rapid, experiment-based evolution of process, practice, and organisation. Agendashift avoids the self-defeating prescription of Lean and Agile techniques in isolation; instead we help you keep your vision and strategy aligned with a culture of co-creation and continuous transformation.

Lean-Agile Strategy Days: An X-Matrix and Agendashift Fusion

PhotonQ-FusionI’m really excited by a new venture on June 7-8 with Mike Burrows. Its called Lean-Agile Strategy Days, and will be an opportunity for attendees to explore with Mike and myself how we can combine and synthesise the X-Matrix and Agendashift as approaches to Strategy Deployment.

From the event page:

We’ll be looking at strategy – how to engage people in its development, how to develop and test the thinking, and how to build habits of follow-through. You’ll be learning through practice, and at the same time participating in an exciting collaboration. Together, let’s discover how these important topics interact and amplify each other.

I’ve blogged previously about Strategy Deployment and Agendashift with my early thoughts on the relationship between the two. Since then have I become an Agendashift partner and attended Mike’s workshop as a participant. As we have chatted and collaborated a couple of things have become apparent.

  1. There is a huge overlap in our thinking and philosophy around how we approach helping organisations through change.
  2. There is a huge opportunity for more collaboration between people with similar philosophies but different ideas.

After Mike ran another collaborative Flow Days workshop with Patrick Steyaert earlier this year, we realised they had created a good way of taking advantage of both these points, and Lean-Agile Strategy Days was born. We hope that this grows into a series of events where different people collaborate to combine their ideas – co-operating rather than competing.

If you want to learn about Strategy Deployment, with either the X-Matrix, or Agendashift, or if you want to be involved in innovating ways of combining the two, then please join us. Super Early Bird price is just £535 + VAT until May 8th for two days of learning and discovery with myself and Mike.

Book now – we hope to see you there!

Agendashift, Cynefin and the Butterfly Stamped

The butterfly who stamped

I’ve recently become an Agendashift partner and have enjoyed exploring how this inclusive, contextual, fulfilling, open approach fits with how I use Strategy Deployment.

Specifically, I find that the Agendashift values-based  assessment can be a form of diagnosis of a team or organisation’s critical challenges, in order to agree guiding policy for change and focus coherent action. I use those italicised terms deliberately as they come from Richard Rumelt’s book Good Strategy/Bad Strategy in which he defines a good strategy kernel as containing those key elements. I love this definition as it maps beautifully onto how I understand Strategy Deployment, and I intent to blog more about this soon.

In an early conversation with Mike when I was first experimenting with the assessment, we were exploring how Cynefin relates to the approach, and in particular the fact that not everything needs to be an experiment. This led to the idea of using the Agendashift assessment prompts as part of a Cynefin contextualisation exercise, which in turn led to the session we ran together at Lean Agile Scotland this year (also including elements of Clean Language).

My original thought had been to try something even more basic though, using the assessment prompts directly in a method that Dave Snowden calls “and the butterfly stamped“, and I got the chance to give that a go last week at Agile Northants.

The exercise – sometimes called simply Butterfly Stamping – is essentially a Four Points Contextualisation in which the items being contextualised are provided by the facilitator rather than generated by the participants. In this case those items were the prompts used in the Agendashift mini assessment, which you can see by completing the 2016 Agendashift global survey.

This meant that as well as learning about Cynefin and Sensemaking, participants were able to have rich conversations about their contexts and how well they were working, without getting stuck on what they were doing and what tools, techniques and practices they were using. Feedback was very positive, and you can see some of the output in this tweet:

I hope we can turn this into something that can be easily shared and reused. Let me know if you’re interested in running at your event. And watch this space!

Strategy Deployment and Agendashift

Agendashift is the approach used by Mike Burrows, based on his book Kanban from the Inside, in which he describes the values behind the Kanban Method. You can learn more by reading Mike’s post Agendashift in a nutshell. As part of his development of Agendashift, Mike has put together a values based delivery assessment, which he uses when working with teams. Again, I recommend reading Mike’s posts on using Agendashift as a coaching tool  and debriefing an Agendashift survey if you are not familiar with Agendashift.

After listening to Mike talk about Agendashift at this year’s London Lean Kanban Day I began wondering how his approach could be used as part of a Strategy Deployment workshop. I was curious what would happen if I used the Agendashift assessment to trigger the conversations about the elements of the X-Matrix model. Specifically, how could it be used to identify change strategies, and the associated desired outcomes, in order to frame tactics as hypotheses and experiments. Mike and I had a few conversations, and it wasn’t long before I had the opportunity to give it a go. This is a description of how I went about it.

Assessment & Analysis

The initial assessment followed Mike’s post, with participants working through individual surveys before spending time analysing the aggregated results and discussing strengths, weaknesses, convergence, divergence and importance.

Strategies

Having spent some time having rich conversations about current processes and practices, triggered by exploring various perspectives suggested by the survey prompts and scores, the teams had some good insights about what they considered to be their biggest problems worth solving and which required most focus. Getting agreement on what the key problems that need solving are can be thought of as agreeing the key strategies for change.

Thus this is where I broke away from Mike’s outline, in order to first consider strategies. I asked the participants to silently and individually come up with 2 to 3 change strategies each, resulting in around 20-30 items, which we then collectively grouped into similar themes to end up with 5-10 potential strategies. Dot voting (with further discussion) then reduced this down to the 3 key change strategies which everyone agreed with.

To give some examples (which I have simplified and generalised), we had strategies around focussing collaboration, communication, quality, product and value.

Outcomes

Having identified these key strategies, the teams could then consider what desired outcomes they hoped would be achieved by implementing them. By answering the questions “what would we like to see or hear?” and “what would we measure?”, the teams came up with possible ways, both qualitative and quantitative, which might give an indication of whether the strategies, and ultimately the tactics, were working.

Taking the 3 key strategies, I asked small groups of 3-5 people to consider the outcomes they hope to achieve with those strategies, and then consolidated the output. One reassuring observation from this part of the workshop was that some common outcomes emerged across all the strategies. This means that there were many-to-many correlations between them, suggesting a messy coherence, rather than a simplistic and reductionist relationship.

Some examples of outcomes (again simplified and generalised) were related to culture, responsiveness, quality, understanding and feedback.

Hypotheses

Once we have strategies and outcomes, the next step is to create some hypotheses for what tactics might implements the strategies to achieve the outcomes. To do this I tweaked Mike’s hypothesis template, and used this one:

We believe that <change>

implements <strategies>

and will result in <outcomes>

With this template, the hypotheses are naturally correlated with both strategies and outcomes (where the outcomes already consist of both subjective observations and objective measures).

I asked each participant to come up with a single hypothesis, creating a range of options from which to begin defining experiments.

For example (vastly simplified and generalised!):

We believe that a technical practice

implements a quality related strategy

and will result in fewer defects

Actions

This as far as we got in the time available, but I hope its clear that once we have hypotheses like this we can start creating specific experiments with which to move into action, with the possibility that each hypotheses could be tested with multiple experiments.

Results

While we didn’t formally go on to populate an X-Matrix, we did have most of the main elements in place – strategies, outcomes and tactics (if we consider tactics to be the actions required to test hypotheses) – along with the correlations between them. Although we didn’t discuss end results in this instance, I don’t believe it would take much to make those explicit, and come up with the correlations to the strategies and outcomes.

On a recent call with Mike he described Agendashift in terms of making the agenda for change explicit. I think that also nicely describes Strategy Deployment, and why I think there is a lot of overlap. Strategy Deployment makes the results, strategies, outcomes and tactics explicit, along with the correlations and coherence between them, and it seems that Agendashift is one way of going about this.