GROW, Systems Thinking and writing a novel

Posted on October 15, 2008 by Liz

GROW stands for Goal, Reality, Options, Way forward.

As a coach, I frequently use GROW as a method of helping people move forward. Find the Goal, examine the Reality and all the resources available, look at Options for getting closer then pick one or more as a Way Forward.

As part of this, I encourage coaches and participants to think of how they’ll know they’ve achieved the goal. What are you going to see? If I reach that goal in a different way, will it achieve your aims, or is there another context that we haven’t considered yet? (Anyone into BDD, ATDD or acceptance criteria generally will find this familiar!)

I also use this technique on myself, to help me achieve the things I want to. And, for ever such a long time, I’ve wanted to write a novel. November is National Novel Writing month; it seems an appropriate time to kick-start this. Also, I just ran a coaching session in which I encouraged others to go for their dreams. It seems a little hypocritical not to have a go myself!

So, I’m going to try and use the GROW framework on myself, as well as some other techniques I’ve picked up from IT, and see if I can apply it successfully to writing a book.

First step: Work out what my goal looks like once I’ve achieved it

I already have a couple of chapters which I originally wrote as short stories, and which turn out to have some threads of a larger story running through them, so I’m a little bit ahead of the game. That’s a good thing, since NaNoWriMo value “quantity over quality”, and that’s not enough for me.

I don’t just want to write a novel. I want it published. And I don’t want to have to pay some vanity publisher either. I want someone else to find my novel so wonderful that they’re prepared to pay me to publish it. There’s my Goal – my first paycheck as a writer!

Next: Examine my reality as objectively as possible

I can look at my reality with limited objectivity. I’m a poet. People have paid me for my poetry, and the last time I sent a book off I got some excellent feedback. So I have good writing skills, and particularly I know how to impart an emotional context into a scene in a vivid, descriptive way, thanks to all the practice I’ve had with haiku.

Now for the downside of my reality. What do the best fantasy novels have?

  • A great plot
  • Detailed, vivd descriptions
  • Believable characters
  • An unexpected ending.

I’ve got the characters and the vivid descriptions. I’m just missing the plot and the ending – all I have are the first two short stories. So I’m going to do what all the best writers do – steal someone else’s plot!

This won’t be a problem, since the plot won’t be recognisable once I’ve adapted it to my characters and world, and also because experience tells me the characters rarely like to stick to the details of a plot, given half a chance to escape. It will, however, get me writing, which one Way Forward.

True objectivity is of course impossible

There are plenty of books out there which teach us that we’re blind to our own reality. Probably I think I’m a better writer than I actually am. The subjects I’m writing about might not be enthusiastically embraced by a traditional fantasy fiction audience. Indeed, the stuff in my head may be completely incomprehensible to other people.

Systems Thinking tells us to get balancing feedback

Another book tells me that my mental model is distorted. I like to be told I’m good at what I do. This is called reinforcing feedback. This will make me feel better, and help me to justify all the strange and inexplicable things which keep me from being successful. It will also stop me from actually being successful!

I can get balancing feedback in an Agile way – deliver iteratively to someone, preferably more than one, and see what they think. Amongst my resources are a number of friends who enjoy fantasy fiction. I’ll try and corner one or two of them at the party I’m going to this weekend. It would be useful for me to have the first two chapters printed out so I can take advantage of any good will coming my way. There’s my second Way Forward.

This approach won’t automatically make me successful…

…but hopefully it will help me fail faster, if I’m going to. Will let you know how it works out!

Posted in life, writing | 4 Comments

If…

Posted on September 11, 2008 by Liz

Save cancelled

If you can scan your threads when all around you
Are searching for the last response they knew
If you can kill the spammers with a button
While others must select a different view
If you can wait and not be tired of waiting
For others to get round to their replies
If email’s not the greatest thing you’re hating
And others’ weary rants are a surprise

If you don’t need to dream of working faster
And swift communication is your game
If you believe that emailing your master
And mastering your email are the same
If you can find the words that you have spoken
Within the folders chosen by your rules
If you can fix the email list that’s broken
Without the need to curse your dodgy tools

