Deliberate Discovery, Real Options and Cynefin

Posted on June 5, 2013 by Liz

Last week, I held a hangout with a few people from the ALE community. A few people very much enjoyed it and got quite a lot out of it – it’s far less formal than most presentations. It takes me a minute or so to get going, but once I do, this turns out to be the first time I’ve ever approached the idea of embracing uncertainty without starting with BDD or using it as a backbone.

There are quite a lot of experiments in this – it’s the first time I ever led a hangout – so please excuse the lack of preparation!

If you want to see something more formal, I also held a webinar called “Fail Fast, Fail Safe”,  on similar and related issues, complete with slides. I get to rant a lot in this one about people who “guarantee success” with Agile and Lean, and show some examples of how we all tend to do it without realising, anyway. Unfortunately we had a few technical difficulties outside of my control, so I drop out for a minute or so a few times. It got good votes despite the problems.

Big thanks to Ivana, and to Emily at Arrows Group, for arranging these sessions and making sure they were recorded for posterity!

Posted in Uncategorized | Tagged , , , | Leave a comment

BDD and Complexity Thinking tutorials at NDC Oslo

Posted on May 6, 2013 by Liz

This year I’ll be running two 1-day workshops at NDC Oslo:

Behaviour-Driven Development

Have you ever wanted to know exactly what your customers want? Or helped them to clarify their requirements? Have you ever wanted to quickly pick up a new domain, or prove that the application behaves as expected?

BDD is a set of practices which help software development teams to have conversations about the behavior of their system by talking through examples of how a user might use it.

Over the last nine years the adoption of BDD has grown globally, with dozens of tools created, used by hundreds of projects around the world. In this tutorial we look at the original reasons behind the creation of BDD, bringing the focus back to the language and conversations which lie at its heart. We look at how BDD’s patterns can be applied at multiple scales – from the initial project vision all the way to the code – to deliberately discover and address ignorance in every aspect of software development, producing reliable, maintainable software that matters.

This tutorial will be non-technical, focusing on conversations rather than automation. We’ll also be looking how to identify the places in which BDD doesn’t work so well, which plays nicely into…

Complexity Thinking

Have you ever wondered why big-analysis up-front never worked? Or wished you had the language to explain that to other people? Ever wondered why some things seem straight-forward while others defy analysis and prediction?

In this tutorial we’ll look at Cynefin, a framework for making sense of the world and the problems we encounter in it. We’ll also look at Deliberate Discovery and Real Options, and how they play into it, and we’ll practice coming up with experiments we could run in complex spaces that would still allow us to keep our options open.

This tutorial, highly applicable to software development, may also change the way in which you live your life…

NDC Oslo

As well as these tutorials, I’ll be talking about “Cynefin for Devs”, which covers the overlap between the two tutorials, looking at how complexity thinking is specifically applicable to BDD and IT in general.

NDC Oslo runs from 12th to 14th June with tutorials on 10th and 11th. I hope to see you there!

Posted in bdd, complexity, conference | Leave a comment

Respect for People: it’s a Test, not a Pillar

Posted on May 1, 2013 by Liz

On Monday at LKNA13, I ran an ignite talk on the title above. It was prompted by a video clip of John Seddon talking to Jeffrey Liker, suggesting that running interventions to make people more respectful might not be a good idea.

I partly agree with him. What is that we really want from our teams and our people? Tom Gilb has what he calls a “mafia offer” where you have to choose which of two things you value to sacrifice. I propose this related thought experiment:

Imagine that all the scientific data told you that the right way to get knowledge workers delivering was by brow-beating, yelling and command-and-control. What would you do as a manager or change agent? Would you focus on respect, or delivery? Which is actually more important?

Fortunately, we don’t have to make the choice. It turns out that the right thing to do is also the nice thing to do. All the good practices for delivering software tend to be respectful.

Yet we do make that choice, intuitively. A lot of the time, I see managers and change agents focusing on respect in order to get delivery. What if we turned that around? What if focusing on delivery could generate respect?

What is respect anyway?

Douglas Hubbard, in his talk on “How to measure anything”, proposed two questions:

  • Why do we care?
  • What do we observe when we have more of it?

