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.

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.