Constraints and Cynefin

Posted on December 9, 2019 by

A short reminder of Cynefin and the difference between domains:

  • Obvious situations can be categorized and have fixed constraints.
  • Complicated situations can be analyzed and have governing constraints.
  • Complex situations can be probed (trying something out that’s safe-to-fail) and have enabling constraints.
  • Chaotic situations require you to act, and have no constraints.

The fixed constraints of the obvious are easy to understand. Think of putting a plug into the wall. There’s really only one way to do it, and it’s very hard to get it wrong!

Chaos is caused by a lack of constraints; meeting constraints will cause it to dissipate. Think of fire burning until it runs out of fuel or oxygen. This is what makes Chaos transient and short-lived; it will rapidly grow until it meets constraints, at which point the situation resolves (but not necessarily in your favour).

Robust constraints

In complicated situations, the governing constraints provide limits to what can be done. In terms of our policies and processes, these are hard-and-fast rules. They are context-free, which means they apply to everything, regardless of context.

In one of his later articles on constraints Dave Snowden refers to governing and fixed as robust constraints, which survive by becoming stronger and which, when they fail, do so catastrophically. Think of things which snap, shatter, or result in someone being immediately fired.

Resilient constraints

Enabling constraints, though, are contextual. That means that they can be adapted or escaped for context. In policy and process terms, they’re guidelines or heuristics. Dave uses the analogy of a salt marsh, as opposed to a sea-wall; the water is contained, but can gradually permeate the marsh.

Enabling constraints are resilient. That means that when they break, you usually get a bit of warning, or the impact is small to start with.

Coupling (connecting) and Containing constraints

Resilient and robust constraints can both be either connecting or containing. A connecting constraint is one which holds things in place without limiting them; a tether or an attractor. A containing constraint keeps things in one place without centering them; limiting or guiding them.

Disorder and Constraints

Disorder often occurs accidentally when we’re using the wrong kind of constraints for the situation.

For instance, think of the difficulty of getting innovative work done when you’re at a highly regulated big bank with all of its processes, its governance and change control!

Or alternatively, think of what happens when you fail to obey the safety notices or read the instructions, treating something as if it’s safe-to-fail when it isn’t.

Using the wrong kind of constraints – treating something complex as if it’s complicated, or vice-versa – is a form of disorder, and when disorder persists, it usually results in chaos.

Creating Probes around Constraints

Wicked, complex problems are often hard to solve directly, and they’re usually made up of combinations of human behaviour, and the constraints within and around which we act, whether complex or complicated.

By looking at the ecosystem of constraints – all the processes in place, and all the rules and guidelines and legacy that help us or hinder us – we can consider whether relaxing or tightening constraints might produce a beneficial outcome. That relaxing or tightening can become a probe.

In complex ecosystems, especially human ones, be careful! Dark constraints – things which cannot be seen, but the effects of which can be felt – are often cultural, and changing things can cause unexpected side-effects. Remember to check that it really is safe-to-fail!

Posted in cynefin | Leave a comment

A Probe by Any Other Name

Posted on November 20, 2019 by

In complexity (new stuff is complex) we prefer to probe; which means to try something out that’s safe-to-fail.

Knowing things are failing or succeeding relies on feedback loops; but who do we get feedback from? And what do we do with it?

There are a few different terms for different kinds of probes in the industry, so I’m writing down my thoughts here about each kind, from the PoV of someone in the development team. These aren’t hard-and-fast rules; if you have different naming conventions that’s probably OK.

Spike – demonstrates to us (the team) that something is possible.

Prototype – demonstrates to someone else that something is possible.

Alpha – gets feedback from real users / customers on value. Fix showstoppers; keep track of other bugs.

Beta – gets feedback on readiness to release. Fix bugs.

Release – provides value, even if in a limited context. Fix bugs urgently.

One of the most common problems I see is a mismatch between what the team, the PO, the business and other stakeholders all think people are working on.

Chris Matts explained a phenomenon to me called “signalling intent”. It’s what happens when you intend to explore or open up an option, but instead you accidentally communicate a commitment.

