You are viewing sirenian

Tue, Mar. 26th, 2013, 04:18 pm
The Five Whos

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?

Originally published at Liz Keogh's blog. Please leave any comments there.

Tue, Mar. 12th, 2013, 04:19 pm
BDD for Life – revisited at GOTO Chicago

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!

Originally published at Liz Keogh's blog. Please leave any comments there.

Fri, Feb. 15th, 2013, 04:04 pm
Two exercises, one puzzle

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!

Originally published at Liz Keogh's blog. Please leave any comments there.

Fri, Dec. 21st, 2012, 12:01 am
The Eighth Day

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!

Originally published at Liz Keogh's blog. Please leave any comments there.

Wed, Dec. 5th, 2012, 09:04 am
How to run Safety Checks

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!

Originally published at Liz Keogh's blog. Please leave any comments there.

Thu, Nov. 8th, 2012, 02:03 pm
BDD Training – a bit differently

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!

Originally published at Liz Keogh's blog. Please leave any comments there.

Wed, Oct. 31st, 2012, 01:15 pm
Learning English

Since much of my focus is on getting people to talk and communicate effectively, I thought I would share a couple of sites that might be of use to people wanting to learn the language we tend to communicate in – English.

English StackExchange is “a free, community driven Q&A for linguists, etymologists, and serious English language enthusiasts” – experienced writers and speakers who are wondering about more advanced topics. Favourite questions include, “How do you quote a passage that has used ‘[sic]‘ mistakenly?”, and “Did English ever have a formal version of ‘you’?” (It turns out to be you, with thou being informal – who knew?)

However, the community has little patience for people who ask questions about correct use of grammar and vocabulary, and heaven help you if you don’t actually use those in your questions! A new site has now been proposed, and backed by some of the experts over at the advanced site: English Language Learners StackExchange. It needs a few more people to enter its beta, so if you feel like you could use some help with your English as she is spoke, or you think you know enough to help out others, why not head on over and make the commitment to ask or answer 10 questions?

While I’m here: it’s means it is, its means belonging to it. Please be kind to your apostrophes.

Originally published at Liz Keogh's blog. Please leave any comments there.

Tue, Oct. 2nd, 2012, 02:16 pm
The Joy of Arrogance

I’m awesome, and arrogant.

I’m awesome, and arrogant, and I know it, and this makes me joyful. I wanted to share that joy with you, and explain why I think arrogance is so important, and humility overrated.

For a start, humility suffers from a Catch-22 condition: if you have it, you can’t know you have it, because if you know you have it you don’t. Only arrogant people believe themselves to be humble (but not all arrogant people, since some of us know we are).

Secondly, we’re all arrogant. Arrogant people are unable to learn, thinking that they already know the answer. This is a natural part of the human condition – it’s called confirmation bias – and we all suffer from it. The world simply has too much data in it to be able to take it all in, so we abstract from what we observe, come to conclusions as a result, form beliefs based on those conclusions, and filter our observations based on our beliefs. This is perfectly normal behaviour.

There are some people who believe that because they are aware of confirmation bias, they don’t suffer from it any more. Dan North calls this bias bias. People who are seeking humility are trying to escape from confirmation bias. It would be a fantastic goal, if it wasn’t essentially impossible. The quest for humility is itself a form of bias bias.

Tobias Mayer wrote in his recent blog post on humility, “Humility allows for quiet, internal reflection; it is a tool for rightsizing oneself, and thus opens up greater possibilities for thoughtful, considerate, and open interaction with others.” And yet, this quality isn’t something that just magically appears out of thin air. The only way to discover that we have opinions which we hold too strongly is to share those opinions, and sharing an opinion that we hold strongly but don’t recognise as being biased by our beliefs… well, we will share it as if it’s a fact, and come across as arrogant. Fact.

If we reflect internally, what changes? Where do the new opinions come from?

They come from other people who are sharing their opinions. If humility listens and arrogance talks, then we need arrogance in order for humility to be of any use whatsoever.

There’s a rather lovely phrase: “Strong opinions, weakly held.” That blog post that I’ve just linked to talks about “Wisdom as the courage to act on your knowledge AND the humility to doubt what you know.” Have you ever tried to doubt what you know? Not just suspect, but actually know? Again, we’re asking for the impossible.

Here’s what I’m going to do. Instead of doubting what I know, I’m going to focus on finding out what you know. I’m going to do that by sharing my strongest beliefs – as I have in this blog, as have all the bloggers on humility. I will ask questions only about those things about which I am uncertain. I will do this because there’s a good chance that I’m right, and because my essential human nature makes it impossible for me to do anything else. If I do ask questions, I will gain certainty, and then I will share my wonderful new knowledge with you, because it will be true and I will be right. If I’m wrong, you will no doubt set me straight, because you believe you’re right too. I probably won’t believe you at first, because I’ll be busy filtering whatever you say to fit my model, so you might have to persist and perhaps remind me that I am human and therefore arrogant. Your duty to me, as a fellow human being, is to be arrogant enough, and forgiving enough of my arrogance, to do that.

Because I’m awesome, and arrogant, and so are you.

Originally published at Liz Keogh's blog. Please leave any comments there.

