Liz Keogh, lunivore

On Real Options and Speculative Investments

Posted on September 8, 2017 by Liz

If you’ve read the awesome graphic novel, “Commitment”, you’ll know the rules of Real Options already:

Options have value
Options expire
Never commit early unless you know why.

There’s an additional rule which is sometimes added to this:

Options have more value as uncertainty rises.

…and software development is full of uncertainty.

We do want to make commitments; also investments, which are the subject of this blog. Failure to act is itself a decision, and at some point options do expire. As David J. Anderson says, “If you leave it long enough, eventually everything becomes an expedite.” The problem comes when the commitments are premature, and the investments speculative. So this post is about minimizing speculative investments, and avoiding premature commitments altogether.

An option is the right, but not the obligation, to do something or get something.

Chris Matts took the term “Real Options” from financial options, for which we can easily assign value; the right to buy cocoa beans at a certain price right before Christmas so that your chocolate factory can meet its own commitments to provide chocolate Santas to its customers, for instance. If cocoa beans are cheaper than the option price, we don’t need to use the option. If they’re more expensive, we exercise the option and we get our beans affordably.

In real life, options are harder to value. They’re just choices. However, they have value, and we as human beings tend to exercise our options way before we need to. We have an innate dislike of uncertainty. Our confirmation bias serves to make us think we have certainty and understand the patterns we see, even when we don’t. That’s great for helping us move forward in an uncertain world… but if we could move forward in a way that kept two directions open for us, cheaply, why wouldn’t we?

The other problem I’ve encountered is that we don’t actually commit a lot of the time. Instead, we make heavy, and speculative, investments.

A speculative investment is risky.

In finance, a speculative investment is one which may entail a significant degree of loss, and which by its nature is uncertain. I’m talking about real-life investments, which might be of time or effort or willpower or social capital. The term “speculative” also means “based on conjecture, rather than knowledge.” Like premature commitments, a speculative investment is one made in an absence of good information.

So what’s the difference between a commitment and an investment?

Commitments are discrete; investments are continuous.

Let’s say you’re skiing, and the lift is broken. You plod up the mountain with your skiis, investing in the ride down. At some point you realise the slope is a bit steeper than you thought, and not a good match for your ability. You decide you’ve invested enough, and put your skiis on, and off you go. Only the effort you’ve spent is committed; you haven’t made any future commitments. The decision is a continuous one, and can be changed at any point, dampening future consequences. If it’s a bit too steep for you you might feel a bit uncomfortable and you’ve still got a chance of crashing, but at least you were able to stop when you did.

A commitment is jumping out of a plane. If your parachute doesn’t work, you can’t change your mind half-way down and decide you’ve had enough. The future consequences are unavoidable.

I think of investments like a slope of expired options against time, with the steeper slopes being heavier investments, and commitments being a vertical line. Sometimes investments can turn into vertical lines, like the V1 point at which a pilot is pretty much committed to taking off from the runway and can’t abort. Sometimes they can be unwound, but the unwinding can be painful, like plodding all the way back down the mountainside.

Investments in software development prove really interesting, particularly because of two human biases: confirmation bias, and the sunk-cost fallacy.

Together, they lead us to commit to the direction set by speculative investments, thinking that we have certainty and good information when we don’t; and to build on the investments we’ve already made, even if we do have information that they’re wrong. Sometimes the commitment is just a mental block. Sometimes we communicate it to others, creating reputational or contractual commitments. Sometimes we tie other decisions to the investment, making it a far heavier investment than it was before, until it’s practically a vertical line anyway.

Here are some common examples of speculative investments that I see in software development, and some ways of improving your process by making that investment smaller and lighter and less likely to invite commitment.

Research, analysis and design done a long time ahead of the actual development. (Yes, two weeks is a long time.) Prototype as soon as you can, especially if the solution is technically complex. Use the prototype for guerrilla testing. Keep your options open by having several different designs (concurrent set-based engineering, or in Cynefin-speak, parallel probes). Don’t worry about bits of the design which are easy to change; fonts and colours and spacing and even layout can be sorted out later. Bonus points to designers who can sit with the devs and help them tweak the final bits… especially if it means you learn a bit of code yourselves.

Backlogs that require grooming. This is another sign of speculative investment in the form of analysis. I find planning at the capability level is a good level of granularity at which to stop. Put them on cards or post-its and stick them on a wall somewhere. A big one-year trading project had about 37 cards. The projects I work on now are typically a few months long and have ten cards or so. Let the team break them down as they come to them. Focus on the riskiest ones that the team know least about, too, so that you can make discoveries and get the information for good decisions early. And minimize the work you’re looking at! If you don’t need it, don’t put it on the wall until you’ve done the stuff you need (and often, discovered what that really is). Everything else is an option, and options have value.

