Conversational patterns in BDD

Posted on September 22, 2011 by Liz

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.

Posted in bdd, breaking models | 6 Comments

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

Posted on August 23, 2011 by Liz

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 them, they tend to work through those tasks methodically. They 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 their 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.

Posted in feedback, scrum, stories | 14 Comments

Done with Chickens and Pigs

Posted on August 11, 2011 by Liz

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.

Posted in coaching, conference, scrum | 16 Comments

The Gordon Pask Award

Posted on August 1, 2011 by Liz

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.

Posted in conference, life | 4 Comments

Deliberate Discovery – a “Sonnet”

Posted on June 30, 2011 by Liz

Uncertainty’s the muse of all that’s new,
And ignorance the space in which she plays;
A year’s enough to prove a vision true,
But we could prove it false in only days.
We dream, and chase our dream, and never fear
To fail, and fail. Up, up! And on again,
But ask us to pursue another’s goals
And failure makes us mice where we were men.
Ah, best laid plans! Where were you at the end
Who chained us and constrained us from the start?
We knew you made a fickle, fragile friend;
You tricked us when you claimed you had a heart!
We thought less travelled roads would see us winning
In places other fools had feared to stray –
If only we had known from the beginning
The ignorance we found along the way.
And yet, a list of dangers and disasters
Filled out, and scanned, and added to some more
Would still have left out some of what we mastered –
We didn’t know we didn’t know before.

We planned our way with maps we’d made already
Assuming the terrain would be the same,
Expecting well-paved roads to keep us steady
And any local creatures to be tame.
We loaded up our caravans and wagons
With good advice, best practices and tools
But didn’t spot the legend – “Here be dragons!”
So we got burnt, again. They say that fools
Rush in, and yet we count ourselves as wise,
We praise each other’s skill and raise a glass
To intellect – ignoring the demise
Of expeditions just as skilled as ours.
When they return, worn out, their pride in shreds,
We laugh and say, “A death march! You expect
Such things to fail.” And in our clever heads
It’s obvious – at least in retrospect.
The dragons of our ignorance will slay us
If we don’t slay them first. We could be brave
And work for kings who don’t refuse to pay us
When we’re delayed because we found their cave.

They say that matter cannot be created,
A fundamental principle and law,
While dragons keep emerging, unabated;
As many as you slay, there’s still one more.
Our ignorance is limitless – be grateful,
Or else we’d find we’ve nothing left to learn;
To be surprised by dragons may be fateful,
But truth be told, it’s best laid plans that burn.
We could seek out the dragons in their dungeons
And tread there softly, ready to retreat;
We could seek other roads, postponing large ones,
And only fight the ones we might defeat.
The world could be a world of dragon slayers
And stand as men and women, not as mice;
The joy that comes from learning more should sway us;
The fiercest dragons won’t surprise us twice.
Discover tiny dragons, be they few,
And all the mightiest, with equal praise –
Uncertainty’s our muse of all that’s new,
And ignorance the space in which she plays.

Posted in bdd, deliberate discovery, life, writing | 9 Comments

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

Posted on June 27, 2011 by Liz

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.

Posted in bdd, business value, stories, testing | 15 Comments

Acceptance Criteria vs. Scenarios

Posted on June 20, 2011 by Liz

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.

Posted in bdd | 27 Comments

Questions on BDD

Posted on May 24, 2011 by Liz

After my BDD tutorial at XP 2011, some attendees asked if I could write up a list of the review questions I asked afterwards. I asked them because they reflected on the things that I hoped the attendees learned, and to get feedback in case they hadn’t. As it was, they answered these questions very well!

I’ve rephrased these questions slightly because the attendees had more context… and included some which I wish I had asked!

  • Why is BDD not focused on testing? What is it focused on instead?
  • How do we typically phrase scenarios?
  • Why do we focus on user and system capabilities in scenarios?
  • What’s more important than writing down or automating scenarios?
  • What’s the difference between a ‘Given’ and a ‘When’?
  • Why do we split features into stories?
  • Why don’t we create scenarios for every user story up front?
  • What are the different granularities of requirements in Feature Injection and BDD?
  • Why do scenarios, of all the granularities, get so much attention in BDD?
  • How do the principles of Real Options play into BDD?
  • What single word was important to the start of BDD, and why?
  • Who should meet up to talk through scenarios before implementing the code?
  • Why do we want to get feedback quickly?
  • Can you give me an example of a stakeholder that isn’t a user?
  • What’s Context Questioning?
  • What’s Outcome Questioning?

If you’d like to know more about how I answer these questions, I’ll be running introductory BDD tutorials later in the year at a few conferences, including Agile 2011 (August, USA) and Agile Testing Days 2011 (November, Europe). The tutorials include aspects of Real Options, Deliberate Discovery and Feature Injection, and focus on analysis, conversations and creating useful scenarios far more than on the tools.

Posted in bdd | 4 Comments

Gaming Culture with the Dreyfus Model

Posted on May 5, 2011 by Liz

A few people here at the Lean Software & Systems Conference have asked me to write more about using the Dreyfus Model to game culture.

I’ve already written quite a bit about the Dreyfus Model – how to use it to create experts, grow teams, etc. – but this is more of an experience report.

I was working with a number of other coaches to transform a small IT organisation. We were asked to come up with some strategies for spreading the adopton happening in a couple of teams. When we presented our options, the head of IT went with one of the faster ones: giving us an afternoon every 2 weeks to play a game with the developers.

We assigned developers and testers to teams made up of people they hadn’t worked with before, one tester to two developers. Then we gave each team the requirements for the Game of Life – just the basics:

  • Cells with less than two neighbours die
  • Cells with more than three neighbours die
  • Cells with exactly three neighbours are born in empty spaces.