I care about respect because it helps us get better outcomes. That doesn’t necessarily mean making people happy; I don’t believe that happiness is a good test.

I observe that respectful communication is focused on outcomes, or on options: either offering options to others, or explicitly retaining them. I observe that this tends to happen through forgiveness and transparency. I find that knowing about people’s constraints is useful. I find that respectful communication tends to be reflective, too, which matches the etymology of respect: it comes from the Latin specere or spicere meaning to look, so  it literally translates as “look back” or “look again”.

Conversely, disrespectful communication seems to happen more when constraints are unknown or non-existent, the system is unforgiving, and desired outcomes are unclear.

This maps very nicely to Dan Pink’s aspects of motivation: autonomy, mastery and purpose. Autonomy can only happen when people have the skills to do the job, and the constraints on them are just enough to allow them to organize to do it. Mastery happens when a system is forgiving enough to allow people to learn. Purpose happens when we share outcomes transparently. So respect and motivation are heavily linked.

But wait! I’ve just described a system of skilled people, learning together to find out what outcomes are desired and what the right thing to do might look like.

That looks an awful lot like software delivery anyway. Maybe the most respectful thing we can do is to get out of people’s way and let them get their job done?

Some systems encourage disrespect

In a system which encourages disrespect, we have to act as individuals if we want respect, and that intervention may not actually be rewarded.

Any system which has a lack of constraint (so people may not be skilled enough to act within it), a lack of forgiveness (so people cannot reverse decisions easily or take back their mistakes) and a lack of transparency (so desired outcomes cannot easily be known), is likely to cause disrespect.

Readers, meet Twitter: the place in which conversation is highly public, constrained only by the character limit, and in which we can only guess at people’s intent.

I have seen more disrespectful communication over Twitter than any other medium. It’s closely followed by email, which has the same problems as Twitter while enabling us to write even more. At least with email we have the space to express our intent and to ask reflective questions.

Disrespectful communication may not help you

We sometimes tell ourselves to count to 10 before responding to someone. This is because it gives us time to think about the outcomes that might result from our response.

I do this a lot. While I count to 10, I think about the options that I might be limiting for myself; the outcome that I truly want; examples of outcomes that I might get as a result of what I’m about to say.

I’ve been told that I come across as respectful, a lot of the time (nobody’s perfect). The thing is, I don’t think of myself as being respectful. I think of this behaviour as utterly self-serving, since it allows me to make mistakes while chasing the things I want. It also helps to set up systems in which other people respond the same way, giving us all more options and clearer understanding of intent.

Disrespectful communication often burns our bridges, leaving us with no options to reverse our decisions. We do it because we’re human, but not because it’s useful.

Caveat

These are highly experimental thoughts. It may be that no system is sufficient to counter the influence of those people who are determined to be disrespectful: people who hide their goals, hold grudges, and expect more from the people around them than can reasonably be given.

It’s just possible, however, that if we help to build systems which are focused, constrained, transparent and forgiving, we might actually end up helping to change those people’s behaviour as a result.

I would love to find out. So, if you behave differently as a result of this post, or set up different types of systems, please let me know what happens.

Posted in complexity, feedback, real options | 3 Comments

If you can’t write tests first, at least write tests second

Posted on April 24, 2013 by Liz

I had a very interesting discussion at GOTO Chicago with the awesome Corey Haines, software journeyman and founder of the Code Retreat movement.

We were talking about the “Spike and Stabilize” pattern, and whether it was a good idea to suggest (as I have) that experienced TDDers can skip TDD under situations of flux and high uncertainty. I still maintain that you have to be really good at TDD to write spikes and stabilize them, and agree with Corey that most developers will get more traction from throwing away their prototypes once they have feedback, and start again “properly”.

However, I think the skill of being able to take existing, messy code, clean it up, and bring it under test, is hugely important.

Developers aren’t born knowing how to do TDD effectively. New developers will always be coming into our industry, and they’ll always be making a mess until they learn how to make things clean. If you can write your tests first, that’s absolutely fantastic! But if you can’t – or if someone on your team can’t – then being able to tidy up the code, and being able to show others how to do it, is IMO even more important than getting it right in the first place… and it’s not just novice devs who make the messes, either. We’re all human.

