Traversing the Ocean of Knowledge

The Five Whos

sirenian — Tue, 26 Mar 2013 16:18:31 GMT

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.

BDD for Life – revisited at GOTO Chicago

sirenian — Tue, 12 Mar 2013 16:19:54 GMT

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.

Two exercises, one puzzle

sirenian — Fri, 15 Feb 2013 16:04:38 GMT

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.

The Eighth Day

sirenian — Fri, 21 Dec 2012 00:01:58 GMT

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.

How to run Safety Checks

sirenian — Wed, 05 Dec 2012 09:04:37 GMT

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.

BDD Training – a bit differently

sirenian — Thu, 08 Nov 2012 14:03:57 GMT

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.

Learning English

sirenian — Wed, 31 Oct 2012 13:18:43 GMT

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.

The Joy of Arrogance

sirenian — Tue, 02 Oct 2012 13:16:08 GMT

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.

The Deliberate Discovery Workshop

sirenian — Fri, 21 Sep 2012 13:01:11 GMT

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.

Instructions

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.

Examples in the large

sirenian — Sat, 07 Jul 2012 10:04:29 GMT

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.

Beyond Test Driven Development

sirenian — Sun, 24 Jun 2012 15:37:24 GMT

Clarification: this isn’t a post about BDD vs. TDD, it’s a post about Spike and Stabilize. Tagging those now.

For love of TDD

Dan North and I have been talking about some different ways of writing software that matters. We’ve been talking about not doing TDD, and not automating BDD scenarios.

A lot of people have reacted to these suggestions with something approaching visceral horror, as if we’ve committed outright heresey, which I guess we have. TDD is such a game-changing practice that those who’ve discovered it recently may not be able to even imagine a world without it, since that would mean going backwards. So I want to explain a little bit about my take on TDD, just to make it really clear, and then introduce some different ideas.

TDD is amazing.

TDD is a truly important practice that every developer who writes code for a living ought to know about and attempt to master. TDD is how I learnt to write maintainable code; design classes with appropriate and single responsibilities; understand what it was that I was really trying to achieve.

The people who came up with TDD are deserving of every respect, which I haven’t always given them. I decided to start with that this time just to make it clear. TDD is a flippin’ awesome practice. When we talk about “BDD isn’t just TDD”, it definitely evolved from it. If TDD hadn’t existed, BDD and ATDD wouldn’t have either. So a big, massive thank you to all those people who helped create and espouse the values of TDD.

If you haven’t experienced really great TDD, stop reading. This post is not for you. Go read Bob Martin’s many articles and posts, or Kent Beck’s book, or find your local code retreat instead. You will get more out of that time than reading this article.

Beyond TDD

Dan North and I have been talking about moving beyond TDD for a while. Here’s a confession: I don’t always write my tests first. I often don’t automate scenarios up-front either. And I consider it right for me not to do so.

Dan recently blogged on the opportunity costs of our various practices, and used TDD as an example of a practice that carries such a cost. It can take longer to produce software with TDD than without. I know this because I’ve tried it both ways, as has Dan. We do something that Dan calls “Spike and Stabilize” – trying one or several things quickly to get feedback, then stabilizing the end result after we’ve managed to eliminate some of the uncertainty around what we’re doing. I can’t tell the difference between the end result when I TDD something to when I spike and stabilize, except that the second one lets me get feedback from my stakeholders faster, and is easier to change in response to that feedback.

For me, that means starting with a UI and knocking out something approximate, frequently with hard-coded data. If the UI is the place of uncertainty, I’ll show it to the stakeholder immediately, or try it a couple of ways. Sometimes it might be a performance concern, in which case the UI will be something that exercises the performance. Sometimes I might need some simple behaviour behind the UI, which I also just “hack out”.

I keep all the code I’m writing clear, readable and easy to change. I can do this because I can write examples of how my class is going to work (a.k.a. unit tests) in my head. That’s come from hours of doing TDD, at work, at home, at code retreats, after work, during lunch hours. If you want to be really, really great at coding, I think you do need to have the 10,000 hours of practice that Malcolm Gladwell talks about. I’m pretty good rather than really good (and particularly, I have shallow rather than deep knowledge) but I get TDD enough to move beyond it. I’m emphasising this not to show off my knowledge, but to stop anyone who’s still learning TDD from thinking, “Oh, this is great! I can just do what Liz does.” Get good at TDD first.

Dan works with amazing people who are way better than I am. He’s damned good too. Developers like Dan and his team don’t need TDD in order to create good designs, separate responsibilities or simple code that does just enough to do the job. They’re really good at TDD, and have moved beyond it.

For most people, TDD is a mechanism for discovery and learning. For some of us, if we can write an example in our heads, our biggest areas of learning probably lie elsewhere. Since ignorance is the constraint in our system, and we’re not ignorant about much that TDD can teach us, skipping TDD allows us to go faster. This isn’t true of everything. Occasionally the feedback is on some complex piece of business logic. Every time I’ve tried to do that without TDD it’s stung me, so I’m getting better at working out when to do it, and when it’s OK to skip it. If in doubt, I do TDD. I recommend this as a general principle. Otherwise, I try to eliminate the ignorance I have. Here are the rules I’ve learnt which help me to spike things out and stabilize them.

If in doubt, do TDD.
If it’s complex enough or has enough learning in it that pairing is useful, do TDD.
When spiking, hard-code the context rather than adding behaviour wherever possible. Hard-coded data doesn’t require TDDing.
Don’t pick the right libraries or technology. Pick the technology that’s easy to change. And don’t write tests around other people’s libraries – isolate them through interfaces or adapters instead.
Once the uncertainty you’re dealing with is no longer the area of greatest ignorance, stabilize by adding tests. You’ll be able to tell at this stage if you should have TDD’d first based on how much rework you have to do to make the tests readable.
Adding tests afterwards is especially important if you’re working in a team with mixed skills or silo’d roles, or other teams in the same code-base, as your team-mates and colleagues will need them to provide documentation.
Adding tests afterwards is especially important if you’re the kind of person who forgets what it was you were working on after a couple of months (i.e.: just about everyone).
Adding tests afterwards requires even more discipline than adding them before-hand. If you find you’re under pressure to skip that step, do TDD instead.
No amount of automated testing is a substitute for trying out the code you’ve just written manually.
If your user is another system, hack something out to allow you to pretend to be that other system, then stabilize that. You’ll need it later.