For instance, let’s say you work in a very casual office. Shorts and flip-flops are the norm. You get a call from an engineer at Avogadro Corp (side-note: read this book; it’s really good). It seems like it might be a fun conversation; even if you aren’t looking to jump ship, it would be a shame to waste the chance to find out more. So you turn up in the morning dressed smartly, ready for your meeting in the afternoon.

But your team-mates and managers have noticed. They think you’re going for an interview. Your lightweight probe is interpreted as a commitment; they think you’re about to jump ship. Their behaviour changes as a result.

When a perfectly lightweight probe is miscommunicated as a firm investment or commitment, people start aligning around it (positively or negatively) until it becomes the only option available. At that point it’s no longer safe-to-fail.

So if you’re thinking of trying out a probe, consider how you’re going to communicate it, both internally and externally, to the team, or to the leaders, or to the customers.

And if you are a leader, consider how you’re asking for the probe in the first place. If it’s an experiment you want, tell your people. Clarify your intent about the level of feedback you’re looking for, and the extent of the commitment you’re willing to make, in time or money or social capital, however small.

The alternative is disorder, and the inevitable chaos that results.

 

Posted in cynefin, feedback, real options, Uncategorized | 2 Comments

Scenarios using custom DSLs

Posted on August 27, 2019 by

One of my clients recently asked me how often I use Cucumber or JBehave in my own projects. Hardly ever, is the answer, so I want to show you what I do instead.

The English-language Gherkin syntax is hard to refactor. The tools form another layer of abstraction and maintenance on top of your usual code. There’s a learning curve that comes with them that can be a bit tricky. The only reason to use the tools is because you want to collaborate with non-technical stakeholders. If nobody outside your team is reading your scenarios after automation, then you don’t need them.

There may still be other reasons you want the tools. They’ll be more readable than the code I’m about to show you. Dynamic languages are harder to refactor anyway; I work primarily with static typing. Maybe you want to take advantage of hooks for your build pipeline. Maybe you already know and feel comfortable with the tools. Maybe you just really want to learn the technique. That’s OK. But you don’t need them.

So here’s a simple alternative.

Have some conversations, and write down the examples.

I like it when the developers do this, and get feedback on their understanding. Writing it in semi-formal Gherkin syntax is pretty useful for helping spot missing contexts and outcomes. All the usual goodness of Three Amigos conversations still applies.

Find a capability, and the thing that implements it.

Your application or system probably has a number of things that it enables people or other systems to do. We’re going to be using a noun that matches those things as a way of starting our DSL. Here are some examples:

  • Buying things -> the basket
  • Making trades -> a trade
  • Commenting on an article -> a comment / the comments
  • Doing banking -> the account

You may find the language is a bit stilted here (I did say the English was clearer!) but that’s a trade-off for the ease of getting started with this. You might find other things which make more sense to you; it’s sometimes possible to use verbs for instance.

  • Searching for a car -> I search

You’ll get the idea in a moment. Each of these is going to be the stem of a bit of code.

Start with comments in the code

Sometimes I like to just start with my scenario written in comments in the code. For each step, think about whether the step has already happened, is the thing that triggers some interesting behaviour, or is the outcome of that behaviour. Add Given, When or Then as appropriate:

    // Given an article on Climate Change
    // When I post a comment "This is a really conservative forecast."
    // Then it should appear beneath the article.

Add the Given, When or Then to your stem, and…

  • Given the basket…
  • When the trade…
  • When a comment…
  • When a search…
  • Then the account…

…construct your steps!

Now we’re in code.

GivenAnArticle().on("Climate Change")

GivenTheBasket().contains("Pack of Grey Towels")

WhenTheTrade().isCreated()
    .withCounterparty("Evil Corp")
    .forPrice(150.35, "USD")
    .....
    .andSubmitted()

WhenISearch().For("Blue Ford Fiesta")

ThenTheAccount().shouldHaveBalance(15.00, "GBP")

You can see that trading one is using a builder pattern; each step returns the trade being constructed for further changes, until it’s submitted. I sometimes like to use boring, valid defaults in my builder so that these steps only call out the really interesting bits.