Yearly budgeting cycles. Most organizations do have a process for changing direction mid-year, but it’s painful. The cost of unwinding heavy investments often is. Bjarte Bogsness’s work on Beyond Budgeting is excellent for separating the different concerns of budgets like resource allocation and motivation and prioritisation, providing more flexibility, as well as being beautifully alliterative. Budgeting for half a year or quarterly lets you change direction more frequently. Concepts like BHAGs, True North and the One Metric That Matters (OMTM) can help departments to align, letting them make decisions locally, enabling greater trust and more autonomy for spending the money you’re giving them.

Leaving testing to the end. Doing this at the end of a project is going to hurt you badly, but even leaving testing to the end of a sprint means you’ve got two weeks of speculative investment of code. Devs, if you’ve got something working on your machine, and your tester is co-located, go and get them so they can see it. Chances are you’ve forgotten something. (Chances are good you’ll remember it as you’re walking across the room.)

Big releases without the possibility of rolling back… or without the information that tells you that you need to. Actually, this is a commitment rather than an investment, since you’ve got no choice but to enjoy the freefall. I heard of one company that had to cease online trading for months afterwards… or there’s Knight Capitol Group, which, well, it doesn’t exist any more. Don’t do big-bang releases with no rollback, unless you’re really sure that you’ve eliminated uncertainty or opened some options for yourselves through other means. (If this is the norm for you, you probably don’t have those techniques either. Start learning, because your competitors do.)

It’s all about investments and commitments.

These are just a few examples of speculative investments that I see in software and the wider organization, from code to corporate strategy. We’ll always have some level of speculative investment, because we need to move forwards and uncertainty always exists, but it doesn’t need to be heavy. Minimizing speculative investment is a principle which scales.

I’ve realised that just about every aspect of my job as a Lean / Agile coach and consultant is about minimizing these speculative investments and avoiding premature commitments; encouraging people to keep options open by creating safety (organizational, technological and psychological), minimizing queues and feedback loops and embracing the riskiest and most uncertain work so that information for making better decisions arrives earlier, helping people limit the work in progress with that “stop starting, start finishing” mantra so that the investments already in flight pay out or give us feedback earlier, clarifying direction to allow for swift and autonomous changing of decisions, and helping people communicate and visualize with greater transparency.

Everything decision we make, we do with the information we have. We often make the wrong decisions, and more so when we don’t have good information. Unless there’s something urgent going on (because chaos is often what happens when you make premature commitments), we want our investments in uncertainty to be probes; a Cynefin term which means trying something out that’s safe-to-fail, with feedback on whether it’s succeeding or failing and mechanisms for amplifying it or dampening it accordingly.

With investments, being wrong less doesn’t have to mean being right. It can mean being wrong with less money, in smaller contexts, for less time, with less stuff and fewer people.

That’s how we keep our most important option open: the option to do something else instead.

Posted in cynefin, real options | 1 Comment

Reflecting Reality

Posted on August 31, 2017 by Liz

One of the things I often do as a coach is help people to set up their visual boards, whether physical or electronic. Sometimes that can be surprisingly hard for teams to do without a bit of guidance, so I wanted to provide some hints and tips for getting a board up and running, fast. A lot of these have come from the world of Kanban, and I think they really help with small, continuous improvements.

My most important hint of all:

Make your board reflect reality.

If reality is ugly, your board will be ugly. If you have lots of places where work passes from one role to another, your board will have lots of phases too. If you have work piling up in one area like “Ready for Dev” or “In QA”, your board will have a lot of work in that phase.

Do not hide it. I see a lot of teams aiming for some kind of Agile ideal, and when the work doesn’t match the ideal, sometimes they think, “Well, we shouldn’t really be doing it, then.” And so, they hide the work, and things end up dropping through the cracks as a result. Sure, maybe the team shouldn’t be working on five things at once. If you are, though, put it on the board. The first stage to fixing a problem is admitting that you have a problem!

Once when I was working as a dev, I was told not to put any work on the board without going through my team lead, who was often away. That resulted in each dev keeping a little file of stuff that we knew needed to be done. Our lead was very surprised to find that we weren’t confident about meeting the sadline*… and even more surprised by the amount of work still left to do to go live. We’d love to have a small backlog and be releasing every week, but if that isn’t possible, put it on the board.

Change the board.

If you find that your board doesn’t reflect reality, or that you’re having to adopt processes that feel wrong because of the board, change the board. If you’re using a technology that isn’t adaptable to change, change the technology. Your tools are there to support your work, not the other way round.

I love physical boards because they’re so easy to change, and you can tweak them together until you get a result you like.

Keep your metrics.

Most of the teams I work with actually have two: one physical, and one electronic. Often one of those is nominated as the “master”; usually the electronic one. If you only have a physical board, though, or your physical is the master, when you move a card, put the name of the phase / column and the date you moved it on the back.

This is invaluable in seeing how and whether the team is improving, and in making forecasts about when you’re going to be finished, so you can manage things like stakeholder expectations and marketing and cross-programme dependencies.