By doing TDD – writing our tests first, or before we’ve got feedback on what it is we’d like to achieve – we are creating a premature commitment. The principles of Real Options say, “Never commit early unless you know why”. If you’re working with uncertainty, and if you can avoid adding investment before getting feedback – for any practice – then you will actually go quicker and be able to respond to discovery faster. You will be more agile.

However, if you don’t yet know how to write software that’s easy to change and maintain, every piece of code you write is a more concrete commitment than it will be if you learn to do TDD, since TDD helps you to adopt these practices, as well as providing nice documentation and living examples of how to use your code, how it behaves and why it’s valuable. If you haven’t yet experienced amazing TDD and you try doing things this way, you’ll probably find that you end up with a lot of rework when you come to stabilize the spike (and if you don’t stabilize the spike, you’ll eat up cost in maintenance later).

It’s interesting to me that this is actually how a lot of people learn to do TDD – by adding tests afterwards, until they gain enough confidence to add tests first. It really does remind me of this quote from Bruce Lee:

Before I studied the art, a punch to me was just like a punch, a kick just like a kick. After I learned the art, a punch was no longer a punch, a kick no longer a kick. Now that I’ve understood the art, a punch is just like a punch, a kick just like a kick. The height of cultivation is really nothing special. It is merely simplicity; the ability to express the utmost with the minimum.

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

BDD in the large

sirenian — Fri, 01 Jun 2012 12:08:34 GMT

One of the biggest problems I encounter with BDD is that it was started by developers, for developers, so that we could get a better grip on what it was we were developing.

As we began to understand the complexities of what we were developing, conversations with business stakeholders started to become more fluid. We started to understand what it was like to handle multiple stakeholders; to have uncertainty around requirements where stakeholders weren’t really sure about the outcomes they wanted; to pay to delay decisions about implementation until later.

There are three practices / principles / bodies of knowledge and experience which I use and teach as part of BDD, and I don’t think BDD works well without them. Good BDDers have taught these practices anyway, sometimes without giving them a name, so I wanted to call them out explicitly so you know that they’re there and can use their names to go find out more.

This is the stuff that happens in conversation, before developers get anywhere near a keyboard.

Feature Injection

A large number of Agile projects have backlogs of user stories. Some of these backlogs can be quite large. One team had over a year’s worth of stories, covering four walls of a room. Scrum and other Agile practitioners talk about “grooming the backlog”; reacting to their growing understanding of the real problem by removing some stories and adding more in. Even Agile teams can be sidetracked by “quick” two-week-long analysis phases, or two-hour planning sessions, or additional functionality that still fits within their deadline when they could have shipped three weeks ago.

What if you didn’t have to do this?

Lean proponents talk about minimum viable products or increments, in which we determine the smallest thing that could make a difference to the problem, then do the minimum necessary to ship. Feature Injection, introduced to me by Chris Matts, is a fantastic technique for discovering that minimum. Here’s how it works.

Every project worth pursuing has a vision - either something new, or something that you’ve seen someone else do and you want to do it too. The vision is designed to increase revenue, decrease costs or protect revenue – for instance, keeping customers from going to a competitor (note that there’s no ROI for a vision like that!)
There may be other stakeholders whose goals need to be met in order to allow the vision to go live. Frequently these stakeholders have traditionally gatekeeping roles – UAT, Architecture, Legal, Security. By recognizing these stakeholders early, we get a chance to turn them into educators instead.
To meet the stakeholder’s goals, we create capabilities. For instance, employees might need the capability to book a holiday. Notice that they could quite easily do that with paper! To make our differentiating vision compelling, we may need a certain amount of commoditised functionality – things that people will expect in that kind of application. When David Anderson talks about differentiators he uses the mobile phone market. An example of a differentiator is the first ever camera in a phone. We’ll also need to be able to make calls, receive calls, look up numbers, etc.
To deliver the capabilities, we design features. We may decide that some features are too complex, and create manual workarounds instead. The features represent the way in which users will use the capabilities we’re giving them – through a browser, a windows client, a mobile phone, etc. Now we’re starting to move into the areas of UI design, preferably with a UI designer, and developers and testers can really get involved if they weren’t already! Even if the development team wasn’t involved in the conversations before this point, I recommend they should be aware of the outcomes and able to map their features back into the capabilities, stakeholder goals and initial vision. Even better, the team might only have the capabilities on their backlog – breaking them down into features as and when they reach the next capability (see Deliberate Discovery for prioritisation).
To really explore the features, we talk through scenarios; examples of the outcomes a system should produce when a user uses it in different contexts. We can use the scenarios to decide what we want to get feedback on, and thus divide the features into stories. The main purpose of dividing things into stories is to be able to get feedback quickly.

Scenarios are the BDD artifacts people are most familiar with, but look how much happens before we even get this far! And that’s without budget negotiations, portfolio management, company strategy, recruitment and all the other gubbins needed to get a development team up and running…

After that, we can move into the traditional development space – TDD (or unit-level BDD if you prefer), code, integration and, we hope, production.

Deliberate Discovery

In Agile projects, we normally prioritise stories by their value. But wait a moment! If we’re doing Feature Injection, our vision is for the smallest valuable thing we could ship (otherwise, that smaller thing would be our minimum viable product). So we can’t really say that one feature is more valuable than another, because we need them all (and if we don’t, that’s our minimum viable product!).

What we can say, though, is that we know more about some of the features than others. Commoditised features, particularly, will have been done before, and we can probably estimate them and make predictions about them, as long as we have enough expertise in the domain. Anything that’s new, or that’s new to the team, we’ll know less about. We can bet that there are some things in there that we’ll discover as we code, some of which will come back to bite us. These are the kind of things which can really derail a project.

In the spirit of failing fast, we’d really like to have our projects derailed early, while we can still change our minds and perhaps think of something else to do instead. Deliberate discovery is the act of assuming ignorance, then going to look for it and optimizing to address it first. There will always be things we don’t know we don’t know – but since those things will usually show up in the functionality we’ve not delivered before, why don’t we do the new stuff first?

If you’re into Theory of Constraints, you know that in a production line environment, you tailor your system to the constraining machine, putting it first where possible. But software development is more like product development; it’s creative knowledge work, rather than doing the same thing over and over again. Ignorance is the constraint.

This is how we prioritise – by the features and capabilities about which we’re most ignorant. It helps us to address the risk early. Since the risky stuff is usually what keeps our stakeholders awake at night, this is a great way of establishing trust, too.