I normally suggest that a “When” should be in active voice; that is, it should show who did it. If that’s important, add the actor.

WhenTheTrade().isCreated()
    .....
    .andSubmittedBy("Andy Admin")

or

WhenTheTrade().isCreated()
    .by("Andy Admin")
    .....
    .andSubmitted()

Active voice would normally look more like:

When("Andy Admin").createsATrade()
    ....
    .andSubmitsIt()

But now our “When” is ambiguous; we can’t tell which kind of capability we’re about to use, so it makes it really, really hard to maintain. It’s OK to use passive voice for DSLs.

As I construct these, I delete the comments.

Sometimes I like to just put all the detailed automation in which makes the steps run, then remove the duplication by refactoring into these steps. (Sometimes it’s enough just to just leave it with detailed automation, too, but at least leave the comments in!)

Pass the steps through to Page Objects; use the World for state

You’ll probably find you need to share state between the different steps. I normally create a “World” object, accessible from the whole scenario.

Each of the stems you created will correspond to one or more page objects. I like to keep those separate, so my steps in the DSL don’t do anything more than just call through to that object and return it.

Here’s an example of my scenario object for a Sudoku solver:

public class Scenario
{
        private readonly SudoqueSteps _sudoqueSteps;
        private readonly CellSteps _cellSteps;
        private readonly HelpSteps _helpSteps;

        private World _world;

        protected Scenario()
        {
            _world = new World();
            _sudoqueSteps = new SudoqueSteps(_world);
            _cellSteps = new CellSteps(_world);
            _helpSteps = new HelpSteps(_world);
        }
        
        protected CellSteps WhenISelectACell{ get { return _cellSteps; }}

        protected CellSteps ThenTheCell{ get { return _cellSteps; }}

        protected SudoqueSteps GivenSudoque{ get { return _sudoqueSteps; }}
        
        //...

        protected HelpSteps WhenIAskForHelp { get { return _helpSteps; } }

        protected HelpSteps ThenTheHintText { get { return _helpSteps; } }
}

It does get quite long, but it’s pretty easy to maintain because it doesn’t do anything else; all the complexity is in those underlying steps.

And here’s how I use it:

    [TestFixture]
    public class PlayerCanSetUpAPuzzle : Scenario
    {
        [Test]
        public void APlayerCanSetUpAPuzzle()
        {
            GivenSudoque.IsRunning();
            WhenISelectACell.At(3, 4).AndToggle(1);
            ThenSudoque.ShouldLookLike(
                "... ... ..." + NL +
                "... ... ..." + NL +
                "... ... ..." + NL +
                "           " + NL +
                "... ... ..." + NL +
                ".1. ... ..." + NL +
                "... ... ..." + NL +
                "           " + NL +
                "... ... ..." + NL +
                "... ... ..." + NL +
                "... ... ..." + NL);
        }
    }

Full scenarios here.

This one was written in plain old NUnit with C#. I’ve done this with JUnit and Java, and with JUnit and Kotlin. The examples here are only from toy projects, but I’ve used this technique on several real ones.

There are lots of tools out there which help you to construct these kind of DSLs; but I’ve found they also come with their own learning curve, constraints, maintainability issues etc.. This is a pretty easy thing to do; I don’t think it needs anything more complicated than I’ve put here.

It’s also very easy to refactor overly-detailed, imperative scenarios, of the kind created by lots of teams who didn’t know about the conversations, into this form.

It’s easy to move to the BDD tools if you need them.

With your Page Objects already in place, it’s pretty quick to get something like Cucumber up and running and make the step definitions call through to the page objects exactly as you were before, with just a little bit of refactoring of method names.

It’s a lot harder to move from Cucumber and regex to a DSL.

Chris Matts once had some great wisdom. “If you don’t know which technology to choose, pick the one that’s easy to change. If it’s wrong, you can change it.”

This is the one that’s easy to change, so I tend to start with this. And sometimes it doesn’t need to change.

 

 

Posted in bdd | 9 Comments

Off the Charts

Posted on July 2, 2019 by

If you’re following me on Twitter, you’ll have noticed that the amount I’m talking about the environment and climate change has ramped up recently. I want to explain why, and why this is probably the most important blog post I’ve ever written.