Make process policies explicit.

Often teams have a really organic process, which means that sometimes when things get a bit crazy, as they always do, bits of that process get missed and fall away. By adding a simple checklist for moving into each column, we remind ourselves of the other people involved in delivering our work, and have a better chance of delivering it well.

You can have different policies for different types of work. Just make it explicit. Scrum practitioners often agree on a definition of “done”**, but I like having this definition for each phase-change. Bonus points if the policy involves talking to someone else and showing them what you did rather than just ticking boxes.

If we have a physical board, the policy might just be a little bit of paper at the top of each column with reminders on it.

Add all types of work, including improvements.

If the team are involved in something, and it’s taking their time and energy and focus, put it on the board. I tend to differentiate between customer/stakeholder-facing work that needs to be done, technical tasks where the customer is future-you or another dev team member, information-gathering activities like spikes, and improvements of the kind that often come out of retrospectives.

It isn’t totally necessary to put improvements on your board, and a lot of teams are successful without doing that, but the teams which I see continually improving tend to have those tasks listed visibly somewhere. The improvements might go outside of your team, so it’s OK to put “please deliver a talk on your ways of working to the XYZ community” on the board. Flag it up as a different kind of ticket if you need to filter them out for some reason. “Improvement” is a ticket type in JIRA; get your admin to add it.

Visualize (small) queues, and limit your work in progress.

I’ve seen a lot of boards called “kanban board” that weren’t actually pull-systems. “Kanban” comes from Lean manufacturing systems like Toyota’s. It means a signal card, and it’s a way of making sure that the inventory in the system (i.e.: the work in progress) is a good match for the throughput capacity.

That means, for instance, that if your tester is regularly overloaded, you won’t be able to go faster than your tester. By putting WIP limits on your tester’s column, you create a signal (a space in that column) that your tester has room for more work. If the tester doesn’t have room, you know that rather than overloading the WIP limits, the right thing to do is to go help the tester. Or, if you can’t, read a book! Or do something small and interruptible, so that when the tester comes back with feedback, the work is still relatively fresh and the knowledge hasn’t rusted in the rest of the teams’ heads.

This way of working may not be productive, but it is more effective. Knowledge rusts way faster than cars.

We expect that in knowledge work, we’ll get a lot more variance in terms of how long things take than Toyota does in its factories. Because of that variance, and because human beings are capable of more than one skill (unlike factory machines), our constraints will sometimes shift. We want to keep the work flowing, which means that we never want the constraint to run out. So, we want small queues of work before the constraint.

If you want to start putting WIP limits somewhere, put them wherever work seems to get “stuck”. That’s your constraint.

As a note, there’s a pretty typical journey I see with teams adopting WIP limits for the first time:

they ignore them completely
they violate them reluctantly
they fight to stay inside them.

At each of these stages, we have another conversation about why WIP limits will help. Coaching takes patience.

Stop Starting, Start Finishing.

If you don’t feel like your team is ready to start putting WIP limits in place, this litttle principle (from David J. Anderson) will help to get the mindset in place. Before starting work, look to see if there’s any way to help finish other work that’s ongoing.

That might be as simple as offering to get your tester a cup of tea!

Another way to start doing this is called “Walking the board”. In the stand-up, rather than just going round each person, look at the cards starting from the ones closest to release, then working through each phase towards the new work to be pulled in (normally right-to-left). Ask what’s needed to help finish it, and if anyone else could do that or learn that skill.

People will naturally start learning each other’s skills, becoming T-shaped, with narrow expertise but general ability to help out in the basics elsewhere.

Autonomy, Mastery and Purpose.

As Dan Pink says in his book / talk, “Drive”, this is how people in creative spaces are motivated. These ideas should help you provide your teams with the ability to change their own ways of working, in context; with slack as the constraint moves around to pick up new, related skills and to deepen and improve their own; and with a renewed sense of purpose driven by meeting genuine customer need, quickly and effectively.

Who knew visualisation could be so much fun?

*Sometimes no person or project or opportunity dies as a result of missing a date. If nothing’s going to die, it’s not a deadline. Often it’s just someone’s reputation at stake, and missing the date means that someone will be sad. People tend to be surprisingly pragmatic with real deadlines in a way that they’re not with sadlines. Humans are weird.

**You’re not really “done” until the software has been retired and is no longer used at all. Make your board reflect reality. Call it what it really is, whether that’s “ready for integration” or “ready for release” or “in production”. Remember that there are other people still using, maintaining and updating that software, and be nice to your IT Ops teams.

Posted in kanban, lean | 2 Comments

A Helping Hand

Posted on July 18, 2017 by Liz

This week, Sallyann Freudenberg and Katherine Kirk have been running a small summit on inclusive collaboration and neurodiversity – not just focused on diversity in our experiences, but in the very make-up of our brain.