Real Options

As well as the things we don’t know, there will also be things we don’t know that we don’t know. No amount of analysis will ever allow us to discover everything! So we have to keep ourselves ready to change.

Unfortunately, we human beings don’t work well with uncertainty, and have a tendency to try and eliminate it. One of the ways we do that is to break down problems into their components. That works very well for predictable stuff that we’ve done before, but not for new things which we don’t understand so well. Doing this for new functionality only leads to the uncertainty being hidden away!

So what can we do to keep our options open, so that our ignorant ignorance doesn’t bite us?

Chris Matts took the concept of trading options – the right, but not the obligation to buy copper at $1000 a tonne in October, for instance – and worked out which aspects of options still apply to Real Life. Here are his principles:

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

With Deliberate Discovery, we’re getting what information we can before we make a larger commitment, so Deliberate Discovery plays into this very nicely. There’s another thing we can do, though. We can pay to keep our options open. This is what we do when we take time out to design our code well or refactor it so that it’s understandable. We’re creating options for the future.

When we talk through our scenarios and we see our P.O. frowning or saying, “Um…” then we know there’s uncertainty there. It might be worth spiking out a feature cheaply, to see if it does the job, before pinning that feature down with automation (or even, dare I say, unit tests). Discovering that uncertainty and ignorance is at the heart of BDD – not finding the examples, but finding the examples we can’t find.

Another practice Chris taught me off the back of this is, “Don’t pick the right technology. Pick the technology that’s easy to change.” Whenever we have a choice and not enough information to help us make the decision, picking a decision that’s cheap to change later usually turns out to be a good way forward, as we can change when we have more information (or keep it if it turns out to be good enough!)

BDD is just TDD?

Sure, if you’re a developer, and you only get to see the stuff that happens in development. Even then, it may be worth talking through not just the scenarios, but the larger-scale picture; discovering uncertainty and ignorance, paying to keep options open, and working towards a clear and compelling vision to deliver software that’s not only well-tested and functional, but which really, truly matters.

In this post, I’ve focused on the differences between BDD and TDD, most of which have been spawned by the language of BDD which allows for more appreciation of uncertainty than the language of TDD. For the similarities, and more about the history of how BDD was originally derived from TDD, see this article.

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

Showcasing the language of BDD

sirenian — Wed, 30 May 2012 14:29:22 GMT

Since there are a few debates going on (again!) about whether BDD is just TDD done well, I thought it might be interesting to showcase some examples where BDD language made a difference to people’s understanding.

From StackOverflow, TDD – Should Private/Protected methods be under unit test?:

Original Poster wrote:

In TDD development, the first thing you typically do is to create your interface and then begin writing your unit tests against that interface. As you progress through the TDD process you would end-up creating a class that implements the interface and then at some point your unit test would pass.

I wrote: Please let me rephrase this in BDD language:

When describing why a class is valuable and how it behaves, the first thing you typically do is to create an example of how to use the class, often via its interface*. As you add desired behavior you end up creating a class which provides that value, and then at some point your example works.

*May be an actual Interface or simply the accessible API of the class, eg: Ruby doesn’t have interfaces.

This is why you don’t test private methods – because a test is an example of how to use the class, and you can’t actually use them.

Response: Brilliant post. Clarifies a lot.

From StackOverflow, should i only be testing public interfaces in BDD (in general, and specifically in ruby) (sic):

I wrote:

Instead of writing a test, you’re going to write an example of how you can use your class (and you can’t use it except through public methods). You’re going to show why your class is valuable to other classes. You’re defining the scope of your class’s responsibilities, while showing (through mocks) what responsibilities are delegated elsewhere.

At the same time, you can question whether the responsibilities are appropriate, and tune the methods on your class to be as intuitively usable as possible. You’re looking for code which is easy to understand and use, rather than code which is easy to write.

If you can think in terms of examples and providing value through behaviour, you’ll create code that’s easy to use, with examples and descriptions that other people can follow. You’ll make your code safe and easy to change. If you think about testing, you’ll pin it down so that nobody can break it. You’ll make it hard to change.

Response: good answer! very concise!

From comments on my blog post, “Translating TDD to BDD”:

Ben asked: Given this terminology, can you reword these sentences to eliminate the TDD terminology, but in such a way that someone who doesn’t know what BDD is can understand it?

Writing the tests first ensures that the code we write to make them pass is actually testable. Otherwise, we may wind up with classes and methods that, although fairly well designed, are not easily tested

I replied:

Writing examples of how to use the code, before we write the code that makes those examples work, ensures that the code we write is easy to use and understand. Otherwise, we may wind up with code that, although adhering to SOLID principles, has been written to be easy to write rather than easy to use or maintain.

(Of course, if you’re doing true outside-in then you already have one example of how to use a piece of code, from its consuming class. I reworded this from ‘well-designed’ to ‘adhering to SOLID principles’, since they’re necessary for good design but IMHO not sufficient.)

Ben responded: Liz, that’s beautiful. I especially like how you phrased your points about use and maintenance. Takes the focus off “testing” and puts it on something that’s more directly tied to value.

Taking it up a level, again from StackOverflow, Are BDD tests acceptance tests?

BDD “tests” exist at multiple different levels of granularity, all the way up to the initial project vision. Most people know about the scenarios. A few people remember that BDD started off with the word “should” as a replacement for JUnit’s “test” – as a replacement for TDD. The reason I put “tests” in quotes is because BDD isn’t really about testing; it’s focused on finding the places where there’s a lack or mismatch of understanding.

Because of that focus, the conversations are much more important than the BDD tools.

Acceptance testing doesn’t actually mandate the conversations, and usually works from the assumption that the tests you’re writing are the right tests. In BDD we assume that we don’t know what we’re doing (and probably don’t know that we don’t know). This is why we use things like “Given, When, Then” – so that we can have conversations around the scenarios and / or unit-level examples.

We don’t call them “acceptance tests” because you can’t ask a business person “Please help me with my acceptance test”. Try “I’d like to talk to you about the scenario where…” instead. Or, “Can you give me an example?” Either of these are good. Calling them “Acceptance tests” starts making people think that you’re actually doing testing, which would imply that you know what you’re doing and just want to make sure you’ve done it. At that point, conversations tend to focus on how quickly you can get the wrong thing out, instead of about the fact you’re getting out the wrong thing.

Response: 20 upvotes and a “nice answer” badge!