For GOTO Amsterdam, the organizers asked if I could talk about the 4th Industrial Revolution (I may write a blog post on that later). While I’m familiar with the concepts in the 4th (possibly actually the 6th) IR, I needed to know a little bit more about the history of Industrial Revolutions in general to make a good talk. So a few months ago, I started researching.

Iron and steam. Steel forges and railways and ocean-going ships. Electricity and telephones and computing and the technology age that we now currently enjoy. Movement and machinery and connectivity. The automation that started with the textile mills of the UK has spread world-wide.

It all needs power. Lots and lots of power. Those of us in the tech industry use a hell of a lot of it; in our work, our play, and our travel. Our computers and the internet require power. Those hot laptops and graphics cards are evidence of how much power we use. The aircon that keeps our offices cool. Our cars, our flights, the industry that makes our phones and tablets and all the other tech…

It all needs power.

So I started researching the effects of that power.

I hadn’t actually read the IPCC’s report before. There’s a summary of it for policymakers that’s a bit long.

Until this year, I figured the policymakers had probably read it. They had to be working on something that was appropriate for the urgency, right? But the Extinction Rebellion movement keeps growing… is it just people panicking over nothing, or is that sense of urgency really justified? Does Greta Thunberg, the 16-year-old who’s spoken most passionately about her own future, really mean it when she talks about the collapse of civilization as we know it?

Well, the IPCC’s got some nice pictures to make it easy for us. Here’s two of them. They’re on page 11 of that summary I’ve already linked.

IPCC report: How the level of global warming affects impacts and/or risks associated with the Reasons for Concern (RFCs) and selected natural, managed and human systems

So this is why they’re asking us to stay below 1.5C.

I thought 1.5C might be, you know, kind of OK. But it turns out even at 1.5C we’re destabilizing the arctic (bye-bye, polar bears), probably the Western Antarctic ice sheet, losing most of the warm-water corals with their rich ecosystem, turning some places into famine-stricken deserts, and flooding others. You know, more than they already are. You can see the grey bar representing 2006-2015 on that chart.

1.5C turns out to be… still pretty bad.

At 2.0C, as well as the effects being horribly red-looking across the board, we’re entering that place where the feedback cycles start kicking in. You know, more than they already are. Here’s a picture from ClimateVictory.org that shows the basics of what that looks like.

So we’d really, really like to stay below 1.5C if we can, because 2.0C is not looking good. 2.0C is looking, well, pretty devastating.

So how are we doing?

Here’s the Independent’s report, based on a number of existing models. I’m just going to quote it, because there’s a key phrase in there, and the fact that it exists is ridiculous.

Based on lack of meaningful global action to rapidly extinguish all greenhouse gas emissions within the next decade, the authors sketch out a scenario in which global emissions peak in 2030.

In this case, using several existing studies, they hypothesise average global temperatures may reach 3C above pre-industrial levels by 2050.

Scroll back up. Can you see 3C on those charts?

I think that’s the point where scientists just throw their hands up and beg everyone to grow the f&*$ up. Actually, that’s Bill Nye doing that, right there. And you can hear everyone laughing, because Bill Nye swearing is incongruous with his normally family-friendly presentation and incongruity makes us laugh, but it isn’t funny. It isn’t funny at all.

3C is off-the-charts catastrophic.

And we’re looking at 5C by the end of the century, at least. 5C’s unimaginable. At 5C and above, things start to get apocalyptic. If it isn’t an existential threat for humans entirely then it will certainly, as Greta Thunberg says, be the end of civilization as we know it. António Guterres, the Secretary-General of the UN, said this week that “We are in a battle for our lives.”

What does that look like?

We’ve already started to see it. It looks like Chennai, India’s 6th biggest city, running out of water. It looks like police using tear-gas on peaceful protesters, in a country where the temperature hit 45C this week. It looks like animals going extinct, at a rate that’s faster than anything since the meteor impact wiped out the dinosaurs. It looks like insects disappearing and the failure of ecosystems world-wide that results.