Sallyann suggested there was a little test that could be taken to discover if we ourselves have any autistic tendencies. I wasn’t surprised to find that I register on the threshold. I remember the years spent entirely alone at junior school, without worrying about any need for friends; losing myself in raindrops trickling down the windows; the rich visual stuff in my head (doesn’t everyone think like that? Apparently not, says Sallyann.)

I spot patterns not because I think about them a lot but because I associate visual and kinesthetic experiences. Cynefin isn’t just made up of obvious and complicated and complex and chaotic things; it’s stuff that’s hard and doesn’t budge; that fits together and clicks and is a bit greasy like cogs; that’s organic and smells peaty and crawls and climbs and shifts like plasticine; that’s on fire. When I feel the same way about something in life or work, I know instinctively what it is I’m looking at, which is why I think the framework made sense to me. Knowing how my head works has made a big difference.

In the last couple of years I’ve also lost much of my hearing. I’ve always been a bit deaf in the bass, but NHS hearing aids back when I was a child were big, clunky things that amplified the air con more than anything. Now I’ve lost more hearing still, so I need them. NHS hearing aids these days are tiny, but apparently my ear canals are narrow, and even in “extra-small” size the little gadgets hurt a bit to put in. Still, I can hear. It’s a blessing… and also incredibly tiring and draining. Paying attention to people is hard, though I have to, if I want to make a difference to the world.

So, when they told me that we’d be assembling hands for children who’d lost theirs, in complete silence, I felt calm and happy. No more straining to hear people. No more asking them to repeat themselves. Silence, my friend for a long time, would be keeping me company alongside my team-mates.

Then we started work.

First, we were missing the instructions. Oops! Are we meant to assemble this without them? I wondered. But no, they’d mentioned instructions… oh, Gitte put up her hand, so she’s on it.

We read through. I happened to sit in the middle, between Gitte and Aaron. A bad idea… I always tend to dominate these kinds of activities, with or without speaking. I tried hard to make sure that I was giving the others a chance to participate and not just doing all myself, but at one point Gitte started writing on a post-it. Katherine had suggested we do that, for things that we were thinking, or wanted to say.

What’s she writing? I thought. Is it about me? Did I do something wrong? Am I being too dominant again? Wow, that’s really paranoid. Seriously.

They seem to know what they’re doing. Why aren’t they doing it? They should pick up the fingers, the pins, the cogs. I want to. I’ll just hold them and let them take them; is that still dominating? They aren’t moving. Are they waiting for me? Do they want me to lead? I can do that, but it’s not a good idea; I should let one of them have a go.

It’s a lot like Lego. It’s easy. Do they think it’s easy? Am I being arrogant? I studied engineering; maybe it’s easier for me… no, they have it, look. Yep, that’s me being arrogant again; I’m not the only one who knows how to do this. Might want to remember some humility next time, Liz, teach you to think you know better.

And on.

I wanted silence, but I didn’t have it. I had too many thoughts, instead. Too many things that I wanted to say… not to my team-mates, but to myself.

The others started the day with meditation (which I don’t enjoy; a long story which I won’t tell here) but I don’t often get the chance to really talk to myself about what I’m thinking… let alone to listen. Self-hypnosis is similar, and I do practice it, but not as often as perhaps I should. I do freewriting sometimes, too, and it felt a bit like that, listening to my own running commentary inside my head.

There was only one thing I really wanted to say: hush. Be quiet. It’s OK.

At some point I think my head started to listen. It was all right that I didn’t know where a piece went, or what it was that Gitte wrote this time. It was all right that we made a bit of noise when we used my empty coffee cup as a hammer, and I didn’t need to worry about what the other teams thought. After a while, my thoughts stopped chattering and started getting to work. I started paying attention to what the others wanted, instead of what I wanted… and I moved seats so that Gitte was in the middle.

These days I’m generally good at being quiet around others. The WAIT acronym – Why Am I Talking? – is often at the forefront of my mind. Being quiet around myself, though, so that I can actually hear what other people are saying, and not just with my ears… that’s my new quest.

Somewhere, this year, a child will be getting a hand that they need.

I think I found something I was missing, too.

Posted in cynefin, learning, life | 1 Comment

When Ignorance is Bliss

Posted on June 23, 2017 by Liz

I’ve written before about epiphany; that sudden sense of enlightenment that you get when you realise that you’ve discovered a new pattern in the world. It’s ironic that my favourite moment of epiphany was when I finally understood its opposite – apophany; that moment of enlightenment when you see a pattern that doesn’t actually exist.

We’re really, really good at spotting patterns that don’t exist.

And with that came the crashing understanding: this is why we have to probe before we sense or respond.

Over and over again, I see people in complex domains, trying to make big plans for how their transformation will progress. The plans are certainly valuable. They provide coherence; an example of how the attempted changes might succeed, or in Cynefin-speak, a realistic reason for thinking that the probes might have a positive impact.