These are just a few instances of using BDD’s language instead of TDD’s. I’ve found it even more powerful in spoken language, and more powerful still when talking to business-focused stakeholders about examples of how we might use a system to deliver the value they want. I taught BDD to my dad once, showing him how to write examples in Java in order to ensure that his code would be usable and maintainable. After we’d written a couple of classes, I said, “Of course, this also gives you a nice set of regression tests.”

“Oh, yes!” he said, “So it does. I hadn’t thought of that.”

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

Upcoming engagements

sirenian — Wed, 09 May 2012 11:23:32 GMT

There are a few exciting speaking and training engagements coming up, many of them UK based!

First off, two tutorials:

I’m running my first Deliberate Discovery, Cynefin and Real Options tutorial at Skills Matter on 29th May. These three ways of thinking and modelling software development and the world in general have really helped me, and I’d like to pass the techniques on. Highly workshop-driven and not at all technical.

At the end of September I’ll be running my 1-day BDD tutorial as part of Agile Cambridge. This is the only BDD tutorial I’ll be running this year, so if you’re interested, get in there now! Dan North (my mentor in all things BDD and Agile) and David Snowden (Complexity Thinking and Cynefin guru) are keynote speakers, so it promises to be an excellent conference!

I’ll also be speaking and running workshops through the year:

The Next Generation Testing Conference organised by Unicom is on the 23rd. I’ll be on the panel talking about Agile, and particularly ranting about our obsession with granularity and our need for certainty even where it doesn’t really exist.

I’m going to be talking about Real Options at Dev Tank in London on the 29th, after the Progressive .NET Tutorials. It shouldn’t be a long talk, so lots of opportunity to catch up with your fellow devs over a beer. More details to follow – watch the space!

On June 7th, I’ll be giving an overview of BDD, how to do it well and why it works at Agile East Anglia. If you’ve been out of the loop on BDD, this is a great chance to get into it, and I’ll be answering any questions you have too. I think there may be just one ticket left…

In August I’ll be at Agile 2012 in Dallas, running “Turning and turning in the Widening Gyre”, a workshop on complexity and deliberate discovery, and “BDD: Look, no Frameworks!” on how to do BDD using custom DSLs instead of BDD tools, while keeping steps maintainable and readable.

On 21st – 22nd September I’m honoured to be one of the keynote speakers at Lean Agile Scotland. Topic still to be decided, but it’s going to be related to people and the inside of our heads; one of my favourite minefields.

I’m also speaking at GOTO this year (October 1st to 3rd, Aarhus, Denmark). In my talk, “To be honest…” I’ll be looking at why honesty is so important and yet so hard to do.

In the meantime, I have some days free for in-house training or coaching. Please get in touch now, before the rest of the year gets this busy too!

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

Commitment – a novel about managing project risk

sirenian — Sat, 31 Mar 2012 13:31:32 GMT

If you’ve heard me speak at any conferences or read my blog over the last few years, you’ll know that I’m really, really into Real Options.

I’m half-tempted to get “Options have value. Options expire,” added to my tattoo. The principles which Chris Matts and Olav Maassen champion have become such guiding forces in my life that many of the decisions I make are only done in order to increase the number of options available to me. Once the whole innate phobia of uncertainty is out of the way, it’s a fantastic way to live life in freedom and with fun.

Real Options are also a phenomenal model for managing risk on software project – and not the only brilliant idea that Chris and Olav have!

So imagine my absolute joy when I saw this in the works – a graphical novel, fun and easy to read and understand, dealing with all kinds of ideas around risk management. The skiing story at the end of the first chapter (downloadable from the link) is the same one that Chris shared with me to help me understand his ideas.

Chris and Olav describe it as “a business graphic novel on managing risk. The book is a culmination of their collaboration on the real options model over the last six years. It provides examples of how to manage a project using the real options model and outlines a simple technique for making better (informed) decisions. It also covers more advanced topics such as information arrival process, game theory, feature injection, paradox of choice and how to deal with uncertainty. While geared towards project managers, the book benefits anyone making decisions in their job or daily life. Chris and Olav focus on making risk management easily understandable as everybody does this every day without being aware of it. ”

I am very confident that this book is going to be ground-breaking. I am so confident that I’ve already laid out £500 of hard-earned cash for a chance to star in the book (sorry, that option has expired). I don’t regard this as charity. This is me doing something small to pay Chris and Olav back for their guidance and help over the last few years, and it’s money they’ve helped me earn anyway. Estimated publishing date is Winter 2012… assuming they manage to raise the funds to kick it off.

If you would like to help these two fantastic people get this novel out of the door and benefit from the same help they’ve given me, please go to the Sponsume site before April 14th and pick an option. You never know – you could be the proud owner of a limited edition of a book that turns out to be as ground-breaking as “The Goal”*.

*What do you mean, you haven’t read it? Go. Buy it. Now! It’s already out and will give you something to read in the meantime while you’re waiting for “Commitment”.

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

The Myth of “What” and “How”

sirenian — Mon, 05 Mar 2012 21:19:31 GMT

I often hear things like, “Tell the team what to build, but don’t tell them how to build it.”

Or, “A feature is what you’re building. A story is how you’re going to build it.”

Or, “When you’re doing TDD, don’t worry about the internals of the class. The API is what it does. The internals are how it does it.”

Here’s the thing. When we write code, that’s how we’re creating a story or a feature. It’s also how we’re implementing the architecture. It’s how we’re managing security and providing an audit trail and doing a bunch of other stuff.

And that’s how we’re selling more goods. And how we’re keeping things maintainable for the future. And how we’re preventing data theft. And how we’re correcting our mistakes.

And that’s how we’re staying in business. And how we’ll be able to react in the future. And how we’re able to sleep at night. And how we learn.

The code is how we deliver a story.
The story is how we deliver a feature.
The feature is how we give the users the capability to do something.
The users’ capabilities are how they deliver a business goal.
The business goals are how stakeholders implement a vision.
The vision is an idea of how to make money, save money or protect revenue.
And we could keep going if we wanted to…

Every goal, no matter how big or small, is the how for someone’s what. (The how and the what may come from the same person, but the interesting stuff happens when they’re different people. Or behave like they are.)

If only life worked by being able to divide a bigger what up into smaller pieces and manage them appropriately, then it would all be fine! Unfortunately the code has to work with other code to deliver its value. The features have to work with other features. The system has to work with other systems, users have to work with other users and the goals of one stakeholder have to align with the goals of another.