If you can start again from the beginning
And find out that your draft is not yet lost
If you must fight your inbox and you’re winning
Without your leisure time bearing the cost
If you find others accidentally bin you
Or cc you in mails they forward on
If you can laugh and even find it in you
To help discover where they might have gone

If typos with control keys never hurt you
And buttons don’t exist you fear to touch
If sanity and reason don’t desert you
When all the mailing lists become too much
If you find you can spend a single minute
And get some useful work done while you’re free
Yours is the Net and everything that’s in it –
And I guess you use a different client to me!

(With apologies to Rudyard Kipling)
Posted in humour | 3 Comments

Splitting up stories

Posted on September 11, 2008 by Liz

The high-level vision is made up of Stories of Unusual Size

We have a good idea of where it is we want to go. We have some high-level stories which are quite large. We’re about to play some of them in our iteration, and we want to know what the real scope of the stories is. We’re also pretty sure that some of these SOUSes are too big to get done in the space of a week or two.

To get feedback more quickly, we split the stories up

Occasionally it’s possible to release part of the original, high-level story. More often, we can split the story up so that we can get feedback about that bit of the story.

Whatever we do with the story, in order to get feedback, it has to show something that the business can understand and on which they can give us feedback. If you can’t get feedback, nobody cares. If nobody cares, it’s not a story.

(If you’re having problems getting feedback from your business, try delivering something.)

We can’t split the story up into horizontal layers

The business don’t care if

  • We created a CustomerData table with the right columns
  • We can migrate all the old data into the new database
  • We are using Spring as our framework
  • We are using magical pixies to make our site look nice instead of CSS.

They care if

  • They can see interesting information on the website
  • They don’t have to use two different applications for the same job
  • They can get changes made quickly and easily
  • The site is fast enough and makes for a good user experience.

Here are three ways of splitting up stories

The only valid way to split stories is into slices which the business can understand. That means that there has to be some effect on the interface that the business use! Even if there’s another computer somewhere else that uses our site, and no user interface at all, we should be able to define the effect of our stories in terms of their effect on the interface.

QAs are used to this. They have a great acronym, “SMART”, to remind them that stories should have acceptance criteria, which should be:

  • Specific – no generalizations (“It must be quick enough” vs. “It must load 90% of the time within 1 second”)
  • Measurable – nothing that can’t be given a quantative measurement (“Users are happy” vs. “Users who express their level of happiness should give us at least 7/10”)
  • Achievable – nothing that can’t be done (“I want my site emblazoned on the side of the moon”)
  • Relevant – keep it related to the story at hand (“I want the three latest blog posts and a pony”)
  • and Timeboxed– work out when it needs to happen (“I want to be able to duplicate the works of Shakespeare using the random word generator”)

Three ways that I’ve found to split up stories are:

  • By splitting up the output of the interface
  • By splitting up the input of the interface
  • By splitting up the behaviours, or business rules, that connect the input and the output.

We can split stories using the outputs

Think of a webpage. If you’re reading this on WordPress, it’s a great example. We’ve got several components on the screen:

  • The blogroll
  • The archive
  • The comments
  • The admin area
  • The footer
  • The date of each post
  • etc.

Let’s say our business have asked for a blog roll. The usability experts have come up with a design that shows the date of each post, who posted it, tags, categories and comments.

We can start capturing blog posts immediately. Not all blog posts have comments. We need to capture the date to show them in order, but we don’t need to worry about how to display the date. Not all posts have tags or categories, either! So our stories might be titled:

  • Blog posts
  • Display date on blog posts
  • Tag blog posts
  • Categorize blog posts
  • Comment on blog posts
  • Stop robots spamming blog posts
  • etc.

An output might be a page with components on it, a particular flow through an application, or a report with content and formatting.

We can split stories using the inputs

We can split the story up into the different types of input, and the way in which they effect the output. Search filters are a really great example of this. Take a look at Google’s advanced search.

I doubt that Google started with all those different search options. Maybe they started by letting you search for all words. Then by letting you search for exact words. Then by letting you search for all words, or exact words, but not the unwanted words.