Over and over again, human systems thwart the plans, and unexpected context emerges.

This is the trouble with the complex domain. You learn by doing; by attempting the changes and seeing what happens. Cause and effect can only be understood in retrospect.

We all have the human desire to understand the context of a situation. We like predictability, and shy away from uncertainty (that dreaded chaos!), so it’s natural that we seek to understand the thing we’re about to try to change.

The trouble is, you can’t. All those patterns you think you see? Not there, or not the important ones; certainly not the ones that are actually going to stop the changes from working.

Some of the changes will land. Some of the ideas you introduce will be accepted. Many of them will not… and if you push harder, you’ll sometimes encounter the backfire effect, and strengthen the very problem you’re trying to solve.

So if you’re encountering lots of resistance, try something else. Changing a bit of context can make it safe to change another bit, which can provide further safety, and so on and so forth until gradually the whole organization has transformed.

(It will probably take a while, and that’s OK. If it isn’t, use the incipient chaos to generate a sense of urgency, which buys more tolerance for change, so that it can happen faster.)

I define safety as the ability to act without losing the things that you, or others, value. By anchoring the things that we mutually value, we can increase the safety and make it easier for other changes to happen. Putting feedback loops in place, and deferring commitment and minimising investment, and telling people that it’s a bit of an experiment and it might not work but that will be OK, please let us know… they all increase safety. Most importantly, anchor and amplify the changes that are already working, because people on the ground generally have more context and are more likely to make changes that are disposed to work, and more likely to try to change things if they see that their changes are valued.

These days, this is how I work when I don’t understand the context. Because you don’t need to understand the situation to change the situation… and you can’t, anyway, until it isn’t the same situation any more, because you just changed it, and now you understand.

In complexity, there are unknown unknowns; discoveries ahead that cannot be predicted. This is second-order ignorance. You will always have it.

Work out how to make that OK, and enjoy it.

Posted in cynefin | 3 Comments

Yes, and…

Posted on March 5, 2017 by Liz

Imagine two actors standing on stage. “I like your penguin,” the first says. The other turns round, looking at the empty space where one might imagine a penguin could be following.

There are two things that can happen.

Perhaps the second actor frowns at the empty space. “I don’t have a penguin,” they say. “Oh,” says the first, and that’s it. The scene is dead.

Perhaps the second actor goes along with it. “Why, thank you!” they exclaim. “I only got it yesterday. Rockhoppers, I tell you, you got to get one of these…” And the scene continues, and now it’s funny, because it has a penguin in it, and penguins are funny – especially imaginary ones. The humour emerges, with jokes that are unexpected, both to the audience and the participants!

This is the principle of “Yes, and…” that forms the basic rule-of-thumb of Improv.

It’s also one of the most important principles for Agile transformation… or any kind of change involving people. This post is about why, and how to spot the principle at work and support it.

Complexity has Disposition, not Predictability

In a complex space, where cause and effect are only correlated in retrospect, we’re bound to make unexpected discoveries. Anything we do in that space needs to be safe-to-fail. Things that we try out that might improve things and which are safe-to-fail are called probes.

As leaders, our temptation is to come in and start poking the space, persuading people to pick up new ideas and try them out. Maybe that’s safe-to-fail; maybe it isn’t.

The people best positioned to know aren’t the coaches and consultants brought in for the transformation. They’re not the leaders and the managers. They’re the people on the ground, who’ve been working in that context for a while. They know what’s safe and what’s not. They know what’s supported and what isn’t. If you listen to the stories that people tell then you’ll hear about what works and what doesn’t… and those stories play into the space, too, and the people on the ground have been listening to them for a while.

They might not know what’s guaranteed to succeed. I once asked a group whether a football game counted as complicated (predictable) or complex (emergent). One of the attendees asked, “Is England playing?”

I think I might have made a face at that! However, it gave me a useful place to explain the difference between predictability and disposition. Just because the England team seem unlikely to win the football match doesn’t mean that they can’t. They don’t lose every match, after all! So perhaps the world of football is disposed against England winning the world cup.

However, we’re disposed for good beer and a beautiful summer with at least a bit of sunshine, so not everything is bad.

In our organizations, different probes will be differently disposed to succeed or fail, and to require amplification or dampening accordingly. The thing about human organizations, though, is that they are Complex Adaptive Systems, or CAS, in which the agents of the system (in this case, humans) can change the system itself.

And they already are.

People are generally interested in doing things better. They’re always trying things out, and some of those things will be succeeding.

The most important thing we can do as coaches and consultants is to encourage those successful probes; to spot those things which are succeeding and amplify them, and to make safe spaces in which more probes can be carried out, so that we can see more success and amplify it again.

Amplifying means taking what’s already in place (yes!) and building on it (and…).

A Really Common Pattern: “That won’t work because…”