This is why we have root cause analysis and the “5 Whys” – because when we can see the higher-level goals and deeper-rooted problems, we can understand better how our own actions fit into them, and what they deliver – for better or worse. This is also true for other domains than software.

It doesn’t really matter much whether we call them features, stories or tasks, as long we appreciate that they’re how we’re delivering to those higher-level whats, and we have a pretty good understanding of the whats and how to test that we’ve achieved them, even (especially!) if the what is a learning or exploratory goal.

Of course, we’ll get the how wrong occasionally and fail to deliver the what. But that’s what feedback, in its many forms, is for.

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

BDD Tutorial Slides are up

sirenian — Sun, 26 Feb 2012 13:22:25 GMT

I’ve been meaning to do this for a while. I have released my BDD Tutorial slides on SlideShare.

There are notes underneath each slide which are a cut-down version of the kind of things I talk about. I’ve even left the exercises in, with a description of what I do in each.

I am releasing these under my usual favourite licence – Creative Commons share-alike. That means that as long as you attribute me, and are similarly generous with any derived work you make, you can use the slides commercially and base your own work on them.

Yes, that means that if you want to, and you feel qualified to do so, you can use the slides, run the course and get paid for it. If you don’t feel qualified, feel free to experiment. Just please give a nod my way when you do!

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

CALMalpha – the second request

sirenian — Sun, 19 Feb 2012 00:36:21 GMT

CALMalpha was meant to be a mash-up between the Lean, Agile and Cynefin / Complexity Theory practitioners.

The outcome of the unconference wasn’t really stated. When you understand that a complex domain is one in which the cause of an outcome can’t be perceived except in retrospect, this might make more sense. The only thing we were trying to do was see if there was a way of using complexity theory to help inform our practices, and if there were some practices from Agile and Lean that complexity theorists might find interesting – a mash-up!

There’s one problem with this.

Currently, the best-known leadership of Complexity Theory revolves around the company Cognitive Edge. These guys have some amazing methods for making sense of domains, spotting complex problems and providing data which calls out “weak signals” that might otherwise be lost. I paid good money and took time off work for the course last year, and it was worth every penny. For the non-initiated and tl;dr, imagine five new types of retrospective, a method for reducing planning meetings to five minutes, and six different ways of making the output from them heard, and you’ll get a vague idea of the impact and scope. Oh, and they’ve got software for running the retro across countries.

Except…

I can’t currently use the methods they taught me, not as a professional coach. The methods are open-sourced, but released under a non-commercial, non-derivative Creative Commons license.

Cognitive Edge, your Wiki says (emphasis mine):

The Cognitive Edge wiki exists to provide a collaborative space for accredited members of the Cognitive Edge Network. All accredited practitioners should feel welcome to contribute to the ideas and concepts in these pages.

The licence prevents me from using your methods as a professional coach:

You may not use this work for commercial purposes.

The licence also prevents non-accredited people, which is most of our communities and a lot of CALMalpha attendees, from creating their own ideas:

You may not alter, transform, or build upon this work.

While I might be able to build on your work, I’m unwilling to do so as long as my efforts fall under this licence. I also can’t pass on anything to the people I work with for their contribution.

Can you see how this doesn’t mesh with the idea of a “mash-up”, and goes completely against your ideas around multiplying perspectives?

So here’s my request.

Cognitive Edge, please, please open your licence up for commercial and derivative work.

The stuff you do is amazing. If you were working solely for the money, you wouldn’t have come up with these ideas. I can only assume that you, like us, are trying to make the world a better place. We will continue to attribute the methods to you and talk about how amazing they are. Those of us who’ve seen it will continue to point people towards your SenseMaker software (which is ground-breaking, world-changing, worth paying for the 1-day demo, and deserves the more rigorous patent applied to it – I look forward to the day when it’s a bit cheaper!)

As it stands, we can’t do anything useful with your methods. Worse, because you’re working in a space full of narratives and I’m working in a space full of very similar examples, I have to be very careful that my work – released on my blog under CC, non-commercial, non-derivative – is actually based on other sources (mostly Dan North and Chris Matts) and not on yours.

Please. Be generous. Reach out to your contributors, ask them, and release what you can.

Sometimes it’s worth doing something you can’t go back from.

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

You’re doing it wrong

sirenian — Fri, 23 Dec 2011 10:47:35 GMT

The first time I did it wrong, it was because I didn’t know any better.

The second time I did it wrong, it was because I forgot about the first time.

The third time I did it wrong, it was because I was really tired.

The fourth time I did it wrong, it was because someone else told me to.

The fifth time I did it wrong, it was because nobody lets anyone do things right around here.

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

Conversational patterns in BDD

sirenian — Thu, 22 Sep 2011 14:32:57 GMT

BDD isn’t about the tools. It’s about the conversations you have, exploring examples (or scenarios) of an application’s behaviour, to see if everyone has the right understanding.

Of course, we don’t know what we don’t know, so feedback is still important. We’ve got a good chance of discovering what someone else knows, and has perhaps forgotten to tell us, if we start questioning the ways in which our understanding might be wrong.

These are two patterns which I commonly use. You’ll notice that they follow from the typical BDD scenario template:

Given a context
When an event happens
Then an outcome should occur.

Context Questioning

We can ask, “Is there any other context which, when this event happens, will produce a different outcome?”

It might be an additional context, or a context which occurs instead of the one(s) we’re considering. We can ask this question, or we can think of contexts ourselves and ask about those. For instance:

Given a client manager, Fred, has two clients, George and Henry
When Fred uses the application
Then Fred should only be able to see George and Henry’s accounts.

I ask, “Given I have no client managers, what happens then?” (I’m thinking of handling empty lists, because I’m a developer.)

The head of Client Management says, “What? Who cares? Why are you even using the application? Get on the phone and get some clients already!” (He’s thinking of his failing business.)

You can sometimes learn a lot about a business domain this way, even if the behaviour of the application isn’t going to change immediately!

Outcome Questioning

This is similar to Context Questioning, but instead, we ask,

“Given this context, when this event happens, is there another outcome that’s important? Something we missed, perhaps?”

Another way I like to ask this is, “If pixies were doing this instead of software, would it be enough? Or do they need to do something else, too?”

For instance:

Given the legacy system has a problem
When a trader stores a trade
Then the trader should be told about the problem.

