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
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!)
- 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.
I like the idea of anchoring the good bits while continuing to explore. I suspect that there is an assumption, perhaps a bit patronising apart from anything else, that most people will hang onto anything they have in their mind and the main task is to goad them into looking at new ideas. In fact, some become so enthusiastic about complexity that they throw away the things they could hang onto and look for complexity in areas where it isn’t really the most useful starting point.
Please note that I’m using the word “complexity” in the sense of Cynefin and Complexity Thinking. The assumption made by many is, as Dave Snowden puts it, “a certain level of predictability and order exists in the world”, when it really doesn’t. You can see this reflected in things like the Scrum Guide (“optimize predictability and control risk”). The main tasks I’m trying to achieve here are *both* to hold on to the things that are useful (the “Yes!”) and then to explore not just new ideas, but new *probes* (the “and…”). Human change is always dominated by complexity (unless it’s a reaction to chaos) so we don’t really have a choice about the starting point.
I agree. I dashed off my comment above as I was leaving the house and might not have been very clear.
I find Snowden’s formulation of complexity and its relationship to other states in the Cynefin framework the most useful source in this field.
Many people who take on the idea that most human systems are complex, including in the software field, seem to treat it as if the whole world must be complex or ordered whereas it is more like a mosaic of connected areas ( I would say domains but it would be confusing in the context of Cynefin), some of which are characterised by complexity and some by largely ordered behaviour, at least within certain bounds of time and organisational span. I am not directly involved with software on a daily basis but it seems that the good name of an Agile approach is being blackened by people applying it where it isn’t a good fit or adopting the Dilbert version http://dilbert.com/strip/2007-11-26
I think that can be avoided by considering good probe design when thinking about change: do the people making the changes have ways of knowing if they’re succeeding or failing? Have they thought about dampening or amplifying it? Does the change seem realistic? I’ve had some really useful conversations about disposition, too, which helps us choose things that are more likely to work, even though not completely predictable.
I think the biggest problem with software development and change is that software is itself driven by complexity, since you’re always doing something you’ve never done before; so useful change in that space often involves helping people move away from notions of predictability, which is itself complex and a real battle against human desire for certainty. It’s very different from, for instance, putting TPS in place in a factory producing the same cars over and over again.
Agile adoption tends to throw up radically different discoveries in different contexts / organizations as a result, and IMO the good name of Agile is being blackened largely because as it moves away from innovators and early adopters and into the mainstream, people think that it should just work… and of course, it’s never that easy.
Pingback: Five Blogs – 7 March 2016 – 5blogs
Pingback: Java Web Weekly, Issue 167 | Baeldung
Pingback: The Concentric Rings of the Cloud-Native Enterprise
I really like this way of thinking, and have noticed its applicability all around me after reading. Today, I stumbled upon this talk from Agile Tour London 2015 where Andrea Darabos gives 10 helpful tips for creating a ‘Minimal Viable Experiment’, which I suspect is useful and even integral to learning in any Cynefin.Complex space: https://www.infoq.com/presentations/minimum-viable-experiments
While the whole talk is worth watching because she elaborates on each of the points, the tips are:
State your Assumption. Connect it to a Goal. Make it Minimal. Think Creatively (run the experiment outside of the domain it originated in). Have a Pass Condition. Run in a timebox. Share Progress Visually. Document What You Learn. Run one at a time and Sequence based on risk/investment (I would add Complexity).
I hope her tips will help someone who reads your great post but finds it hard to start using probes!
Thanks Stephan. I would suggest being careful with the pass condition; you often get unexpected side-effects in complexity which could end up giving you the opposite of what you expected, but still a good thing. I wrote more about that here. If you think of it as an example of a good thing that might happen (“Coherence”) and treat the outcome with curiosity then the tips are excellent.