Humans have a real tendency to see patterns which aren’t there, and to spot failure more than success. We don’t like failure. It makes us feel bad. We tend to avoid it, and when we see failure scenarios we invoke one big pattern in our head: That won’t work because…

There’s one word that’s short-hand for that tendency to see and avoid failure.

“I want to learn TDD, but it will take too long.”

“We could co-locate the team, but we’d need to find desk space.”

“We’ve got some testers in India, but they’re not as good as we need them to be.”

The word “but” negates everything that comes before it. It’s the opposite of building on what’s already there. What might happen if, instead, we use the word “and”?

“I want to learn TDD, and I’ll need to set aside some time for that.”

“We could co-locate the team, and we could look for desk space to do that.”

“We’ve got some testers in India, and we need to help them improve.”

Now, instead of shutting down ideas, be they our own or other people’s, we’re looking at possibilities for change. Just changing the language that we use in our day-to-day work can help people to spot things they could try out.

We already use “Yes, And…” in TDD

The TDD cycle is really simple:

Write a failing test
Make it pass
Refactor

However, when we’re dealing with legacy code, which has behaviour that we’re interested in and want to keep, the first thing we do is to amplify and anchor what’s already in place! We write a passing test over the existing code, then refactor with that safety in place, then we can add the new failing test and the change in behaviour.

Write a passing test (Yes!)
Refactor
Write a failing test (And…)
Make it pass.

We can do this with our co-workers, our teams and our organizations as well. Of course, we don’t refactor people! Refactoring code, though, usually means separating concerns and focusing on responsibilities. In human terms, that means anchoring the behaviour or probe that’s working, and helping people or organizations focus on their strengths and differentiators. This helps to outline the disposition of the space too, so that whatever we try next has a good chance of working.

Of course, in a complex space, a “passing test” might not always be possible, depending on what we discover. At least, though, by anchoring what we value, we’ve made sure that it won’t be any worse. If we keep the investment in our probes small, it’s safe-to-fail.

Anchor valuable behaviour (Yes!)
Recognize and celebrate strengths
Design the next probe, or just encourage people with more context to do that (And…)
Give it a try.

Tim Ferris’s book, “The 4-hour Work Week”, is all about this; focusing on our strengths and letting other people cover our weaknesses, so that we can change our lives to allow ourselves to learn new things.

The Feedback Sandwich is a “Yes, and…” pattern

You’ve probably come across the feedback sandwich before:

Say something good
Say something bad
Say something good

It’s got some other, less polite names, and a poor reputation, so I’d like to show you a different way to think about it. Here’s what we’re really doing:

Anchoring valuable behaviour
Suggesting improvements
Outlining a good place we’d like to get to.

Human beings are complex, and we make complex systems. It’s entirely possible that the good place we might like to get to won’t be easy, or we’ll make discoveries that mean we need to change direction. So that good place we want to get to is actually just an example of coherence; a realistic reason for thinking a probe might have a positive impact. We can think of a good thing that might result from trying out that improvement.

The thing is, people are adaptive. If you can outline a place you’re trying to get to, and it’s good, and other people want to get there, and you’ve already made them feel safe by anchoring the valuable behaviour, then they’ll make their own improvements, and probably try things you didn’t even think of. You don’t need the bit in the middle. People know themselves better than you can, and they know their own disposition. They know what feels safe, and possible. By giving them a suggestion of a good place to get to, we’re freeing them up to find their own way to get there… and they might end up going to a different place that’s better than before, and that’s good too.

In fact, just making sure that people’s most valuable behaviour is appreciated can be a really great way to create change. “Thank you” is a very simple way of doing that, so remember to use those two words a lot! “Thank you” is the “Yes!” of personal feedback.

It’s All About Safety.

improving-agile-teams This is the book which prompted this whole post.

In “Improving Agile Teams”, Paul Goddard dedicates a number of chapters to the concepts of safety, failure and fear of failure. I highly recommend this book, especially the simple exercises which are designed to help a team adopt principles that will help to make things safe.

It’s possible to look at an entire Agile transformation through this lens, too.

Typically, an organization starts adopting Agile at the team level, just in software development, often by taking on Scrum or some form of Kanban. It’s pretty easy to do, because we’ve got a lot of tools which enable us to change our software safely. BDD and TDD provide living documentation and help to anchor the behaviour that we care about. Our build pipelines and continuous integration makes sure that whatever we’ve got working stays working. Of course, we can’t quite ship yet! That’s because shipping to production is still a bit of a commitment, and it isn’t safe.

But* now it’s safe for Development in an organization to get it wrong.

Gradually we adopt practices alongside IT Operations which enable us either to fail in a place where it’s safe – making our test systems more like production – or which enable us to roll back in case of failure. Of course, once you’ve got a production-like test system that can be destroyed and rebuilt as required, it’s not a big step to actually make production systems that can be destroyed and rebuilt easily. Jez Humble and Dave Farley’s book, “Continuous Delivery”, is all about this (they call them “Phoenix Servers”, which gives me an excuse to shout-out to “The Phoenix Project” by Gene Kim et al, too; an excellent novel on the same theme).