So if you can’t write tests first, at least write tests second. Then try writing them first next time.

Posted in spike and stabilize | 4 Comments

The Five Whos

Posted on March 26, 2013 by Liz

Many of the companies I visit start with much the same problem: the development team aren’t collaborating effectively either internally or with the business, so they would like to adopt Agile, or better forms of Agile.

Usually these are pretty awesome companies producing quality software, and it can take a while to work out what the real problem is, and why they want to collaborate more effectively in the first place (other than a vague feeling that “it’s good”).

Asking around for more context, I usually find that while much of the software written is fantastic, a lot of it gets thrown away towards the end of the project, or is surplus to what’s truly needed for the release, and what the clients would really like is for that to happen much less, and releases to happen more often – the promise of Agile, delivered.

Asking further, it often transpires that the projects have either been created without a clear vision in mind, or that the vision has not been communicated clearly, or that the needs of peripheral stakeholders are only being taken into account in a very woolly fashion, perhaps with a single story card saying “Monitoring”.

If you ask the development team, “Why are you doing that?” five times, they will perfectly happily give the answer – as long as it’s a requirement that’s core to the project, at least. They may even, sometimes, be right.

Ask about something like security or performance, though, or try to find out who has the final say on whether something’s ready for production, and in larger companies the development team often don’t know. They think they know why, and that’s usually more dangerous than being aware that we don’t know. I can often tell because their stories either start with, “As a user…”, or miss that line completely, or it’s only ever one Product Owner who gets to come to the showcase.

I’ve just written a blog post for the Lean Systems Society called “Value Streams are Made of People”, which is related to this. Here’s a paraphrased tl;dr:

Before we ask why, ask who. Who will be the first person who cares outside of the development team if we don’t do this? Who do they have to tell, or if they were to (hypothetically) hide it, who would be the next person to notice? Who cares after that? And who’s the person whose job, or company or – heaven forfend – life is on the line as a result?

If we don’t know who cares, how can we know who to ask to find out why?

Posted in business value, stakeholders, stories | Leave a comment

BDD for Life – revisited at GOTO Chicago

Posted on March 12, 2013 by Liz

A couple of years back, I ran a talk on how to apply some of BDD’s techniques to your whole life, and to life coaching.

I am very excited to announce that this year, at GOTO Chicago (April 23rd – 24th), I will be revisiting that talk, but this time I’ll be looking at some of the more crazy stuff we’ve introduced into BDD’s toolbox over the last few years, too.

There will be even more focus on Real Options and Deliberate Discovery – but I’ll be using Cynefin to show where, and how, you can usefully apply them in your life. I’ll be talking about Dan North’s “Three Ages” delivery pattern, and showing how that applies to our everyday activities. I’ll still be looking at well-formed outcomes as a test, but I’ll also show how we can never quite achieve the things we want the most, and every outcome we think of is just an example of what might happen. I’ll show how to fail, quickly and safely, using Feature Injection; how to get your life under test, TDD-style, before you refactor it; how and when to use real-life libraries and open-source to cut down the amount of work you have to do; and how to create your own for other people to use.

Want to come? Just use the code “keog150” when registering here, and you can get $150 off your entrance price. Looking forward to seeing you there!

Posted in bdd, conference, life | Leave a comment

Two exercises, one puzzle

Posted on February 15, 2013 by Liz

Today Benjamin Mitchell played a small exercise I really liked during his Kanban talk.

Benjamin gave each of two people 5 A4 envelopes and 5 pieces of paper. The two people were given instructions to either write a letter sequentially, or to do it in batches.

The sequential person had to put the paper in the envelope, write their address on the front then mark an “X” for a stamp. They had to do this 5 times.

The batch person had to do each of those steps in turn; filling in 5 envelopes, writing 5 addresses and “putting on” 5 stamps.

Now, I remember another exercise which teaches us that multi-tasking is bad. If we’re asked to write all the letters of the alphabet as capitals, then write them all as small letters, then write the numbers from 1 to 26, we do this much more easily by doing the whole of one job than we do by switching between them. It’s very hard to write, “A, a, 1, B, b, 2” – much harder than it is to just write “ABCDEF…” etc. It gets even nastier if we write roman numerals too!