We gave them 15 points for developing these rules, and also scored them according to the cultural values we saw, taken from Kent Beck’s XP books:

  • Respect
  • Communication
  • Courage
  • Simplicity
  • Feedback

We were already using Dreyfus models with numeric values to help individuals move forward. We adapted these for the game:

  1. Novice: team exhibit antipatterns
  2. Experienced Beginner: team are human
  3. Practitioner: team are behaving like successful Agile team members
  4. Knowledgeable Practitioner: team behaviour influences others
  5. Expert: superhuman.

By the end of the game I don’t remember that we had any 2s left, let alone 1s, and one team were exhibiting 4s. Here’s what we did.

How we did the marking

The 5 coaches got together at the end of every session to share their notes – what we had seen, how the teams had behaved, what points we thought they should have. If we hadn’t seen anything particular, we gave them a 2 – ordinary human beings.

Whenever a team exhibited particular antipatterns (1) or particularly excellent behaviour (3-4), we gave them feedback as to why. We also only ever marked whole teams. If a particular member of the team was showing anti-patterns, it was the whole team’s responsibility to help them adopt a better culture.

We also held a clinic in which team members could ask for clarification, or advice about how to improve their score the next week.

An example of marking

On the first day, one team named themselves “Team Buttplug”. The coaches had spent a while putting the game together – coding a UI for the teams to use, setting up version control, etc. – and we felt that this wasn’t very respectful of our efforts. So we gave the team a 1.

The next week, the team renamed themselves “Team Redemption”, and scored a 3. We appreciated their turnaround!

The stories

After the first week, we added more stories, which made the software progressively more complex. The testers started having plenty to do!

The stories we added were:

  • The grid can now switch from bounded (no cells outside it) to infinite (gliders run off the edge).
  • The grid can switch from any other to wrapped (gliders return on the other side).
  • The cells change colour depending on how old they are.
  • The cells change size depending on how many neighbours they have.
  • The rules can change from Conway’s rules to High Life (cells are also born when they have 6 neighbours).
  • Users can step backwards.
  • Users can scroll around infinite or wrapped grids using a joystick.

Gaming the culture

The teams quickly worked out that behaving according to the culture was an easier way to get points than developing the increasingly complex software.

“What will you do if we just pretend to be courageous?” one developer asked.

“How will you do that?”

“Well, we’ll just pick up things we’ve never done before. Or we could pretend to communicate; just get a whiteboard and talk about what we’re doing and draw on it.”

“Sure, we’ll give you the points if we can’t tell the difference…”

Of course, these cultural values are really hard to game without actually adopting them. Teams pretending to communicate better actually were communicating better. Teams exhibiting respect engendered respect around them. The culture of all the teams gradually improved. People started to be more forgiving; to provide feedback to us as well as to each other; to treat each other with respect and collaborate more and more effectively.

The end-game

On the last afternoon, two teams from the 8 we had were almost neck and neck. There was 1 point in it. One of them had developed more of the software – they had a particularly heroic developer who did much of the work.

The other team had started off poorly. They weren’t the best at development. However, they were using their tester very effectively, talking to us and clarifying the requirements, discussing their design on the whiteboard… and slowly overtaking the first team.

They won by 1 point. Thoroughly deserved.

All the teams who participated were amazing, but most of all I remember the head of IT who let us run the game in the first place. That commitment to learning really helped the teams understand the importance of what they were doing.

Swanky prizes helped, of course!

Posted in coaching, learning models | 8 Comments

Be nice to your PMs

Posted on March 24, 2011 by Liz

After my talk at QCon London, some of the feedback I got was that I was really, really mean to PMs.

In fairness, I was also mean to Tech Leads, architects and other managers, both in and out of software, as well as treating development teams as if they were made of sheep. It was a talk titled “Learning, Perverse Incentives and the Evil Hat”, and it focused on how we game systems, as set up by people who create the processes through which those systems emerge. But, mostly, I was indeed really, really mean to PMs. My hat was evil. I’m sorry.

And because I hadn’t been mean enough, Dan North and I ganged up to do it again during our Deliberate Discovery talk at Cuke-Up today.

It’s very easy for me to take the mick, especially out of a role that I’ve never taken on. I’d like to redress the balance.

Project Managers – the good ones, anyway – are invaluable. They protect us from the stress of high-level management and business politics. They spot obstacles coming and help prevent them from hitting the team. They negotiate deadlines. They facilitate collaboration between teams and across departments. They manage the budget. They work to protect the stuff that’s working and address the stuff which isn’t. The best project managers are servant leaders; invested in providing a motivating, learning, creative environment in which useful, effective software development can actually happen.

Not all project managers are good project managers. This is mostly because they’re learning, and while we get environments in which we can share our skills and learn from each other – pair-programming, talking, fixing problems together – project managers are frequently put in competition with others (because the high-level managers are still learning, too). The politics and existing processes can make their job hard. Really, really hard. They’re expected to be independent. They’re expected to know how to do their job. As one PM put it, “It’s a lonely place to be.” I’ve not yet worked as a PM, but I’ve coached a few.

So be nice to your project managers, and give them an environment in which they can learn. A PM is also human, and will make mistakes. Make it safe for them to say “Sorry”. Take them down the pub for a chat, and give them honest feedback. Very few PMs actually bite, and most will be grateful.

If you can do this enough, hopefully they’ll forgive you for the taunts, easy jibes and jokes at their expense. And hopefully they’ll forgive me too.

Posted in coaching | 1 Comment