So now we have DevOps, and it’s safe for the whole of IT to get it wrong.

As we start shipping smaller pieces of functionality more and more smoothly, the Business starts to pay attention. “Well… could I try this out?” someone says, and suddenly we’ve made it OK for them to do probes too, finding out what the market and their customers do and don’t want.

Now we’ve made it safe for the business to get it wrong.

At this stage we can really start churning out probes as a whole organization. There’s a really weird thing that happens in complexity, though. Sometimes people use things in a way that they weren’t intended to be used.

I often tell the story of Ludicorp and their online game, “Neverending”. They built tools for the players to share screenshots. They weren’t just used for screenshots, though, and those tools became the foundation of Flickr. Google started as a search engine. Amazon sold books. These companies don’t do what they started out doing. This is “exaptation”. It’s people, taking what we created (yes!) and using them for something else (and…)

It’s what makes it OK for us to have not discovered everything yet. It’s OK for humanity to be wrong.

This is how I always think of the Agile Fluency Model ™; with these levels of making it OK for people to be wrong. An Agile transformation is all about making it OK for an organization to get things wrong. If we think of it this way, it becomes obvious that safety is going to be a truly important part of that.

If you can’t think of a probe to try that might improve things and which would be safe-to-fail, maybe you can think of a probe to try that increases levels of safety. Something which puts in place the “Yes!” so that the “And…” can follow later. Something which helps people reduce their investments and commitments, providing themselves with options, or helping them deliberately discover information while it’s still cheap to change.

Make it Safe for Yourself, Too

*You can usefully use the word “But” to negate negatives. That’s about all it’s good for. It took me a fair few months to adopt the “Yes, and…” habit, and even I still use “but” occasionally, because I’m human. I slip up. I make mistakes.

So will you.

Celebrate your successes and your strengths, and make it safe for yourself to fail too Forgiveness is pretty much the greatest gift you can give yourself… or anyone else.

It lets you focus on the “Yes!” of your life so that you, too, can have “and…” in it.

Posted in complexity, cynefin, deliberate discovery, real options | 9 Comments

Breaking Boxes

Posted on November 7, 2016 by Liz

I love words. I really, really love words. I like poetry, and reading, and writing, and conversations, and songs with words in, and puns and wordplay and anagrams. I like learning words in different languages, and finding out where words came from, and watching them change over time.

I love the effect that words have on our minds and our models of our world. I love that words have connotations, and that changing the language we use can actually change our models and help us behave in different ways.

Language is a strange thing. It turns out that if you don’t learn language before the age of 5, you never really learn language; the constructs for it are set up in our brains at a very early age.

George Lakoff and Mark Johnson propose in their book, “Metaphors we Live By”, that all human language is based on metaphorical constructs. I don’t pretend to understand the book fully, and I believe there’s some contention about whether its premise truly holds, but I still found it a fascinating book, because it’s about words.

There was one bit which really caught my attention. “Events and actions are conceptualized metaphorically as objects, activities as substances, states as containers… activities are viewed as containers for the actions and other activities that make them up.” They give some examples:

I put a lot of energy into washing the windows.

Outside of washing the windows, what else did you do?

This fascinated me. I started seeing substances, and containers, everywhere!

I couldn’t do much testing before the end of the sprint.

As if “testing” was a substance, like cheese… we wanted 200g of testing, but we could only get 100g. And a sprint is a timebox – we even call it a box! I think in software, and with Agile methods, we do this even more.

The ticket was open for three weeks, but I’ve closed it now.

How many stories are in that feature?

It’s outside the scope of this release.

Partly I think this is because we like to decompose problems into smaller problems, because that helps us solve them more easily, and partly because we like to bound our work so that we know when we’re “done”, because it’s satisfying to be able to take responsibility for something concrete (spot the substance metaphor) and know you did a good job. There’s probably other reasons too.

There’s only one problem with dividing things into boxes like this: complexity.

In complex situations, problems can’t be decomposed into small pieces. We can try, for sure, and goodness knows enough projects have been planned that way… but when we actually go to do the work, we always make discoveries, and the end result is always different to what we predicted, whether in functionality or cost and time or critical reception or value and impact… we simply can’t predict everything. The outcomes emerge as the work is done.

I was thinking about this problem of decomposition and the fact that software, being inherently complex, is slightly messy… of Kanban, and our desire to find flow… of Cynthia Kurtz’s Cynefin pyramids… and of my friend and fellow coach, Katherine Kirk, who is helping me to see the world in terms of relationships.

It seemed to me that if a complex domain wasn’t made up of the sum of its parts, it might be dominated by the relationship between those parts instead. In Cynthia Kurtz’s pyramids, the complex domain is pictured as if the people on the ground get the work done (self-organizing teams, for instance) but have a decoupled hierarchical leader.