The form of the output is exactly the same – a list of search results – but the actual content changes depending on what the input was. We don’t need to support all those inputs to begin with! So, our stories for a Google Advanced Search page might be titled:

  • All these words
  • These exact words
  • Not these words
  • Paginate results
  • Search by language
  • Search within a domain
  • etc.

We might also want to split stories using the state of the application – the context in which it’s running. This is similar to changing the input. For instance, the iGoogle home page contains some widgets, and has a search bar. We can change how the widgets and search bar look depending on:

  • the skin choice
  • the order of the widgets
  • the different tabs
  • etc.

Each of these might also be a different story. The context is another input, and the output changes depending on it.

We can split stories using the business rules

Let’s say we’re building a payroll system.

The simplest payroll we can create is for a full-time employee, who has an annual salary, and who gets paid monthly. Sometimes these employees might just have arrived, so they won’t be paid a full month’s salary. Sometimes they might be in the process of leaving. Perhaps an employee works part-time, so we actually have to look at how many hours they worked that week. Maybe they do overtime. Some of them will get performance bonuses. Some will be on commission. They might have pension contributions, or expenses.

All the information is captured in a database already, so our context isn’t changing. Our input to the system is just an id! Our output is a cheque with an amount. But our amount changes as we introduce each story – which means it won’t work for everyone to start with.

We can support the simplest cases first, and add business rules incrementally to deal with the difficult cases. So, our stories might be titled:

  • Full-time employee
  • Part-time employee
  • Employee who just joined
  • Employee who’s leaving
  • Overtime
  • Pension contributions
  • Expenses
  • Commission
  • Bonuses
  • etc.

As we start adding things to this list, we can start dealing with more and more employees. We can let the legacy system deal with the people who aren’t on the list. It might be a manual legacy system! But even if that’s the case, we can start cutting down the work of the admin staff very quickly.

(I can’t remember who wrote the original tale that inspired this; it ended with the first payroll cheque being framed and put up on the wall. If anyone can give the appropriate credit I’ll include it here!)

You can use scenarios to help split up stories

When we think of examples of the behaviour of our application, we think of stepping through them in the same way that QAs do when testing.

We can say:

  • Given a context
  • When some events happen
  • Then some outputs should occur

If we have different contexts that change the outputs when the same events happen, then we can split the stories according to those contexts. So using an example of an ATM which does different things depending on the balance of my account and whether or not I have an overdraft limit, I can start splitting the “Withdraw cash” story into “enough money” and “overdraft” stories.

If different events cause different things to happen, there are probably different components on our interface that can be delivered independently. So putting in a value for the amount of money, and pressing the buttons that deliver predefined amounts of cash, might be two different stories.

If we find that we’re getting the wrong outcomes for particular contexts and events, we’ve probably got some business rules that we need to include (and we’ll have to have a strategy for dealing with the exceptions in the meantime). For instance, my card used to work very well in the ATMs abroad! But now, I have to phone my bank and let them know where I’m going ahead of time – they’ve put in a business rule to help cope with international fraud.

So our single story – “I can use an ATM to withdraw cash” – becomes:

  • Withdraw cash if enough cash
  • Withdraw cash if enough overdraft
  • Quick buttons
  • Limit use abroad
  • …and we can probably find some more if we talk to people who know the domain.

These stories are not necessarily releasable

Sometimes, the business will have a minimum feature set that they want to release. This might be because of training, because they have a certain number of commoditized features that they need to enter a market, or because rolling out the software or making changes to it in a live environment is expensive.

However, the stories should each have something that the business can start playing with, that QAs can test, that we can get feedback on and that we can showcase and feel proud of.

But they might be!

We sometimes discover that a story we’ve broken down can be released with only part of the original functionality in place. This is great, if you’ve got an immovable deadline!

“We’ve just bought out another company. That’s 1,000 new employees, and they all need paying at the end of the month…”

OK. Let’s work on that first release.

Posted in stories | Tagged | 8 Comments

Feature Injection and handling technical stories

Posted on September 10, 2008 by Liz

Technical stories don’t make sense