It looks like that, only more, and worse, everywhere. Oh, and the sea-level rise will cause storm-surges (which will be more frequent) to flood most coastal cities, and probably London too.

So what do we do?

1. Change your personal priorities.

Most of us who are environmentally-minded are used to thinking, “How can we live our life the way we want, and still be kind to the world?”

We need to change this round. “How can we be kind to the world, and still live our life the way we want?”

That means doing whatever you can, even if it makes you uncomfortable. Take the train instead of flying. If you have to fly, carbon-offset your flights. Carbon-offset everything. This site by fellow coach Henrik Kniberg and friends, GoClimateNeutral.org, makes it easy.

A zero-carbon world doesn’t have to be an awful one. The more we invest in it, the more the infrastructure around it changes to support it, and the easier and cheaper it gets… and the more normal it gets, until hopefully the outliers are shamed into joining the rest of us.

2. Make a difference, or support people making a difference.

Join the protests. If you can’t join the protests, fund the protests. If you can’t fund the protests, facilitate a workshop for them or help out with a website or even just offer a bit of moral support. (Shout-out to Sal Freudenberg for her inspiration; she will have even more suggestions.)

Plant a tree. Change providers. Use green electricity. Get an electric car. Or better yet, a bicycle. Switch to the Ecosia search tool. Don’t like my suggestions? Great! Make better ones.

3. Make a noise.

Do not go gently into that good night. It won’t be good, and it won’t be gentle, and by the time that starts to make itself felt in your life, it will probably be too late. Shout about it. Those of us in technology are more connected than anyone else. Shout about the products making a difference. Shout about the awesome people doing good things.

But most of all, shout about the urgency. Shout about how we need to do something now.

They say the best time to plant an oak tree was 20 years ago, but the second best time to plant it is now. It’s already too late to save everything.

Let’s save what we can.

Posted in life | 4 Comments

On Multiple Givens, Whens and Thens

Posted on May 6, 2019 by

I wrote this as a reply to user RHarris’s question on StackOverflow, but thought it might be easier to find here too. The login scenario and the access record here are adapted from their question.

What contexts should we include in a scenario?

Scenario 1: A user signs in with valid credentials

Given the Sign In page is displayed
When the user enters a username and password
And the user submits the request
Then the user should be directed to the Home page

I find it helps to think of scenarios not as tests, but as living documentation that helps to illustrate how the system behaves and why that’s valuable.

If you can tell that the user isn’t locked out and isn’t disabled in that first scenario, then you don’t need to include those steps.

For something like logging in with an active, enabled account this is obvious, but it might not be for something like a trader staying within their trading limits, or a fetal heartbeat running at a healthy rate, or a comment that hasn’t yet reached the reporting threshold. You can decide whether to include those kind of contexts pragmatically.

I prefer though to move documentation that doesn’t change or doesn’t change very often, like core domain concepts, outside of the scenarios. Perhaps it can be at the blurb at the top of the scenario file, or on a team wiki somewhere that new joiners get to read before they code. It doesn’t have to be in the scenario.

(Obviously you would need to include the contexts which cause the failure in any failure scenario though!)

What about side-effects and other outcomes?

...
Then the user should be directed to the Home page
And the logs should record their access.

All outcomes that matter do so because at some point, they become visible or have effects beyond the system whose behaviour is covered in the scenario.

For instance, when I get money from a cash machine, my account is also debited. I might not see that as part of the behaviour, but it does have to happen. That’s because there’s another stakeholder involved in the scenario – the bank.

Or perhaps, when Fred gets a refund on his microwave, the microwave is put back into stock and the stock count is incremented. Fred, the till operator and the stock controller are all stakeholders here.

In the case where we’re adding something to the logs, there’s a stakeholder who’s going to use those logs for something else. Having an awareness of that value can help us work out why we’re logging, and describe that outcome from the POV of the stakeholder who finds it valuable.

If the outcomes can be shipped independently and still be valuable, they can appear in separate scenarios. I’m pretty pragmatic about this, so I might put them in the same scenario to start with, then refactor them out later once the number of “stock control” scenarios means that it should probably have its own feature files.