I ask, “Is that all that should happen? I’d be pretty upset if I were a trader and this happened a lot.”

My business analyst (by which I mean, someone who can analyse the business) says, “Well, we’ll still have the details in the system, so you’ll be able to do it again later. Oh, yes! We need to store the trade in our system still, too, but make sure it doesn’t have a legacy system ID so that we can tell it didn’t go through.”

And that’s it.

There are lots of other ways to have conversations around behaviour. They’ll usually be trying to find missing contexts and outcomes – places where a new piece of behaviour happens. These also tend to be the things which business users, familiar with their domains to the point where they don’t think about it, forget to talk about. Developers are pretty good at spotting this, because they’re usually thinking through how they’re going to implement the problem, and wondering what goes on the other side of the “if… else…” statement (even if we’re not meant to be implementing yet, we already are in our heads). Testers are also very good, because they’re used to the kind of things people get wrong when they produce software.

This is why getting all three people – a tester, a developer and a business analyst – is so useful when we’re discussing scenarios. It’s also why it’s so important to have the conversations – because if you’re not having conversations, you’re not doing BDD.

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

Splitting stories into tasks – when, why and how (or not)

sirenian — Tue, 23 Aug 2011 20:57:42 GMT

Before I write anything about this, I’d like to clarify what I mean by a task and a story.

A feature is something tangible that works and which we could potentially deliver, if it was enough to provide business benefit. Usually a bit of a screen or page, together with all the logic and validation associated with it, is a feature. A feature is the highest-level thing which a developer could work on without doing significant bits of analysis. It’s a part of an idea made at least concrete enough to imagine.

A story is a part of a feature on which we can get feedback from relevant stakeholders. For instance, we might code the UI, then the validation and messages, then an aspect or two of the behaviour behind the UI. Each of these would be a possible story. The only real reason for splitting features into stories is to get faster feedback and a better idea of progress.

A task is a part of a story which doesn’t allow us to get feedback from relevant stakeholders. If you can get feedback, it’s probably a story rather than a task, because it affects the UI in some way, or at least gives something that can be visibly verified and critiqued and which stakeholders care about. There are lots of UIs and lots of stakeholders and users, so “put logging in to help maintenance debug the situation where the elephant appears on the screen” might be a perfectly good story. Anything that’s just a part of a story is a task.

A task can’t really be tested either, even by a developer. You have no idea if a database has the right tables or data until you connect it to something. You have no idea if an interface to another system will work until it’s actually talking to that system. You might unit-test it, or run some queries, but it’s a level below the feedback and user testing available for features and stories. (There are higher levels of testing too, in which we can look for user capabilities and business outcomes, stakeholder goals, profit / loss, etc. – so you can’t really tell if *anything* works until you put it into production – but that’s a blog post for another day).

Why do some teams split stories into tasks?

A lot of Scrum teams particularly do this, because it’s traditionally taught as part of the Certified Scrum Master course. Hopefully good CSTs, and their CSMs, are teaching the benefits along with the practices.

It can lead to more accurate estimates. Splitting stories into tasks can help developers to think about the amount of work involved in a story, and find any pieces they missed.

It can help with collaboration. By splitting a story into tasks, developers can each take that task – usually a different horizontal slice – and work with minimal merge conflicts and just a bit of adjustment to get their piece working with other people’s. Splitting a story into tasks is useful for swarming, and a lot of swarming teams do this instinctively, even if they haven’t written the tasks down.

It can help senior developers mentor junior developers and verify that they’re taking a good approach towards a story. Some mistakes are worth avoiding.

They can be used as a measure of progress to someone tracking the team, like a PM or Scrum Master.

Why don’t other teams do this?

Some teams prefer to focus on delivering something on which they can get feedback, and find the tasks distracting.

There are also other ways of getting accurate estimates. Talking through scenarios can help with this. A lot of teams don’t use estimates anyway, preferring to stick to SLAs or their own instinctive understanding of how much work they can get done and whether they’re going to release on time. Anther purpose of estimation is usually so that the business stakeholders can have trust and confidence in the team, and there are different ways of getting the trust of stakeholders, too.

What bad things might happen if we split our stories into tasks?

Splitting stories into tasks might indeed distract from delivering something on which the team can get feedback. When a developer sees a list of tasks in front of him, he tends to work through those tasks methodically. He might not notice that, for instance, the team isn’t going to deliver *any* stories this week.

Using tasks to estimate team progress can also be misleading. If all the developers end up working on their own stories, the PM might see lots of tasks being done. If none of those stories are ready for the showcase, though, the team won’t be able to get feedback from their stakeholders – and might end up building the wrong things altogether! Also, the Pareto Principle suggests that 20% of the causes are responsible for 80% of the effects – or that the last 20% of the story might take 80% of the time. Often developers will start with the easy bits and leave the hard things until last.

People seeing the tasks can use them to micro-manage the team, asking who’s working on which task, or even assigning particular tasks ahead of time! But anyone with a manager or Scrum Master who does this has bigger problems than the task-splitting, I think.

Why do you absolutely hate people splitting tasks then putting hourly estimates on them?

First and foremost, this harks back to the old myth that time = work done. Even if developers are only held to be productive 50 or 60% of their “ideal” working day, the focus is still on the number of hours spent, rather than useful software being produced. It’s perfectly possible to spend hours on something that doesn’t work. A team which signs off all its tasks is subtly encouraged to say that they’re “done” without checking that the software they’re producing is useful.

What about the developer who plays with something else while turning over a problem in the back of his mind, then delivers an ingenious solution in 2 hours? Or the developer who wants to try out another way of solving the problem which might involve a steep learning curve, but which would benefit the project in the long run? By pinning these developers down to their hourly estimates, insisting on a certain timescale of productivity, we encourage them to tread the path they had in mind when they made the estimate, even if a different idea occurs to them at the time. Since human beings get a kick out of being right – suffering horribly from confirmation bias and the preference for validation – just the act of estimating the hours will pin them down subconsciously. They may not even think about the problem or have the new idea! Hourly estimates can stifle innovation, and the less wriggle room there is, the more innovation will be stifled.

Finally, it encourages micro-management. A project manager who sees a developer working on some tasks that should have taken 8 hours, but have taken all week, might wonder why that developer is taking so long. However, uncomfortable enquiries will only cause the developer to pad their estimates next time – and work expands to fill the time available, so the team will eventually slow down.

Should we do it or not?