As I learn more about stories and how they get written, I occasionally come across odd things that don’t make sense.

One of these is the technical story. Here’s an example:

As a developer,
I want an automated build
So that I can be sure my code works.

Of course, we’re resistant to letting developers have their own stories. So sometimes, instead, the technical story becomes:

As a business user,
I want developers to have an automated build
So that they can be sure their code works.

This doesn’t make sense to me either. Surely “working code” is part of another story, for any part of that story? Of course, the QAs are busy checking that code works! So why do we even need a build?

If there’s no benefit to the business, the chances are that a technical story isn’t really appropriate.

As a business user
I want the developers to refactor the UglyClass
So that... um...

Maybe not. In this situation, refactoring of UglyClass should happen when it enables some other piece of functionality to be delivered.

Feature injection helps us talk about the business benefit

There are some technical stories, though, which really do deliver something the business care about. You can find this out by asking, “Who cares if I don’t do this? Who cares if I don’t have an automated build? If I don’t write unit tests? If I don’t write acceptance tests?”

This is where the feature injection comes in. I’m flexing Chris Matts’s template a bit to do this; here’s how mine reads:

In order to <deliver some business benefit>
<these people>
will need <these features>.

Now we can start working out why it is that we write the automated build.

In order to minimize support costs due to poor code quality
The development team will need
To write scenarios and automate them.

In order to stop wasting money coding things that don't work in production
The development team will need
Automatic integration with a production-like environment.

In order to minimize the risk of our production environment falling over
The development team will need
Automated performance testing.

Users aren’t stakeholders

Interestingly, the people who care most about these things aren’t always the development team! The maintenance team care about support costs. The business stakeholders care about wasting money on code that doesn’t work. They also care about the production environment falling over.

We sometimes see this in normal stories too: that the user isn’t always the person who cares about the story.

As a user
I want to fill in a captcha box
so that... what? No! What a waste of my time!

Using “In order to…” we can turn this around:

In order to stop bots from spamming the site
Users will need
to fill in a captcha box.

Now it might be obvious that the beneficiary of this story is the person who has to moderate the site, or the commercial team whose adverts would become worthless in a morass of spam. But just in case it isn’t, we can capture both the stakeholder and the user:

In order to <deliver some business benefit>
As a <role> I want <some other role>
to <do something, or use or be restricted by some feature>.

In order to stop bots from spamming the site
As a member of the commercial team, I want users
to fill in a captcha box.

Feature injection helps us remove the implementation detail

So, going back to our technical stories:

In order to stop wasting money on code that doesn't work in production
As the budget owner, I want the development team
to integrate their code regularly with a production-like environment.

You might notice that when we word technical stories this way, the implementation detail – how the development team integrate their code – tends to fall away. All that’s important is that we do it; if automating that is the easiest way then we’ll do it that way.

(Interestingly, JBehave2 was developed with no automated builds. Running them manually was enough.)

Now we can talk about the business benefit of our stories

We can also see that there are three different things we can do with our new build, for three different stakeholders. Because we’re splitting up our technical stories appropriately, we can ask each of the stakeholders to help prioritise the stories, and to give us clear acceptance criteria.

In order to minimize the risk of our production environment falling over
As the person in charge of advertising revenue, I want the development team
to be able to verify the performance figures.

Now you know who you need in the story workshop, too.

“So, I want 90% of pages to load within 1 second, and it should be able to cope with the Christmas sales.”

Of course, the language still isn’t quite perfect, so you can now have the conversations about the real business benefit (maximising advertising revenue and user experience, minimizing the risk of the brand being stigmatized by an embarrassing failure) and splitting up the stories (situation normal vs. peak time).

“But, you know what? We’re not going to be able to do this until after we’ve finished the first internal release and have some idea of what the real content’s going to look like and which agencies we’re going to use for the adverts. Can we delay it till then?”

No problem. Let’s work on that first release.

Posted in stories | Tagged , | 22 Comments

Tyburn 1.0 released

Posted on September 4, 2008 by Liz

It seems to be the season for releasing code!

Tyburn is a fast, minimal, extensible Java Swing harness that was originally part of JBehave 1.0. You can download it here and use it like this:


WindowControl control = new WindowControl("my.named.frame");
control.clickButton("a.button");
control.enterText("a.textfield", "Text1");

Posted in open source | Tagged , | Leave a comment

You may have noticed…

Posted on September 4, 2008 by Liz

… that my blog has moved.

This is so that I can keep things like code samples, etc., connected to my blog, and so that it isn’t blocked by corporate filters that don’t like LiveJournal.

I will still be crossposting for anyone who prefers LJ, or has the old blog on their LJ friends list.

Posted in life | Leave a comment

JBehave 2.0 is released!

Posted on September 3, 2008 by Liz

We discovered some time ago that JBehave 1.0 wasn’t being used. When we found out that it took over an hour to write the scenarios for the Game of Life, we realised why.

Our goal with JBehave 2 was to make the process of collaboration, drawing up scenarios and getting started easy and simple. Feedback from enterprise users suggests that we may have succeeded!

Find out more about the new features, the ones we’ve discarded, and how to use it on the JBehave site.

Posted in jbehave | Tagged , | Leave a comment

JBehave 2 is up on its usual svn

Posted on May 29, 2008 by Liz

svn co http://svn.codehaus.org/jbehave/trunk

No ‘official releases’ yet, but if you want to play, go ahead. Examples of examples are checked into trunk.

Features include:

  • plain text scenarios
  • steps defined using annotations that match the scenarios
  • built on JUnit
  • Ensure (which is just an extension of Assert, so you don’t have to use it)
  • auto-conversion of string arguments to numbers
  • pending steps generated for anything which hasn’t been defined yet (these don’t break the build)
  • errors from scenarios are rethrown after the full scenario has been described

Our goal with JBehave 2 was to make a framework that was lightweight, easy to use and didn’t take as long to set up as JBehave 1. To that end, we’ve been driving this entirely from example code – no guessing, unless it’s obvious – and we’ve ended up with something that works quite a lot like RSpec’s story runner, but for Java.

  • To use it, simply name your scenario file with underscores, eg: i_can_toggle_a_cell and define steps in it thus: 
    Given a 5 by 5 game
When I toggle the cell at (2, 3)
Then the grid should look like
.....
.....
.....
..X..
.....
When I toggle the cell at (2, 4)
Then the grid should look like
.....
.....
.....
..X..
..X..
When I toggle the cell at (2, 3)
Then the grid should look like
.....
.....
.....
.....
..X..
  • Then extend the Scenario class with a similarly named Java class:
    ICanToggleACell.java
  • Extend the Steps class – this is where your steps will be defined, and you can have as many as you want
  • Inject these into the Scenario: 
    public class ICanToggleACell extends Scenario {

	public ICanToggleACell() {
		super(new GridSteps()); // varargs, can have lots of steps
	}
}
  • Annotate methods in your step class to match the ones in your plain text scenario. 
    public class GridSteps extends Steps {

	private Game game;
	private StringRenderer renderer;

	@Given("a $width by $height game")
	public void theGameIsRunning(int width, int height) {
		game = new Game(width, height);
		renderer = new StringRenderer();
		game.setObserver(renderer);
	}

	@When("I toggle the cell at ($ column, $row)")
	public void iToggleTheCellAt(int column, int row) {
		game.toggleCellAt(column, row);
	}

	@Then("the grid should look like $grid")
	public void theGridShouldLookLike(String grid) {
		ensureThat(renderer.asString(), equalTo(grid));
	}

}
  • Run your new scenario!

Future features we’re thinking of:

  • having more than one scenario in a file
  • tagging scenarios
  • better tolerance of whitespace
  • an option for pending steps to break the build
  • decent documentation to show you how you can customise filename parsing, argument parsing, etc.
  • anything you persuade us you need.

Give it a go and tell us what you think! Release 2.0 can’t be far away…

Posted in jbehave | Tagged , | Leave a comment

RIP As a… I want… So that…

Posted on May 14, 2008 by Liz

If you’re more interested in the results than the conversation, skip to the summary.