If the outcomes can’t be shipped independently, which is usually the case with anything transactional, I like to see those outcomes appear together in at least one scenario, to make it obvious that they’re related. They don’t have to appear in every scenario. For instance, once we’ve written the scenario where the user doesn’t have funds so their account doesn’t get debited, we probably don’t have to mention the account again in any other cash withdrawal failure scenarios.

This perspective of multiple stakeholders is also related to the BDD concept of “Outside-In”, where all the behaviour we add to the system is done to provide a value to some stakeholder through some interface.

What about interactions with other users or with time?

Sometimes – very occasionally – we need more than one when to describe what’s happening, and the example of a login counter being incremented is a great one to use.

The value of a login counter is only that it disables the account after 3 attempts (for instance). It has no value in and of itself. It’s an implementation detail. If we made this into an outcome in a scenario, we’d be coupling ourselves to that implementation, which wouldn’t be great. So having two scenarios – one to describe how the login counter works and one to show why it’s valuable – doesn’t feel right since one of them isn’t describing valuable behaviour:

Given Clarence logged in successfully last time
When Clarence enters his password incorrectly
Then the login counter should be incremented.

Given Clarence's login counter was incremented twice
When Clarence enters his password incorrectly
Then his account should be disabled.

Yuk. Let’s not do that.

The only value in that counter is from the interaction of Clarence’s behaviour with Clarence’s future (or past) behaviour. So we could have something like:

Given Clarence logged in successfully last time
When he enters his password incorrectly
And enters his password incorrectly
And enters his password incorrectly
Then his account should be disabled.

Of course, that’s a bit of a mouthful, so we’d probably just say:

Given Clarence logged in successfully last time
When he enters his password incorrectly 3 times
Then his account should be disabled.

We can do that because it’s the same thing happening. Some interactions though involve different things happening (“time passing” is another one I frequently encounter).

Given Clare is editing trade 12345
When Stephen edits and saves that trade
And Clare tries to save that trade
Then she should be told that Stephen has already edited it.

In this case of course Clare’s interaction is different to Stephen’s, since her attempt to save fails.

Note the use of tries here to indicate failure; another example of how I use assumptions. If it doesn’t say tries we can assume that the event was successful. The alternative would be:

When Clare saves the trade successfully

Unless a successful outcome is somehow surprising and not the norm, this would get a bit repetitive, so I prefer to use nothing for the default and tries for failure. Having a difference between them is important from an automation perspective since it lets us do things like move the automated workflow to an error page instead of the confirmation page.

It also reads quite nicely. Which is pretty much why we’re trying to use these English language tools anyway.

Posted in bdd, stakeholders | 5 Comments

How to run a Futurespective

Posted on September 12, 2018 by

Futurespectives, like Retrospectives, look back at the past… from the future!

I find them very useful when there isn’t much to retrospect on: at the start of a project or initiative. I’ve run them for myself, for other individuals, and for groups of up to a hundred individuals, so it’s pretty flexible.

In a futurespective, we imagine that we’re in the future, and we look back to the past. Here’s the quick outline of what I do:

  • Set the scene and create a timeline
  • No explicit safety check (use common sense)
  • Step forward into the future
  • Look back at the past negatively (skip to positive if short on time)
  • State interrupt – break the mood!
  • Step forward into the future again
  • Look back at the past positively
  • Dot-vote
  • Create actions.

There’s some notes at the end too.

Set the scene

Imagine that the thing you’ve started has reached some kind of conclusion.

How long did that take? It could be the first project release, or the first time the team move onto something new, or the first time someone realizes that what they were trying to do has worked (or not).

I like to ask the people in the room, but if they don’t have experience, I’ll use mine or refer to other people’s. Futurespectives work well when the timeline is of the order of months or years (though I’ve done them with just days before!)

When we’ve decided what boundary of time we’re going to use, make post-its for any known or proposed events like release dates, deadlines, etc.. Tangential events which help people to imagine where they are in time are also useful, like the office Christmas party, or the rough date a team-member’s baby is due, or the start of school summer holidays.

The team can add any events they know of to this timeline.

No explicit safety check (use common sense)