If you think splitting stories into tasks might be helpful, try it. If it doesn’t help, stop. However, please resist the urge to put hourly estimates on them – or to ask that your team does so.

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

Done with Chickens and Pigs

sirenian — Thu, 11 Aug 2011 17:00:09 GMT

If you’re not familiar with the concept of Chickens and Pigs, it’s based on an old joke in which a chicken and a pig set up a restaurant. The chicken wants to call it “Ham’n'Eggs”. The pig says, “No thanks. I’d be committed, but you’d only be involved.”

The story is used in Scrum and other methodologies to suggest that only “pigs” – the people whose bacon is on the line – should have the right to speak in stand-ups. This deliberately excludes management.

Yesterday, Dean Leffingwell spoke on the subject at Agile 2011. He pointed out that the practice calls out the chickens as the “bad guys”. “Wrong!” he says. “These are the people who run the company.” Quite aside from some cultural implications of calling people “pigs” – it doesn’t go down well in countries which consider pigs to be unclean, for instance – excluding management from stand-ups can be disrespectful at best, and damaging at worst.

I finally decided to be done with the Chicken and Pigs analogy and practice after a roleplay organised by Derek Wade, in which the manager had something very important to share – something that would have reduced the stress the team was experiencing, as well as the workload, the weekend’s overtime, and the risk to delivery that was approaching our fictitious team.

The manager started to speak. “I…”

“You’re a chicken,” the Scrum Master announced. “Next!”

Let’s not.

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

The Gordon Pask Award

sirenian — Mon, 01 Aug 2011 17:52:06 GMT

Update:

I’m told that it’s too late to get the Pask sorted out for this year – we’re Agile, but not that Agile! Please keep nominees in mind, though. Many members of the committee are talking and are keen to keep the award in some form, so chances are it will be back next year. Watch this space.

It’s that time of year again that the Pask committee meets at the Agile 20XX conference to vote on the nominations which have been made.

The committee is mostly made up of people who’ve already won the award in previous years. We won because of our ideas, because we’re good at spreading them, because we made a difference, because we were under the radar… but not because of our organizational ability! So please forgive this very late post.

We are still collecting nominations (email pask-nominations AT agilealliance DOT org) and will be voting at some point during the week.

A number of people have suggested that the Pask Award doesn’t matter. I thought I’d share some of the things which have happened to me since winning the award last year, so that you can understand exactly what it is that’s being given away.

The Pask Award

It’s always wonderful to be recognised for your work. The award also comes with quite a hefty bit of money – enough to pay for a couple of international conferences, and then some. There’s no trophy, but you get to tell people that you won the award. Your parents will be dead chuffed. You can stand on stage and recognise all the people and communities who’ve helped you. And that’s just the award itself.

The Side Effects

The number of people following me on Twitter doubled overnight, from 500 to 1000. Then it kept climbing. I am now followed by over 1,600 people. That’s enabled me to spread a lot of other people’s messages, too.

Because people have started to know my name, I’ve started getting more offers of work. I’ve had requests for help from the USA, from all over Europe, from India. (Some of them have even offered to pay me!) I’ve been able to raise my rates a bit, and I’m getting all kinds of interesting opportunities which I didn’t have before.

Then, there’s the conference invites. Lots, and lots, and lots of invites to speak around the world. I’m sorry to those people that I’ve had to turn down – I am simply getting so many invites this year that I can’t do all of them, especially if they’re at the same time as others.

Because of the conference invites, I’m getting to speak more, and spread the ideas from my communities, which leads to more Twitter followers and more exposure and more conference invites… I suspect the escalation from this has started to reach a natural limit, but again, I apologise if I haven’t quite been able to keep up. It really has been a little bit insane.

The Further Side-Effects

Because of the invites, I’ve become a better speaker. This means I can now spread the ideas more effectively. They weren’t all my ideas in the first place – many of them came from communities in London and around the world – so now people recognise that I can share ideas effectively. This means more people are now giving me lots of ideas to share! So I’m learning an enormous amount, too. I feel insanely privileged to have such excellent friends and colleagues.

In short…

My life currently rocks beyond my ability to tell it. I’ve been able to help other people’s lives to rock too. A lot of this is due to the award. Many thanks to those who nominated and voted for me, and to the Agile Alliance for continuing to make a difference.

The Gift

If you would like someone to receive a similar gift to the one that I’ve been given in this last year, enabling them to spread their knowledge and ideas to other communities that they wouldn’t normally reach, please nominate at pask-nominations AT agilealliance DOT org. You can see the kind of things we’ve been nominated for in the past. Mostly we’re looking for people who aren’t particularly famous or well known; who haven’t written books or run keynotes, who sit “below the radar”, and could benefit from more exposure – and who will benefit their communities in turn, passing on the opportunities and making the best use of the fame that comes with it.

Do you know of anyone who’s helped their communities? Who’s driven Agile forward in difficult or unusual circumstances? Who’s created an idea, or a community, or a tool, that’s truly revolutionary?

If so, don’t wait – post that email now.

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

ATDD vs. BDD, and a potted history of some related stuff

sirenian — Mon, 27 Jun 2011 20:03:28 GMT

Another question that people often ask around or to me is, “What’s the difference between Acceptance Test Driven Development and Behavior Driven Development?”

To explain, I’ll go back to the time when I first learnt BDD.

BDD started at a unit or class level

Dan North started doing BDD at a unit or class level, as a replacement for TDD – a mechanism for describing the behaviour of code and providing examples, without using the word “test”, because it turned out that this clarified a lot of the confusion (and I still find it much easier to teach TDD if I avoid the word “test”, whatever I subsequently call it).

It was only when Chris Matts said, “That looks quite a lot like analysis,” that Dan began taking it out to describe the behaviour of whole systems of code.

ATDD practices at the time weren’t all that solid

When I came across BDD (late 2004), I was working on a project which had been driven quite heavily with ATDD – at least to start with.

This project had 160 acceptance tests. They all consisted of lists of text boxes, button clicks, locating more text boxes and repeating until a particular outcome was reached. They were lengthy. They were rigorous. Unfortunately, at some point someone had introduced a dialog box into the flow, disrupting about 30% of these tests. There were another 10% also failing, possibly for similar reasons.

It took a couple of days for two of us to work through them, fixing the tests. We got most of them working, but not enough for anyone to actually care about them. The acceptance tests were making things hard to change.

BDD changed the landscape