Recently, I’ve realised that a lot of BDD has been very dev-focused. There’s a reason for that. Dan’s a dev, I’m a dev and most of the people who helped to evolve BDD are devs.

BDD’s about the interaction between the business and the technical people in software. I want to know how it’s working from the other side. So, I’ve been learning more about the customers, and particularly, more about BAs and their role. I had the recent fortune to run into Angela Martin at Agile India, where she taught me the art of grouping stories into coherent releases, while still keeping the stories granular enough that progress can be measured and delivery made regular and predictable.

Last night at XtC I met up with Chris Matts (of Real Options fame) who told me we’re doing it all wrong. “It’s not an art, it’s a process,” he said. “You’re focused on the stories; that’s why you think it’s an art form. The focus should be the value you’re releasing.”

“Right”, I say. “So, when we originally planned the stories that would deliver the value, we knew what would contribute to that value. But we’ve lost sight of that. Changes have been made. As devs, all we have are those narratives – the ‘As a <role>, I want <a feature>, so that <some benefit is achieved>’. So we need to work out which of the benefits add up to the value we’re aiming for. That helps us work out which stories we should try to complete for a release. The QAs are helping us work out what’s ready; the BAs are helping us work out what’s important.”

“That’s the problem,” says Chris. “You’re putting the role first. It’s the value that’s most important. Try this: In order to <deliver some value>, as a <role>, I want <some feature>. Instead of working out why people want a feature, and whether it contributes to the value, now we’re working out who needs a feature, then assigning the story. So our stories are much more focused. If all the stories that contribute to a value are ready, we release.”

I guess if we get to the point where we can release with only some of the stories ready, we didn’t break down our values into granular enough elements. And when we want to work out what goes in a release, it’s easy. The word ‘release’ is more meaningful. There’s some untapped money out there – some market share, some cost saving, some battle against a competitor. All the features we produce go towards releasing that value for our customers to use – and it’s the value we’re releasing, not the features.

Thanks, Chris, for that.

I need to also thank Dave for giving me a better understanding of what a value is.

In summary: my preferred narrative now reads:

In order to <achieve some value>
As a <role>
I want <some feature>.

Because, in order for my work to have any meaning, as a dev, I want to know why you want it.

Edit: Chris said he posted this to the Kanban group on Yahoo, but they aren’t responsible for it. Sorry, Chris, didn’t mean to misaappropriate! See you on there soon.

Posted in stories | Tagged , | 7 Comments

Running your own Retrospective

Posted on April 24, 2008 by Liz

I’m running a training course for TDD and OO design at one of our clients.

Normally when I teach this, it’s to Thoughtworkers or client staff working with Thoughtworkers. This time, I’m teaching fairly experienced clients who have some idea of OO already. I’ve been trying to teach more advanced techniques – communication with customers and how it drives design; starting with the UI and a good concept of ‘done’, etc.

I could see that occasionally, some of the participants looked uncomfortable. Whenever I asked them for feedback, they told me that they were having fun and learning a lot! Yet I could see that they were still uncomfortable – they just couldn’t tell me why.

So, at the end of the second day, we ran a small retrospective. Normally, I would ask a facilitator to run the retrospective for me, but we didn’t have one. Here are some things I did that seemed to work, and help the retrospective to run smoothly.

Make them feel safe with you

It’s awkward running a retrospective when you’re the one who’s likely responsible for the things that aren’t working quite as well as they could. It’s especially true if you’re a stranger to the group, or the group isn’t used to giving and receiving feedback, or both. I wanted to introduce to the participants the idea that they should feel safe giving me feedback; that I would react to that feedback positively and wouldn’t criticise them for giving it. I also wanted to give them an idea of how they might run retrospectives for themselves.

So this is what I told my participants:

I’ve run this training course for a lot of people. I come with a very generic course, and tailor it as best I can to the people who turn up. Every group is different. Some people prefer different techniques to others. You no doubt have your own thoughts about what might work for you.

I’d like to use a retrospective format to get an idea of how best I can tailor this course for you.