Most of the time when I run this session, it’s because something highly uncertain is about to happen, often with people who aren’t used to working together. Asking whether people feel safe to share their opinions is less useful than encouraging them to be creative… particularly in the “negative” run-through!

Make sure you position the “negative” run-through as something of a ritual, so that people feel safe to make suggestions. I tell people that if the worst thing that happens is that a meteor hits the building, then that’s what happens.

Step forward into the future

I ask people to stand up and gather in a group at the start of the timeline, then walk with me as we progress through to the future. I talk about things that are happening as we move; any events that are occurring, the changes in the season, and events like Hallowe’en or that late blast of sunshine that we always get at the end of September; anything which reaches out to the imagination.

At the end of the timeline, we turn and look back.

Most of the times I’ve done this, there hasn’t really been enough room for everyone to traverse the whole timeline from start to finish; they get to shuffle along a little bit behind you while you lead the way. Remember to move past the end so that you give the group as much space as possible! The most important thing is that they aren’t standing where they started, and have moved to somewhere else.

This means that when they look back on the timeline, they will be able to correlate that movement more easily with the shift in time as well, helping them to imagine what happens next (or before).

Look back at the past negatively (skip to positive if short on time)

I like to make the first run-through the negative one, because then we end on a positive note. This one can also be quite funny.

I tell them, “Look back on the previous years / months since <date>. Wasn’t that just the most awful time you’ve ever had, ever? Everything went wrong.” Then I describe all the symptoms of it going wrong – people quitting, blaming each other, stealing the milk… whatever you can think of. I talk about my own role, too, with phrases like, “nobody is even speaking to that consultant you hired back in January!” or “that facilitator just didn’t help at all!”

I encourage people to be absolutely outrageous – in one organization Boris Johnson became the company Chairman; another large national company was reduced to less than 100 staff members because of the high turnover; quotes from “Office Space” and other parodies get scattered around liberally.

The outrageous ideas provide a container in which people can post dangerous ideas; things that might actually be a bit likely, but which would be taboo to suggest in a serious manner. We don’t ever discuss the negative things, so this is OK. Lots of elephants may emerge in the room. We’ll deal with them positively, later.

Ideas go onto post-its and those go up on the board. Ask your attendees to put any continuous events at the point at which they first noticed them happening.

I like to use pink post-its for bad things (and green or yellow for good things later), but I also put them below a particular line, leaving space between the negative ideas and the timeline above it for positive ideas (or you could have the timeline in the middle if you can make it visible enough).

As a guide for the space to leave, the positive ideas should be at or slightly above eye-level, and we normally use 1 or 2 feet (30 to 60 cm) of wall-space for each run-through, depending on how many people are involved and how long we can make the timeline in the space available.

State interrupt – break the mood!

I ask people something like, “Who’s a cat person here, and who’s a dog person?” or, “What’s your favourite film?” I often ask them why they think I asked that question, and they usually guess correctly that it’s to break the sad mood of the previous run.

Step forward into the future again

We repeat the previous walk-through, gathering at the beginning and walking back through to the future, with the same events (which is why the timeline should be of proposed or known events rather than imagined ones).

Look back at the past positively

I tell them, “Look back on the previous years / months since <date>. Wasn’t that just amazing? Look at all the awesome stuff that happened! All those risks we identified back in <this month>… none of them materialized. We managed to mitigate or minimize every single one! So many good things have happened! So many wonderful things! So what are they? What happened?”

Ask attendees to put the ideas onto post-its, and put them on the wall once more.

Dot-vote

De-dupe any of the positive events, moving them to the earlier dates if possible.

Ask the attendees to dot-vote on the events that are “most important, and least likely to happen without intervention”.

There are important events that will happen anyway, and unimportant events that people can work around. We want the events that are most risky; the things that really need to happen, but perhaps haven’t been started yet because people don’t know how.

These are often things that will only happen when people learn by trying them, so getting started is the important thing to do. This just gets people started.

Note that some of these may be the elephants in the room, but we’ve turned them into positive outcomes (see also Mike Burrows’ / Agendashift’s 15-minute FOTO if you want another excellent way to do this!)

Create actions