Fri, Sep. 21st, 2012, 02:01 pm
The Deliberate Discovery Workshop

This is a pretty simple workshop which I ran at Agile 2011 and have run as part of my BDD tutorial since. It usually gets people thinking differently, so I thought I’d share it with you too. Some teams have taken this away to use as another retrospective format, and I’m always fascinated by the stories that come out! It can often lead nicely into an explanation of Cynefin, and also introduces Real Options (it turns out that Deliberate Discovery and Real Options are two sides of the same coin).

I tend to give the instructions out one column at a time, to avoid people overthinking and trying to aim for some outcome at the end. I also walk round the room and ask if anyone’s having difficulty coming up with ideas, particularly with respect to the commitment. Identifying the moment of commitment – or recognising that someone else is making the commitment for you – is the heart of the workshop. Big thanks to Dominica for trying this out and helping with reflection on what works.


In groups of 3 to 4 people, get a big piece of paper and divide it into 4 columns.

1: Tell a story

Each person tells a story about a discovery; either a problem they encountered, or something they found out that they wish they’d known earlier. Give the story a title. Dan North likes “the one where (this happened)”. Put the title on a post-it or just write it into the first column.

If working with a large group, get 1 person from each small group to share their story.

2: Identify the commitment

What decision had already been made that meant it was a problem? Did you make a promise or have one made on your behalf? What was the point at which the decision became hard to reverse? When did an investment get made that was hard to recover? Put this in column 2.

If working with a large group, it might be worth picking out one of the examples to work through so they get the idea.

Examples might include decisions around scope and deadlines, external communications, spending money, or writing the wrong code.

3: Deliberate Discovery

Were there any ways you could have discovered information earlier that would have led to a different decision? Who could you have talked to? Where was the information located, and could you have gone there? This goes in column 3.

Examples might include talking to customers, sitting with users, trying to release early.

4: Real Options

Were there any ways of paying to keep options open, perhaps making the commitment later, when more information was present? Was the commitment simply made too early?

Examples might include good rollback procedures, using technology that’s easy to change, agreeing a range of dates instead of a deadline.

Wrap Up

If working in a large group, get each smal group to share their insights and anything interesting they discovered.

How likely is it that something similar will happen again?

If very likely, would adding the discovery process you identified help you avoid this problem? (This matches the “complicated” Cynefin domain, so cause and effect can usually be correlated and making the discovery early will often prevent the problem occurring.)

If it’s unlikely to happen again, would adding the options process also provide options in any other cases? (This matches the “complex” Cynefin domain, and processes which create options allow decisions to become safe-to-fail experiments or probes instead.)

Whatever the insights, this can then be used as a way of changing the process – and everyone loves to tell stories about problems they encountered!

Originally published at Liz Keogh's blog. Please leave any comments there.

Sat, Jul. 7th, 2012, 11:04 am
Examples in the large

A couple of posts ago, I wrote about Feature Injection. Here’s a quick summary of how I do it:

  • Vision: A primary or core stakeholder has a vision which will save money, make money or protect revenue.
  • Goals: As well as his own goal, the goals of other stakeholders will have to be met too, in order for the vision to go live.
  • Capabilities: To deliver the goal, we provide the users and the system with the capabilities to do something.
  • Features: Most capabilities could be achieved with people, paper and pen, but we like to help by providing software. A feature is a widget, or a part of an application, or a page on a website, which supports the capability.
  • Stories: Features are quite large, so we break them into vertical slices on which we can get feedback.
  • Scenarios: A scenario is an example of a user using the system. We can use scenarios to explore the requirements, discover things we haven’t thought about and break up our features and our scope.
  • Code: Finally, we get to see the vision become reality!

I also wrote about two patterns I use in conversation with scenarios: context questioning, and outcome questioning.

Given a context, when an event happens, then an outcome should occur.

  • Is there any other context which produces a different outcome for the same event?
  • Is this the only outcome that’s important, or does something else need to happen too?

Normally when we think of scenarios, we think of a user using the system. However, we can use these two patterns at scale, as well.

Given a stakeholder, when we deliver this software, then we should meet his goals. Is there any essential stakeholder whose goals we haven’t met? Is there any other goal we need to meet at the same time?

As an example, think of writing software for air traffic control. Obviously the pilots are stakeholders. What about the regulatory authorities? What are their goals? Will the airlines be able to stop us going live? Are there legal concerns?

Given a feature, when we deliver this software, then the user should have the capability to do something.

As an example, consider a trading system. Does the feature for booking a trade provide the whole capability? What about auditing? Approvals? This is also a great way to discover other missing stakeholders!

Given a vision, when we deliver this software, then we should protect our revenue.

Will this really stop our customers from going somewhere else? Is there some context in the market which we’re missing? If we deliver this software, are there any other possible outcomes or repercussions? Perhaps Facebook or RBS could have used this pattern…

By questioning what should happen, and asking, “Should it?”, we can use the same familiar patterns at scale to discover even more potential scope, explore our ignorance and reach a common understanding or find places where there isn’t one.

Wouldn’t it be nice if we could write tests for those examples at scale, too?

Originally published at Liz Keogh's blog. Please leave any comments there.

10 most recent