In a retrospective, we start with the Prime Directive: that no matter what we find out, we know that everyone is a good person and has done the best job they can in the situation. I believe you’re all good people. I hope I’m a good person. I think that the job I’m doing here is a good one, but I’d like to make it better. There are ways in which you could phrase feedback positively. That would be nice! But even if you can’t find a way to express things positively – I still want the feedback. I have a lot of confidence in myself and my abilities. I can take it!

Then, I ran the safety check. The participants felt safe enough (mostly 4s on a 1-5 scale) so I went ahead.

Make them feel safe with each other

I asked all the participants to draw a picture to represent how they felt about the course so far.

I could see their eyes light up as everyone put the pictures on the board. Eight faces with question marks, puzzled expressions and light-bulbs. Everyone felt slightly puzzled, slightly confused yet enlightened! I think this helped them realise that their confusion wasn’t unique.

Make them feel safe with themselves

People are usually happier giving feedback if they can find a way to phrase it positively. Fortunately, this is easy! For every “less of” there’s usually a “more of”; for every “stop doing” there’s often a “start doing”; for every “fear” there’s a “hope”.

Often in retrospectives we insist that people put one thing in each category. I didn’t want to do that this time, because I felt that people would be uncomfortable with the idea of giving me lots of “less of”. Instead, I left them free to think of more positive ways of expressing what they wanted.

I encouraged them to think of ways of changing things by adding three categories:

  • More of / hope
  • Less of / fear
  • Puzzles

I explained what the categories were for, and asked them to come up with about five things that they wanted to put in these categories. To show them what I meant, I drew a pint of beer and put it in the “hope” category, then told them that I hoped that we could all go out one evening for something less formal.

Then I let the participants loose on the board!

Proof that it works

The participants wrote things like “Hope for more time to come up with a solution!”,”Hope not to be so confused by other people’s designs”, “Hope for more tea breaks”, “Hope for better understanding”, “Hope we get to learn more about Agile”, etc. There were very few fears – “Afraid I’ll fall behind” – and a couple of puzzles that were either easy to answer or I promised would be answered as part of the course.

I asked them to talk in more detail and give examples of times when they’d been confused, etc. We came up with a lot of action items as a result of the things they put on the board:

  • Break down exercises into smaller chunks
  • Baseline code bases (move to one common solution for the exercise) frequently, to allow people to swap pairs and stop them being overwhelmed by the differences when they do
  • Allow more time for analysis of the solution and for questions
  • Participants to tell me when they want a tea break
  • Pub next Thursday

I also found some things which they wanted me to teach which weren’t really part of the course, so I made a mental note to slip the easy things in when the time came, or provide them with links to resources where they could learn themselves.

I checked that they thought the action items would meet their hopes. That feedback was very valuable, and far more useful than “Oh, we’re having fun and learning a lot!”

The safety check is the most important thing

It was very important to me that the feedback I got was honest and accurate. For that reason, I was extremely careful with the safety check. I made sure that it was visibly anonymous – I got one of the participants to gather up the pieces of paper, and made sure that they used identical paper and pens so that no one could be identified.

If they hadn’t felt safe, it would have given me feedback about my approachability, and how well I had expressed my desire to get feedback. It might also have indicated that people didn’t feel safe with each other. I guess if that had happened I would have run more icebreakers, more fun exercises that let people relax, and I’d have looked carefully to see if there was any personal feedback that I needed to take on board or give to individual participants. I’d also have tried hard to find an independent facilitator to run the retrospective – but I wouldn’t run it with a low safety check. I also let the participants know this, and reassured them that I’d do some different things to try and make the environment better if the safety check was low.

Thanks Pat!

Pat Kua loves retrospectives, and has taught me their importance and a number of techniques for running them. They’re my second-favourite practice. My favourite is Small Releases – actually delivering the things you promised to deliver – and I use retrospectives to work out why I can’t deliver, or how we can deliver better, or sooner. This can apply just as well to training courses as to code.

I was quite surprised by how well the retrospective worked. Talking about it with my co-trainer Arvind afterwards helped me realise how the things I had done instinctively added to the environment of safety and helped the participants give me the feedback I needed. I hope it’s helpful for you too.

Posted in Uncategorized | Leave a comment