If anyone can make a difference to the events, or try something out which might help with them, they can volunteer for actions.

It’s highly likely that some of the events require sponsorship, authority or assistance from people outside the room. If you as a coach or consultant are in a position to help with those, you can go ahead and take the actions yourself.

Otherwise, ask if people know who to talk to. The action to take is then at least to have a conversation with that person.

Don’t create actions for people who aren’t in the room or don’t want to own them! That’s a really great way to waste post-it notes.

Notes

As long as some of the actions get taken up, and a bit of change happens, the futurespective was worth it. Change creates a new context, in which change has already been successful, which can make future changes easier and more likely to be attempted. In those situations the actions should be safe-to-fail probes. Simple conversations ought to be safe-to-fail (and if they weren’t, that’s useful information to have anyway).

It’s often the case that the red post-its pile up at the end of the timeline, while the green ones are clustered near the beginning; we need to act now to prevent problems later. If that happens, it’s worth drawing attention to it.

I sometimes get asked if we’re going to talk about the red ones. I explain that they’re only there to generate the green ones, but that if they want to, they can create a green one that’s an exact negative (“Boris Johnson does not become our chairman!”) and we can vote on that and talk about how to make sure it happens.

(In that positive timeline, he actually emigrated to Australia. I liked the imaginative creativity of that group very much.)

 

 

Posted in Uncategorized | 3 Comments

Probably not

Posted on July 28, 2018 by

When working in complexity, where the right thing to do emerges and we learn by actually trying things rather than by analysis, there’s a very human instinct that happens when we think of probes to try out. I see it all the time when I teach Cynefin, and I sometimes catch myself doing it (which means I fail to catch myself doing it a lot; welcome to bias).

I see people think of perfectly lovely, lightweight probes. “Let’s try using Slack.” “We could set up a visual board…” “Let’s try talking to the Ops team.” “It looks like a simple fix, and we can back it out easily if it fails.”

The urge that kicks in is then to take these lovely lightweight probes, which are perfectly safe-to-fail, and add stuff to them to give them a better chance of working.

“Slack? Fantastic; I’ll need the list of everyone to add to it, and I’ll set up these fifteen channels, and we’ll have a launch party in two weeks to encourage people to join…”

“A visual board? We should copy it into JIRA as well, and make a key of what colour post-its to use and here’s all the information that we need to put on them…”

“Our Ops team? Let me set up a meeting with our senior stakeholders and third-party suppliers so we can talk through what we need…”

“Release? You’ll have to work with the other teams and join the release schedule we’ve already set…”

The trouble is, these speculative investments of time, money or effort can mean that the probe is that much less safe-to-fail. Communicating a probe without being really clear that it’s just trying something out can result in communicating intent, leading others to create commitments around it, cementing it in place. The sunk-cost fallacy kicks in. “What do you mean, it’s not working? We spent two weeks on that…” The more people it reaches, the greater the impact and the need for success.

Having an awareness of this tendency has helped me to ramp it back. Instead of trying for something that will probably work, think about keeping it lightweight, so that if it doesn’t, it’s easy to fix or reverse or dampen in other ways. We’re aiming for things that might possibly work, or even plausibly work (I saw a figure from Ozzie Yüce that suggests only 1 in 3000 new ideas are actually successful). Keep it simple, small, or cheap, or short, or even hacked-into-place if that’s something you’re good at.

(Probes don’t have to be simple, small, cheap, or short, but I’ve found those are pretty good heuristics to work with.)

Resist the urge to double down by surrounding the probe with expensive scaffolding to prevent the failure. If it seems like it might not work, try to find ways instead to make it safe-to-fail. Those options that you make available for handling failure will work with other probes, too. (Automated rollback, for instance, makes all kinds of production releases safer, allowing all the teams involved to try things out more easily.)

And if you hear someone else’s ideas, please also resist the urge to tell them all the reasons you can think of that mean it’s going to fail, unless it really isn’t safe to do so (or your feedback has been explicitly invited).

In the complicated domain, things will work as predicted; in complexity, probably not so much. And that’s OK.

Posted in cynefin, real options | 1 Comment