For that reason, I predicted that the batch job would finish more quickly. It’s not like software development, where we do different things. It should be even simpler than writing a sequence. It’s the same thing, five times.

Yet the person working sequentially – doing each letter in turn – finished a long time before the other person. The addresses looked about the same length, and the sequential worker had written his far more neatly, too! Benjamin’s reaction told us that this was pretty standard for the exercise – he expected this.

Why? What was it about this exercise that meant the person writing each letter in turn went so much faster than the one filling the letters, then writing the addresses, then the stamps?

I have a couple of ideas, but I’m curious to see what the community thinks! I’ll write the most interesting answers in an edit here… as well as the most outrageous ones. Let me know in comments, and if you try it yourself I’d love to know the results.

Edit: I said I’d write the most interesting answers here, but too many of them are interesting. I do particularly like this breakdown of the game, via Graham Lee.

Don Reinertsen’s explanation of transaction costs is also helpful:

I am a big proponent of reducing batch size, but the viability of small batches ultimately depends on transaction costs. If you ran the game with the envelopes, the letters, the writing desk, and the stamps each in separate corners of the room, or in different buildings, you would undoubtedly get a very different outcome. Reducing transaction costs enables the payoff brought by small batches.

Thank you all for your illuminating answers!

Posted in kanban | 22 Comments

The Eighth Day

Posted on December 21, 2012 by Liz

Scholars immersed in books
Rise blearily, wiping their eyes,
And gather in knots of threes and fours
In the angles of the square.
They avoid each other’s anxious looks;
The crowds who gathered to hear the wise
Are turned away from the college doors
To seek answers elsewhere.

Staunch pigeons flinch from the open sky,
As though they knew that a day was more
Than light’s rebirth with every morn;
For how can a day be measured when
A wealth of suns see time go by
And seas which ate up all their shore
Once spanned the world from dawn to dawn
Before the age of men?

A street-sweeper smashes his father’s watch.
He doesn’t want to hear it tick
When every second is one second less.
The dying smile as though justified,
The foolish count their money and clutch
At jewels, and build their houses of brick,
And lovers, trembling, whisper, “Yes”,
With the rictus grin of the terrified.

Shopkeepers let the looters in
And laugh as they take the TV sets,
The fridges, iPods and video games,
And over the tannoy some shining wit
Plays “Abide with me” as the evening draws in.
A group of soldiers make heartless bets;
One of them calls out his children’s names,
And in the windows, the candles are lit.

Only babies sleep that night;
Oblivious, older children play.
The adults wonder how long it will last
And cry as the twilight fades to black.
They cosset the moon, and the candlelight,
The preacher falls silent, and dares not pray –
The seventh day is fading fast
And God is coming back.

 
 
 

Happy Apocalypse Day, and a very Merry Christmas!

Posted in Uncategorized | Leave a comment

How to run Safety Checks

Posted on December 5, 2012 by Liz

Before I run a retrospective, I often run a safety check.

The purpose of the safety check is to see how safe people feel sharing their opinions or problems in the room. I’ve been doing this for some years now, and have made many terrible, horrible mistakes! So I thought I would share my learning and help others avoid the same fate.

The format

I usually get people to write a number from 1 to 5 on a piece of paper, where 5 is “I feel safe to share anything” and 1 is “I am not comfortable sharing my real opinions so I’m going to smile and nod and pretend to be happy.”

If a team is mostly 3’s or above, I think it’s worth doing the retro. If it isn’t, the retro will be pointless. I’ve sometimes asked management if we can run the retro without them, if comparative safety checks suggest that’s a better idea (please, managers, try and find someone else to run your team’s retrospective!)

I was even once safety-checked out of a retrospective I was meant to run as a coach – the company were making redundancies, and the teams thought our input might have contributed. I got some very useful feedback on my coaching after letting someone else run the retro with me out of the room!

Another format is “E, S, V, P”:

– Explorers want to discover everything they can
– Shoppers have some things they’d like to pick up
– Vacationers are just happy to be away from their desks
– Prisoners come only because they’re forced to.

I’ve started replacing that last one, Prisoner, with Worker, since nobody is actually forced to come or made a victim by doing so.