Dan has since said that JBehave was “just a thought experiment”, and he didn’t really expect anyone to use it. (That’s good, because it JBehave 1.0 was pretty unusable, at least at a scenario level). It worked as a thought experiment, though, and lots of people started doing ATDD in a very different way – creating examples of how their system worked, and using those examples to explore the scope of their systems as well as the responsibility of their classes. Lots of people started working outside-in, from the UIs through which users experienced the system’s behaviour, to the controllers, the domain models, the utility classes, services, repositories, etc., until they finally had working software that tended to matter more to the stakeholders of the project than software had before.

Dave Chelimsky’s movement over to plain text really helped this movement to take off. When people think of “BDD” they often think of the frameworks which have copied this (Cucumber and JBehave 2.0 amongst them), even though this isn’t the complete story. They have certainly encouraged developers – famous for their introverted natures – to boldly go into the analysis space.

BDD enabled conversation

Whether through frameworks, DSLs or just conversation, the biggest difference between BDD and ATDD was the way in which BDD enabled a common language between users and business stakeholders, because it supports Domain Driven Design’s “ubiquitous language” (forgive the rabbit-in-the-headlights look, it was my first ever video!), and provides its own ubiquitous language for software development – the language of examples and behaviour, rather than tests and acceptance criteria.

The second difference was the reusability of steps. This is something which a lot of BDDers are still struggling with, so we’ve still got a way to go here. (More on steps and business / system capabilities some other time).

BDD doesn’t just stop at scenarios, it goes all the way to the project vision

Finally, Chris Matts introduced Feature Injection, which takes BDD’s patterns all the way into the analysis space.

(I consider Feature Injection and BDD to be children of Deliberate Discovery (even though they preceded it), which is itself a child of Real Options. I summarise Deliberate Discovery as the act of wilfully addressing ignorance. Both Deliberate Discovery and Real Options have implications and uses beyond software development, and I heartily recommend coaches and managers to go read up on them. In fact, everyone who lives a life of any kind of uncertainty should go and read up on them. And if your life is staid and comfortable, maybe it will help you to step into those challenging spaces. Go do it anyway.)

Or at least, this used to be the difference…

So that’s the past. What about now?

Well, most people who do ATDD nowadays use the Given-When-Then template which Chris introduced (shout-out to Gojko Adzic for his work in this space). They use domain language in conversation with the business. They’re interested in discussing what software would actually make a difference, then capturing that and sometimes automating it, with a focus on working out the software which would matter.

I’m guided by Dan’s words to the BDD Google Group, which apply both to TDD and ATDD:

I think you can over-think these things.
I’d like to avoid “BDD is better than TDD because…” or even “BDD is
different from TDD (as originally envisioned) because…”

TDD is amazing. Its initial conception was to solve exactly what I’ve been
trying to do with BDD. Originally it was described as variable scope (i.e.
covering both the space of modern day TDD-in-the-small and what the ATDD/SBE
folks are doing in the functional testing space). It’s not the *only* way to
come up with good design, and neither is BDD. They’re just both useful to
have in your back pocket as you go around trying to write decent software to
solve useful problems.

They’re called different things

The difference is that one is called Behaviour Driven Development – and some people find that wording useful – and one (or two) is called (Acceptance) Test Driven Development – and some people find that wording useful in a different way.

And that’s it.

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

Acceptance Criteria vs. Scenarios

sirenian — Mon, 20 Jun 2011 08:49:58 GMT

Some common confusion I’ve come across recently involves the difference between a Scenario and Acceptance Criteria.

I’ll start by defining these two things as I understand them.

A scenario is an example of the system’s behavior from one or more users’ perspectives.
Acceptance criteria are a set of rules which cover aspects of a system’s behavior, and from which scenarios can be derived.

Here’s a scenario from the pet shop I use in my BDD tutorials.

Given a rabbit called Fluffy who is 1 1/2 months old When we try to sell Fluffy Then we should be told Fluffy is too young.

This is an example of the kind of thing a pet shop employee might encounter in the till software. It’s quite specific, containing actual data, and illustrates our domain nicely. We can tell quite a lot from this: that pets have names, that there are rules around the sale of pets, the units in which we measure the age of young pets, etc.

We can’t tell, though, what age we would be allowed to sell the pets. Is it fixed? For all pets? Let’s look at something else:

Given a baby animal is younger than its recommended selling age When we try to sell it Then we should be told it's too young.

Despite the Given, When and Then, this is not a scenario. It’s acceptance criteria – a full specification of this aspect of behavior – phrased in scenario form. A lot of the time, I see people write criteria like this, then become confused when they can’t treat it like a real scenario – discussing it in detail, deriving further edge cases, automating it, etc.

Talking through scenarios is, for me, the most important aspect of BDD. That’s how we discover whether we have a shared understanding or not; by using specific examples to illustrate our understanding or discover our ignorance.

When we’re discussing the scenarios, it isn’t always necessary to write scenarios for all the acceptance criteria. As long as the acceptance criteria are clear enough to derive the relevant scenarios easily, I recommend leaving it as acceptance criteria until the point where it needs to be automated. You can tell if the scenarios can be derived in just a few seconds of conversation. You don’t need to write down everything.

It’s also possible to phrase acceptance criteria in other ways:

We should be prevented from selling animals younger than the recommended age.

Now you can talk through the scenarios, and see potential other criteria which you missed:

Customers should be encouraged to return when the animal is old enough to sell.

As you’re talking through the scenarios, the information we need for automation will emerge, and a better understanding of the domain spreads amongst the people involved in those discussions (usually a dev, BD and tester):

Given rabbits can't be sold before they're 2 months old Given Fluffy the rabbit is 1 1/2 months old When we try to sell Fluffy Then we should be prompted to tell the customer, "This pet is too young. Please come back in 15 days to collect your pet."

By talking about both acceptance criteria and scenarios, asking why, and using scenarios to illustrate the criteria, we find out more about our domain. We can also automate them later on, where they’ll help to provide living documentation and act as regression tests.

There’s one other difference between a Scenario and Acceptance Criteria or even an Acceptance Test. You can ask your business stakeholders, “Can you give me a scenario where that happens?” or “Can you give me an example?” I’ve found this often draws out more useful discussions than, “Can you give me acceptance criteria for this?” or “Can you help me work out how to test this?”

The language of BDD, and particularly its vocabulary, provide a ubiquitous language for analysis and development.

Now we’re talking.

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