I talked to Dave Snowden about this, and he pointed me at one of his newer blog posts on containing constraints and coupling constraints, which makes more sense as the hierarchical leader (if there is one!) isn’t the only constraint on a team’s behaviour. So really, the relationships between people are actually constraints, and possibly attractors… now we’re getting to the limit of my Cynefin knowledge, which is always a fun place to be!

Regardless, thinking about work in terms of boxes tends to make us behave as if it’s boxes, which tends to lead us to treat something complex as if it’s complicated, which is disorder, which usually leads to an uncontrolled dive into chaos if it persists, and that’s not usually a good thing.

So I thought… what if we broke the boxes? What would happen if we changed the metaphor we used to talk about work? What if we focused on people and relationships, instead of on the work itself? What would that look like?

Let’s take that “testing” phrase as an example:

I couldn’t do much testing before the end of the sprint.

In the post I made for the Lean Systems Society, “Value Streams are Made of People”, I talked about how to map a value stream from the users to the dev team, and from the dev team back to the users. I visualize the development team as living in a container. So we can do the same thing with testing. Who’s inside the “testing” box?

Let’s say it’s a tester.

Who’s outside? Who gets value or benefits from the testing? If the tester finds nothing, there was no value to it (which we might not know until afterwards)… so it’s the developer who gets value from the feedback.

So now we have:

I couldn’t give the devs feedback on their work before the end of the sprint.

And of course, that sprint is also a box. Who’s on the inside? Well, it’s the dev team. And who’s on the outside? Why can’t the dev team just ship it to the users? They want to get feedback from the stakeholders first.

So now we have:

I couldn’t give the devs feedback on their work before the stakeholders saw it.

I went through some of the problems on PM Stackexchange. Box language, everywhere. I started making translations.

Should multiple Scrum teams working on the same project have the same start/end dates for their Sprints?

Becomes:

Does it help teams to co-ordinate if they get feedback from their stakeholders, then plan what to do next, at the same time as each other?

Interesting. Rephrasing it forced me to think about the benefits of having the same start/end dates. Huh. Of course, I’m having to make some assumptions in both these translations as to what the real problem was, and with who; there are other possibilities. Wouldn’t it have been great if we could have got the original people experiencing these problems to rephrase them?

If we used this language more frequently, would we end up focusing a little less on the work in our conceptual “box”, and more on what the next people in the stream needed from us so that they could deliver value too?

I ran a workshop on this with a pretty advanced group of Kanban coaches. I suggested it probably played into their explicit process policies. “Wow,” one of them said. “We always talk about our policies in terms of people, but as soon as we write them down… we go back to box language.”

Of course we do. It’s a convenient way to refer to our work (my translations were inevitably longer). We’re often held accountable and responsible for our box. If we get stressed at all we tend to worry more about our individual work than about other people (acting as individuals being the thing we do in chaos) and there’s often a bit of chaos, so that can make us revert to box language even more.

But I do wonder how much less chaos there would be if we commonly used language metaphors of people and relationships over substance and containers.

If, for instance, we made sure the tester had what they needed from us devs, instead of focusing on just our box of work until it’s “done”… would we work together better as a team?

If we realised that the cost might be in the people, but the value’s in the relationships… would we send less work offshore, or at least make sure that we have better relationships with our offshore team members?

If we focused on our relationship with users and stakeholders… would we make sure they have good ways of giving feedback as part of our work? Would we make it easier for them to say “thank you” as a result?

And when there’s a problem, would a focus on improving relationships help us to find new things to try to improve how our work gets “done”, too?

Posted in complexity | 7 Comments

How do you terminate a project in your org?

Posted on July 18, 2016 by Liz

We all know that when we do something new, for the first time, we make discoveries; and all software projects (and in fact change efforts of any variety) target something new.

(You can find out what that is by asking, “What will we be able to do when this is done that we can’t do right now? What will our customers, our staff or our systems be able to do?” This is the differentiating capability. There may be more than one, especially if the organization is used to delivering large buckets of work.)

Often, though, the discoveries that are made will slow things down, or make them impossible. Too many contexts to consider. Third parties that don’t want to co-operate, let alone collaborate. A scarcity of skills. Whatever we discover, sometimes it becomes apparent that the effort is never going to pay back for itself.

Of course, if you’ve invested a lot of money or time into the effort, it’s tempting to keep throwing more after it: the sunk-cost fallacy. So here are three questions that orgs which are resilient and resistant to that temptation are able to answer:

How can you tell if it’s failing?
What’s the process for terminating or redirecting failing efforts?
What happens to people who do that?

If you can’t answer those questions proudly for your org, or your project, you’re probably over-investing… which, on a regular basis, means throwing good money after bad, and wasting the time and effort of good people.

Wouldn’t you like to spend that on something else instead?

Posted in business value, capability red, deliberate discovery, real options | 1 Comment