The safety check should be anonymous

I once ran a safety check with a great team who knew each other really well. The PM said, “Fine,” and threw a 5 into the middle of the table. The rest of the team followed suit. “We all get on very well and feel very safe,” one person pointed out.

I asked if they minded practising doing it properly, on the grounds that we had the offshore devs joining us a week later. I made sure they had the same pens, the same post-its, so that nobody could see who had voted for what.

The first piece of paper we unfolded said “4”. “Who wrote that?” the PM asked.

Now the team does it completely anonymously.

Safety checks should not be shared

A couple of years ago, I stopped sharing the safety check. These days I tell teams, “Only I will see these numbers. They will go in the bin when I am finished; nobody will know. I won’t even share the average. I will just tell you if there are some people feeling unsafe, so that we can think of ways to make things safer, and I’ll tell you if it’s worth running the retrospective.”

The teams I do this with seem to consistently vote lower than those who see the numbers. I take this as a sign that they feel more comfortable being honest.

Sometimes I may do other things to increase safety – for instance, getting someone else that the team trusts to gather up the numbers before I look at them, or asking the coach of another team if they’ll help run it, so that my agenda isn’t on the table either.

Project Managers and retrospectives

It’s easy to bias conversation so that your agenda gets discussed. All you have to do, as a facilitator, is encourage discussion which goes your way and encourage interruption when it doesn’t. And you know what? You’ll be doing this anyway; you can’t help it. It’s human nature.

This is why I prefer PMs not to run their own retrospectives. Even the best, most open-minded PMs can’t help but overlay their own agenda on it, and the worst control the retros to the extent that nobody feels safe to speak. Find someone from another team to help out instead, and go help out with theirs.

A special note about Art Attack

Of all the retrospective formats I’ve used, Art Attack – getting people to draw what’s in their heads, then talk about it – is the format most likely to cause controversy. Teams will often hide the elephant in the room when they talk about it, but seem quite willing to draw it! Again, I’ve had some very frank and helpful feedback myself from running Art Attack retrospectives.

If you’re thinking of running this format with a new team, consider running a safety check first!

Posted in learning, values | 3 Comments

BDD Training – a bit differently

Posted on November 8, 2012 by Liz

Did you know that there are types of requirements which are so uncertain that talking through them will just end in arguing about them? Or that some requirements are so well understood they’re simply boring? That some requirements are more likely to change than others? Would you like to be able to tell the difference, ask relevant questions and know when you’ve got enough understanding to start coding?

Would you like to be able to use your stakeholders’ time more effectively, and have them be truly engaged in conversations? How about using those conversations as a risk management tool? What if the conversations gave you more clarity on the big picture – the vision of the project, the stakeholders involved and their goals, and the capabilities being delivered?

What if you could use these ideas to help keep automated scenarios and tests minimal and maintainable, phrased in a language the business use?

Would you like to use these techniques beyond software – in everyday life, as a coaching tool, or to help find smaller personal goals that will give you more options for reaching the larger life-changing ones?

Behaviour-Driven Development uses examples of how a system should behave to explore the intended value and behaviour of that system, with a heavy focus on discovering uncertainty, uncovering risk and avoiding misunderstandings and premature commitments.

If you’re a developer wanting to learn Cucumber, I highly recommend Matt Wynne’s BDD Kickstart. If you come to my sessions, you might not see any code at all. Instead, I focus on helping people have effective conversations and a mindset that makes a difference across the entire team. As part of my BDD tutorials you’ll get an introduction to Cynefin and complexity thinking, Deliberate Discovery, Real Options, Feature Injection, and – of course – Behaviour-Driven Development. The tutorials are highly interactive, full of experiential exercises, and consistently highly rated by attendees, with unique workshops and conversations that you won’t get anywhere else.

If you like to have powerful conversations and help to create software that makes a difference, watch this space and my Twitter feed for upcoming tutorials near you, or get in touch if you’d like them run internally (whole teams welcome!). 2 and 3-day Agile, Lean and BDD courses are also available.

My next 1-day tutorial will be at Agile Island 2012, Reykjavik, on the 28th of November. There’s still time to sign up now!

Posted in bdd | 4 Comments