Elizabeth Keogh

While I’m coding, I usually have a bunch of very helpful pixies hanging around my desk. (They’re Dan’s pixies really, since he thought of them first; I’m just borrowing them.)

The pixies are bored, and just waiting for a job to do. So, when I’m coding a class, they look out for opportunities to help out that class. When I’m coding the Game of Life, for instance, I write a Gui class that lets me toggle the cells on the grid. Then I have to work out what happens when I toggle the cells.

I could do it in the same class - in the gui - but fortunately the pixies step in to prevent me making these poor design decisions. “Oh, I’ll do that for you!” one of the pixies calls out. (They usually start with this phrase, and they’re all called Thistle.)

“Thanks, Thistle! Do you know what you’re doing?”

“Um, not really. What’s toggling a cell? Why’s that valuable? What is it you want me to do for you again?”

“I need you to handle the cell living and dying when I toggle it.”

“Oh, okay!” Thistle says. “I don’t like the ‘and’ word so much, though. It makes me feel like I’m doing two things at once. What do you call that? The living and dying thing?”

“Hm.” I think about it while the pixie taps his foot impatiently. “I’d call it a lifespan, maybe. Can you handle the cell lifespan for me? Just let me toggle the cells. I also need you to tell any observers that there have been some changes to the cells, and give them a way of finding out where those changes are. I think they’ve already got an idea of what they want there.”

“Really? Both things?”

“Well, there’s no point doing one if you don’t do the other. It’s all part of the same role.”

“If that’s what’s valuable to you then I’ll do it,” he says. “Just pretend I’m there for the moment; I’ll be back when you need me.”

“Fine,” I say. So I use a mock pixie in place of the real one. I create an interface which does what the pixie’s going to do: IHandleCellLifespans.

(See, it’s an interface that starts with “I”, and it represents a role that the pixie is playing for me. This is a role-based, anthropomorphized interface.)

So, now we have code which compiles. Of course, the real code in the Gui is null, or maybe a null object pattern - I might create something like IHandleCellLifespans.KILLING_THEM_ALL if I’m feeling particularly mean. But that’s all right, because Thistle the pixie will step in when it’s time.

So, I run the code. I’ve usually written an automated scenario. It doesn’t matter whether I run the scenario or step through the game manually; both result in the same thing happening, or not happening - no matter where I click the mouse, no cells appear. Pixies are notoriously unreliable.

Since I can’t rely on the pixies, I inject a new class to handle the dependency instead. I decide to call it the Engine, for the moment, and I write an example of how to use it and what it should do for me.

The next step is the Next button. I think about how this would work in the Engine, and start writing some code to show how the Engine needs to behave. I’ll need to calculate the number of neighbours, and apply the rules accordingly.

One of the pixies pipes up, “Oh, I’ll do the neighbours!” and another one says, “Oh, I’ll handle the rules!”

“Fantastic!” I’m so trusting; I always forget what these pixies are really like when it comes to getting the work done.

“If I’m going to count the neighbours,” Thistle says, “I’ll need some information about where I’m counting from, and what’s around me.”

“Ah, I can get the information from the cell itself,” I say.

“No, don’t do that. It’s fine where it is; I’ll just sit inside the cell and do it from there. Can you give me something that lets me know where the other cells around me are? Then I can do the work for you.”

“Sure,” I say, “the Engine knows where the life is. I’ll just give you access to the Engine and let it play that role for you.”

“Can’t I do it instead? I’m bored,” one of the other pixies asks. “Just give me the information from the engine, and let him talk to me instead.”

“Um, Okay.”

Of course, when I try to run it then I find out that all the pixies have mysteriously vanished, and I end up assigning the role to the Engine anyway, or one of its anonymous inner classes. Having it defined as a different role means that it’s easy to move this responsibility around. Maybe I’ll create a World to look after the cells, and let that do the job instead; the pixies certainly aren’t very helpful.

“What do you mean, we’re not very helpful?” Thistle says. “Look at your code. You haven’t written anything that isn’t needed by something else, so there’s less code to maintain. Because we jump in all the time to try and do jobs for you, every time you can assign a new responsibility to something else, you do - that’s the single responsibility principle in action; none of your classes are doing too much. And you can replace us with something else that does the job at any time - that’s the Liskov Substitution principle. The roles we perform are clearly named. It’s been easy to describe the behaviour of each class using mocks to stand in when we’re not there, and the examples are very readable. You can also use them to work out whether your code still works or not, by running them as tests.”

“Okay. I can’t see myself relying on you guys for bigger, enterprise stuff, though.”

“What do you mean?” Thistle looks offended. Oops.

“Well, let’s say that I’ve got a shop, and I need the tills to talk to stock control.”

“Controlling stock? Oh, I’ll do that!” one of the pixies announces excitedly.

“What, all on your own?”

“Well, I’ll probably delegate it to a team, but that’s my responsibility - you don’t need to worry about it. I’ll be there when you need me. Just pretend I’m there for now. How would you like to find me? What kind of stuff are you going to send to me, and what do I need to do with it? What would you like back?”

So I start with something simple - a URL that I’ll use to find Thistle the pixie, some domain objects that I want to send him, and some objects that I’d like back in return. We talk about how to get the information across, whether some of the tills might provide different stock information, how to talk to the claims department about the quality of the goods we’re selling, and whether I’ll be okay if the claims he gives me have more information than I need.

“Hold on,” I say. “You’ve got me playing this game now. I’m not a Claims Department. I’m not going to do the job myself. I’ve got a home to go to!”

“Meh, never mind,” Thistle replies. “I’ll be sitting with this team over here, coding the stock control. We’ll just pretend you’re doing the job; we’ll mock you out for now.”

“How will I know that I’m doing the job correctly?”

“We’ll have to talk to each other occasionally. Is that going to be hard? We’ll write some scenarios over in our team that describe how we’re going to use you.”

“What if I make a mistake?”

“Do you know what mistakes you’re going to make already?”

“No,” I confess. “I’m sure there will be some, though.”

“When you make a mistake, we’ll deal with it at that point. Sound good?”

I think about it. I reckon I could write some code that pretends to be doing the job of the Claims Department and responds correctly to the way they’ve described how they’re going to use me - just for those examples - then I could go home and Thistle would never know. I knock up a quick stub and slip it into the stock control team’s scenarios, then I disappear too, just like the pixies. I figure I’ll start coding a real Claims Department that does a more robust job tomorrow.

When I get back the next morning, all the pixies performing the role of Stock Control have been replaced with code too. The Stock Control team claim that they’ve never even seen them.

I corner Thistle again. “You’re really not very helpful, are you?”

Thistle looks sulky. “Of course we are! Look at your architecture. You’ve got simple messages going back and forth. Your code is very tolerant of extra information, as is the code on this side. You’ve got lovely RESTful URLs, because you were thinking about how you’d like to find us, instead of us providing you with some weird mechanism that doesn’t match exactly what you wanted. We’ve got clean interfaces and APIs. There are no extra columns in your database, because you only replaced exactly what we said we’d do in the first place. You’ve got scenarios to describe how we work together, and at a unit level examples to describe how you’re delegating responsibility to the other pixies. It’s a lovely, maintainable system with a fairly flat cost of change. Isn’t that what you wanted?”

I nod thoughtfully. “I think it would have been easier for me to just write the code instead of going through you all the time.”

“Ah,” says Thistle, “but then you’d have code that was easy to write, instead of code that’s easy to use.”

I think about how they made me fill in the role of the Claims Department. “You never did any of the work, though! I could have done that job myself; put myself in each of those roles and then replaced myself with real code. That would have let me create consumer-driven interfaces just as easily as using you.”

Thistle shrugs. “If that’s what works for you, sure.”

“Won’t people think I’m a bit mad? If I start talking about how I’m personally going to use a particular class, or how I’m offering to do a job for another?”

Thistle looks at me with raised eyebrows, then gestures at all the other pixies clustered around my desk.

“I think it’s a little late to be worrying about that now,” he says.

Originally published at lizkeogh.com. Please leave any comments there.

Pascal Van Cauwenberghe has written a great post on estimating business value, tying it into a feature-injection style template. I particularly like the idea of calculating business velocity, and showing value earned over cost on a visible chart.

Even though we know that cost accounting isn’t useful without looking at ROI, many companies still have this focus (how many people have had problems getting hold of sharpies because they’re "too expensive"</a>? Coloured post-its? Free coffee?)

Perhaps by making the return on investment over time apparent to everyone, we can motivate the team, show the value we’re earning and gain the trust of the business at the same time.

As an aside, I remember one client where the deadline was very tight, but nobody wanted to work overtime or weekends. Our PM asked us if there was anything we’d like to have which would help us work more effectively. We asked for - and got - fresh fruit every day. The difference in our work - both the amount and quality - was noticeable! (We already felt very well respected, so I discount the placebo effect here).

It’s amazing how much difference a few pounds of expense can make.

Originally published at lizkeogh.com. Please leave any comments there.

On an aside, some people have asked me why I’ve chosen to set up my services site as a hard-coded website with server-side includes, instead of using another Wordpress blog or something similar. I did it because:

• It was the quickest way I could think of to get a website out with a reasonable amount of content
• I wanted to be able to get the style right (or at least usable) before I had to wrap it around Wordpress
• I had no idea what I was going to put in the website when I started.

Having said that, it’s now annoying me. There’s enough up there that the next stage is to, um, move it to a customised Wordpress site (it should look exactly the same, but be easier for me to administer).

I did learn a lot about CSS, Mercurial over SSH from Windows, and Apache SSI configuration while I was playing with this. It will be much easier for me to set up the Wordpress site, now I know what I don’t want on it and what I need for the styling to work. And I didn’t need a Wordpress site when I started. YAGNI wins again.

Originally published at lizkeogh.com. Please leave any comments there.

I’ve put up a page on lunivore.com which describes how I use the Dreyfus Model in coaching. This model was the one we adapted to mark the XP values in the Game of Life workshop at Screwfix, and I’ve also found it powerful when used in one-on-one coaching in combination with GROW and well-formed outcomes.

It’s taken me a fair bit of practice to get good at building Dreyfus models, using them appropriately and adapting them for different organisations; however, I’ve not encountered much downside to using them. If anything, the act of creating them has taught me a great deal (Dan North reckons there’s a Dreyfus Model for Dreyfus Modelling.)

Originally published at lizkeogh.com. Please leave any comments there.

My first ever article, “Pulling Power: a new Software Lifespan” is up on InfoQ. BDD, Feature Injection, Lean and Kanban playing nice together!

Big thanks to Dan North, Chris Matts, David Anderson, Amr Elssamadisy and the amalgam of developers who make up “Jerry”; also to the Thoughtworkers who reviewed my article and gave me advice, and the Kanbanjins like Eric Willeke who patiently talked me through Lean and Kanban. Several times. Anything I still haven’t understood is my error, not theirs.

I wish I could have put in everything I’ve learnt about Kanban, which is far larger than this article allows. It strikes me as a lovely, simple, high-discipline, least-wasteful way to deliver software, and it matches my feeling that you should fit your process to reality, not reality to your process.

My experiments with Kanban boards so far have been highly successful. Now I want to know about the problems, too. Have you tried Kanban? What happened? Did you try to introduce it? Did that work out? If not, why not? Did you think about introducing it, but decide not to? Tell me your stories!

Originally published at lizkeogh.com. Please leave any comments there.

Esther Derby writes great advice on giving feedback. I’m intrigued by her closing comment:

I think it depends on how a feedback sandwich is used. I tend to use it to make a safe space in which I can share feedback with people without them feeling like the world’s just been cut out from underneath them. I find it helps me phrase feedback in a very positive, constructive manner.

This is not, to me, the most effective feedback sandwich, despite adhering to any rules I might previously have given:

So, here’s how I’m using the feedback sandwich now (all other rules of giving effective feedback also apply).

I value this…

Whenever someone gives me some advice or criticism, it makes me want to change things so that I’m more effective, or so that the problem is fixed.

For instance, a graphic designer gave me some feedback on my new business cards. “You need to revisit the whole card,” he told me. “Change the shape, add some texture. Put in a tag line, something catchy that people can remember you by.”

Well, I’m not a graphical artist! Nor am I pretending to be, so the feedback didn’t really get me down. I knew I couldn’t get new business cards ready in time for the conference, nor can I really afford the services of a graphical artist right now. I thought to myself, “I could just give out my email address; that’s worked for me before. I don’t really need to take my business cards to the conference.”

Then it occurred to me much later that perhaps that wasn’t the artist’s intention. So I asked him: “Would it be better for me not to take the cards at all?”

“Oh, no! That’s not what I meant. They’re fine, I mean, they’ll do the job if that’s what you want. I just wanted to give you some help to improve them.”

“Fantastic!” I smiled. “So, what do you like about them?”

“I like the colour scheme, and the symbol you’ve chosen - the big red moon - is very powerful.” And then he described the things he liked about the card.

Without anchoring the things that I value, I am in danger of losing them altogether. If I bring up someone’s annoying behaviour when they pair program with me, they might just stop pair programming. If I suggest a different way of solving a problem, they might stop thinking of themselves as problem-solvers. The human mind has this dangerous way of abstracting generalisations from particular situations, and confidence can be easily knocked! Even in the situation with the business cards, where I didn’t really feel depressed by the feedback, I was in danger of throwing away valuable work.

So, I can anchor the things I value; things that might change as a result of what I’m about to say.

And…

The next bit of the “feedback sandwich” is the trickiest. It’s always tempting to put the word “but” or “however” in here! The word “but” has the impact of negating the first part of the sentence. I’ve heard this example a lot:

Mum: Well, he’s ugly, but he’s rich.
Daughter: Yes, Mum. He’s rich, but he’s ugly.

See what I mean?

Even the act of thinking “but” tends to lead me to phrase it unconsciously. So I’ve been trying to replace it with the word “and”. Like “should” in BDD, this leads my brain to go a different way. Instead of thinking of how to phrase the negative advice in a way which is palatable, I find myself phrasing things very differently.

This has led me to new ways of providing feedback. I can even talk to managers now!

I don’t always need to criticise the behaviour that’s causing me problems in order to suggest changing it. Thinking about the last part of the feedback sandwich, and using that to work out what goes after the “and…”, helps me work out what to say.

…I want this.

There’s some place that I want to get to; some goal that I want to achieve. NLP’s well-formed outcomes can help here, or if you’re a software developer, think about the SMART technique for writing tests. How will you know that you’ve got to the place that you want to be in? What will you see? What will you hear? What will you be doing - or not doing - differently?

Even when there’s some particular unpalatable behaviour that really does need to stop, this can help.

Even when it’s really unpalatable behaviour.

Provide options

I like the feedback sandwich because it sits very well with GROW, in which we move to our Goal from our Reality, looking at Options and selecting a Way Forward. Reality is the current behaviour that we value (not the problem!) and the Goal is where we want to get to.

In the examples of feedback I’ve given above, I’ve provided multiple options, or left an opening for them. Even when there’s only one option that can realistically be taken - nobody’s going to say “no” when I ask for more time to type code without having a back-seat driver telling me what to do - I’ve phrased it in a way which makes the other option available. Using words like “maybe”, or asking questions like “What do you think? Can you help me?” can invite other options, things that we haven’t thought of.

There’s safety in these options. By providing them, and allowing the coachee to make the choice, we’re saying, “You have the power here. You get to make the choices.” All I’m doing is sharing a place that I want to get to with you, and leaving it up to you to decide how to get there. You can ask me for help if you want, and even give me feedback if there’s something that I can do that might make a difference.

I was reading this article which starts with an assertion, “old commented-out code is an abomination”. That makes me wince, because an abomination is something hateful, wicked or shamefully vile, and what I see is someone learning! That’s not vile at all; it’s a wonderful thing, and I heartily encourage it. Instead of insisting that the code is deleted, I might suggest trying it out, and seeing which one works best. I might even talk about the benefits of deleting the code. Creating it as an option, instead of “the only right way”, will allow Alphonse to feel safe trying out other things, too.

(Incidentally, the way that the feedback is given in the scenario with Alphonse isn’t very safe. Giving feedback in private is usually better than giving it in public.)

Big thanks to Chris Matts and Real Options for helping me see the similarities between GROW and the sandwich model, and fitting Options into it. I’ve found it’s worth paying to create Options, and I might sacrifice some related feedback I want to give, or my idea of “the right way to solve it”, in order to do so. This has been very effective, and I find it a very natural way of giving feedback now.

Why don’t you give it a try?

Originally published at lizkeogh.com. Please leave any comments there.

I got a bit experimental with my mind maps at the Agile Coaches’ Gathering. I think it was a combination of the amazing and inspirational people, the fantastic choice of venue and the glorious weather that got me feeling so creative. Some people have asked me to put them up on the wiki, so here they are.

Originally published at lizkeogh.com. Please leave any comments there.

This blog’s been up and down the last couple of days while we uploaded my new site, lunivore.com. It’s not finished yet - there are a couple of empty pages, the Game of Life implementation still has a couple of bugs, there’s still more material to go up and I’m not completely convinced that my CSS is the best. However, in the interests of Agility and getting it into production as soon as possible, it’s up there.

Lunivore Limited is the company through which I’m offering my services, and lunivore.com is the website which describes those services: software, coaching, training, writing.

Many thanks to Andy Palmer for his Apache expertise and struggling with cpanel’s weirdness! If either site goes down, it’s cpanel doing something strange that we haven’t pinned down yet; I’m home from the wonderful #acguk and will be on it.

Originally published at lizkeogh.com. Please leave any comments there.

What’s a Cargo Cult?

Once upon a time, during World War II, there was an island on which planes landed. The islanders loved the planes landing, because they brought goods that the islanders couldn’t normally get. The soldiers shared the goods with the islanders, and the islanders considered themselves wealthy, lucky, and blessed by the gods.

When the planes stopped landing, the islanders missed the cargo that the planes had brought, and decided they’d try to bring them back.

They did the same things that they’d seen the soldiers do to make the planes land. They created signal fires, waved at the sky, wore coconut-headphones on their ears and made replica planes from wood and straw. The cult which surrounded this sympathetic magic came to be known as a cargo cult.

What’s Cargo-Cult Agile?

As the Wikipedia author says, the islanders mistook a necessary condition for the planes arriving as being a sufficient condition for the planes arriving.

Teams and individuals sometimes make this same mistake with Agile. They believe that by following the practices of XP, Scrum or some other methodology, they’ll be successful in creating a culture which allows them to succeed.

Unfortunately, the islanders hadn’t realised that the soldiers created the airstrips because there were planes that wanted to land. The planes caused the airstrips - not the other way round! Without the planes, there would have been no desire for control towers or signal fires, for radios or waving arms, or for headphones, coconut or otherwise. And although these artifacts made it easier for the planes to land, the soldiers could have experienced some success with just a bare strip of earth and a little caution.

Agile values

In World War II, the leaders who wanted to win the war realised that planes were necessary. The air-strips helped them to use the planes effectively.

In Agile, the Agile practices that we know have emerged from teams that wanted to deliver valuable, working software, and who had discovered certain personal values that were effective in delivery. The practices they used allowed them to leverage those personal values effectively, but really, a bare strip of dirt - or any kind of process that reminded them what they were trying to achieve - would have enabled them to experience some kind of success.

I’ve found lots of different names for the values that allow teams to be successful - collaboration, trust, responsibility, innovation, camaraderie, rapport, honesty, transparency, helpfulness, forthrightness, motivation, responsiveness, agility, idealism, pragmatism, curiosity… the list goes on. They’re all wonderful ways of expressing those personal values, and I’ve seen or heard of teams succeeding with these values, regardless of which methodology they use. Partly this is because the values they’ve adopted allow them to try things out, to feel safe in questioning the processes they follow, to recognise better ways, and to be pragmatic in balancing the adoption of new ways of doing things with the responsibility for delivery.

I’ve also found that the following five values encompass pretty much everything that I’ve written in the list above, either alone or in combination:

• respect - the belief that other people are valuable, able to teach you something and amaze you, able to succeed given experience and support, interested in others’ well-being and success, and motivated by the desire to make the world a better place; and that any behaviour to the contrary is caused by external pressures or ordinary, forgivable human frailty
• courage - willingness to try new things which might not work, to accept personal risk for professional gain, to make oneself vulnerable in order to learn, and to lead others to do the same
• communication - the art of making oneself clearly understood, understanding others and feeding back any lack of understanding so that it can be corrected, listening and imagining, being aware of the impact of communications (verbal and otherwise), and finding other ways to communicate when required.
• simplicity - the ability and desire to reduce complexity, mitigate or isolate it where it’s inevitable, and avoid introducing it; to start, where it’s possible to start, without worrying about how or where it will end.
• feedback - knowing that our perception of our world and the ways in which we model it may be inaccurate, actively seeking out those inaccuracies (which may require courage!), trusting any existing mechanisms which can inform us of those inaccuracies, and listening to them when they do.

These are the five values of Extreme Programming, as outlined by Kent Beck (the poor definitions are my own).

As a coach, I’ve run competitive workshops in which these values formed the basis of the point-scoring. I’ve seen companies, especially Screwfix, adopt Agile using these values as a backbone, and seen them successfully release projects with previously unimagined scope and resource constraints. I’ve seen Scrum adoptions that were failing take on these values and begin working out the kinks, and XP adoptions that were rigidly bound by their processes, but whose employees lived by these values, become more fluid and successful as they aligned themselves accordingly.

I’ve also seen methodologies adopted without these values, leading to rebellion and the quick return to known, established practices that don’t leverage them. I’ve seen mailing lists on Agile topics become cliques - at least, I don’t feel I can post in them because of the lack of respect shown by some participants to others. And Kent Beck himself had to add that value - Respect - because it turned out not to be as obvious as he would have liked.

Measuring values

I’ve used the Dreyfus Model of Skills Aquisition frequently to measure how well the adoption of particular practices is progressing. I’ve found it useful to map the levels to these values as well, where:

1. Novice: still shows anti-patterns, behaviours which are not aligned with the values
2. Beginner: behaves like a normal human being, and would be pleasant to work with
3. Practitioner / Competent: is a model for these values, has few “off-days” and is forgiving of others on theirs
4. Knowledgeable: maintains these values intuitively, not only as part of their work-life, and can lead others in adopting them; has become a better person as a result of adopting these values
5. Expert: maintains these values in the face of adversity and in environments where these values create vulnerability; can articulate the benefits of holding these values both personally and professionally; can teach others and provide constructive feedback to help them adopt the values and leverage them more effectively.

That “Practitioner / Competent” level, 3, is in my experience the average that a team needs to achieve in each of these values in order to successfully adopt any Agile or Lean methodology. They also appear to lead to more enriched, fulfilling lives at work.

Landing planes

The great thing about these values is that it’s hard to introduce perverse incentives when using them as a metric. One participant in a workshop asked, “What if we just pretend?” Well, you can’t pretend to communicate better without actually communicating better. You can’t pretend to make things simpler without reducing complexity. You can say that you don’t believe in these values, or that you don’t think they’re helpful - but in my experience, teams who’ve tried them have discovered that they’re so much more fun than not maintaining them, they haven’t looked back. Even pretending to value these values leads to good habits, and the reaction of co-workers has often been positive enough to cause them to be subconsciously ingrained.

So, give it a try, and if you’re thinking of adopting Agile or Lean, land those planes first. The practices will follow, and make a lot more sense.

Originally published at lizkeogh.com. Please leave any comments there.

I just read Matt Amionetti’s thoughtfully worded response to the reaction he’s got from his presentation, “CouchDB: Perform like a Pr0n star”.

Indeed, reading the response, it seems almost inconceivable that anyone could possibly be offended by his presentation. Matt warned people beforehand that there would be potentially offensive images, I believe in his stated intentions, and I heed his call that we should be contributing something useful to the discussion.

So, I’d like to give you, the reader, a little bit of insight into the human brain, how it makes connections and comparisons, and help you to understand your power over other people and their perceptions.

I’d like to start by telling you another story.

The Tale of the T-Shirt

On one dress-down Friday, a colleague came in wearing a beach T-shirt, featuring a topless woman coming out of the surf. It was just a black and white image, and the focus was on the scene as a whole, but nonetheless some of us felt that it was inappropriate. So I asked him not to wear it again.

“Why?” our colleague said. “I didn’t think it would offend anyone.”

“It’s not really that it’s offensive,” I said, “but think about this. I’m pair-programming with you, sitting next to you at a table. Someone else comes along to talk to both of us. They see your T-shirt, with that image, and then they scan across from that image to me. Can you see the comparison they’re making in their mind? Even subconsciously? That’s why I would prefer you not to wear that T-shirt - so that people don’t think about topless women while they’re talking to me, and while I’m trying to work. At worst, the comparison is offensive. At best, the t-shirt is distracting.”

Our colleague took the feedback very well, and agreed not to wear the t-shirt again.

How the brain makes associations

The human brain consists of a bunch of neurons, between which connections and pathways are built. Those pathways form associations. There are associations of which we’re conscious, associations of which we’re not conscious, and a blurred space in between.

Here’s a conscious association. If I want to remind myself to pick up my dry-cleaning after work, I can hide my handbag. Sound strange? Well, as soon as I go to pick up my handbag, and it’s not where I left it, I’ll remember why I hid it. I’ve built myself a conscious association between the absence of the handbag, and the task I had to remember.

For a subconscious association, watch yourself thinking of all the things you remember about Germany, when I say the word “Germany”, or “Elephant”. The vast majority of our associations are not in, and often not available to, our conscious mind. They add to our personality, drive the learning we get from our experiences, and there are simply too many of them for us to be aware of them all.

For an example of the blurred space between, I offer my fiancé’s habit of driving directly home from the station, even though we agreed we’d stop at the Chinese takeaway on the way home. He associates the act of driving down a particular road with a particular route, and consciously manipulates the car to follow his subconscious association.

So what does this have to do with pr0n stars?

Human beings learn associations by - amongst other things - proximity; either in time, or in place. That is; they will build associations more easily if two or more things are experienced close together.

If you’ve watched Matt’s slideshow, and you find yourself using CouchDB on a project in the future, will you be thinking of his slideshow? It was very memorable. I think I will find it hard in the future to disassociate that slideshow from the featured product. That’s a conscious association I’ve built. I’m aware of it.

There’s a subconscious association going on in that show, too; another proximity which is harder to spot. We’ve just experienced words of technology - key phrases like scalability, REST, public interfaces - with images of women whom we’re told are available for visual sexual gratification. There are a few men in some of the images; they appear to me to be in positions of power and influence. The images of women, on the other hand, tend to be submissive. So we’re learning, subconsciously, that women associated with technology are also associated with sexual gratification and submissiveness. (The only strong women in the slideshow are associated with conflict, which we try to avoid.)

If you doubt this is true, look through the presentation (and bear in mind that it might be considered Not Safe For Work). At some point, Matt introduces a picture of a typical development team. To which team member are your eyes drawn, and why?

At the very least, we start making comparisons. No wonder she doesn’t look happy.

The power of people with influence

Earlier this year, I finished reading Robert Cialdini’s “Influence”. It’s a very readable, memorable book. It explains some of the ways in which associations are made. In particular, he describes these mechanisms for influencing other people (his titles, my poor definitions):
 

• Social proof - if other people do it, we should do it too
• Authority - if someone in a leadership position tells us to do it, we should do it

Examples which Cialdini uses to demonstrate these concepts include the mass suicide at Jonestown, and the Milgram experiment.

So, if a community is building associations, or you’re recognised as or portraying yourself as an authority telling people to build associations, those associations will be stronger than normal. People will be more likely to act on those associations. In the same way that my fiancé takes the turning for home, “routes” will be set which the brain naturally follows, and acts upon. And it will seem perfectly reasonable, or justifiable, to do so - at the time.

So what can you do now?

If you were sitting in Matt’s presentation, or have experienced similar presentations or associations in the past:

• you might consciously choose to wear a topless women on your t-shirt, because your brain subconsciously confirms that it’s acceptable.
• You might expect women to be more submissive; to accept delegated tasks more easily, or question process less, or accept lower pay.
• You might find it uncomfortable to have a female manager or team lead.
• You might cause the women around you start dressing in less feminine ways, to distance themselves from any association.
• You might erroneously think you have a chance of scoring with your female colleague (notwithstanding cases of genuine mutual attraction).
• You might not expect the woman on your team to be able to teach you anything new.

And, if you’re Matt, or one of the many commenters whose opinions I’ve read, you might not completely understand the backlash. Hopefully this post helps.

If you’re not suffering these or similar biases, trust my experience that others are, or have done, and start thinking about how you might have been influenced. The associations aren’t helpful for me, and I doubt they’re helpful for the people who have them. Recognising the influence of others will help you to consciously choose different paths.

Hopefully if you’ve found the presentation through this blog, you’ve now read through this post and are now better guarded against these associations. (That’s why I didn’t put the link at the top).

You can also strengthen more useful associations. Go find the women in your team and talk to them about their technical abilities; the things that brought them to IT; times when they’ve felt empowered and assertive. Find strong female role-models - I recommend Esther Derby, Desi McAdam, Sarah Taraporewalla, Johanna Rothman, Cyndi Mitchell, Rachel Davies, Angela Martin, and many others too numerous to list here. If you’re looking for something more entertaining to get into your subconscious, try Ellen Ripley, Buffy Summers, Alan Moore’s “Promethea” or Manda Scott’s “Boudica” series.

And, if you’re thinking of presenting something similar in the future, be aware of the power that you have.

On engendering subconscious reactions

Matt entitled his response, “On Engendering Strong Reactions“. I’m worried about the subconscious reactions; about the effect that it has on the people who see that presentation and the way in which they react to me, and to my other female colleagues, afterwards. Matt said, “I would have hoped that people who were likely to be offended would have simply chosen not to attend my talk or read my slides on the internet”.  That doesn’t stop the associations being built, and I can’t necessarily avoid working with people who have built those associations.

So I’m not offended by the presentation - I can understand why some women might be - but I am concerned by it. Hopefully this provides some positive insight into why. Matt - I hope you find it useful and enlightening; please let me know.

Originally published at lizkeogh.com. Please leave any comments there.

Prompted by Szczepan’s post.

I have written tests after code when

• the code is already there, but I / others don’t know what it does or how to use it, and we need to
• I wrote a spike which turned out to be pretty good code, and I wanted to describe what it does and how to use it
• I realised I needed to add some simple yet important behaviour while making a different test pass, and forgetting to add the code would possibly introduce serious bugs, so I added it as I went along and now I’m going back to show what it does and how to use it
• I was learning how to write the tests first, and wanted to know what they would look like.

Originally published at lizkeogh.com. Please leave any comments there.

Today is my last day with ThoughtWorks.

It feels strange to be leaving a job I love with the most amazing company in the world, at a time when I should rightly be thankful for having a job in the first place. So, let me explain why I’m going.

Remember this post, back in November? I decided to actually do some work on the novel which has been hanging around my head for some years. Remember all the follow-up posts in which I told you how I was getting on?

No, neither do I.

The truth is that my day-to-day work - coaching, development, and learning about how brilliant, technical people think - has been taking up huge amounts of my life, time and creativity. I have no regrets about the energy I’ve put into it; watching teams and individuals learn and grow, knowing that I’ve been part of that, gives me pride and hope for the world. Learning how to help them better, and having them teach me, is fun and uplifting. It’s also incredibly draining on my creative energy. Looking back, I’ve hardly written any haiku in the last six months, and I’ve had no poetry published in two years. Nor have I made much progress with the novel.

So I’m going to leave ThoughtWorks and strike out part-time as an independent consultant. (I’m ideally looking for about three days a week leading or helping with Agile transformations, and will be flexible.)

The rest of my time will be going into ongoing training and development - giving my brain the space it needs to learn properly, to create the workshops and training courses which will be most effective - and, of course, writing my book. Maybe more than one of them.

So, from one world to others. I’ll be spending the next month or so in the diverse company of Grey the cat, Susan, Susan’s chair-dragon, Pigeon, Koley, Aquila, the Lunivore and the dryad of Islington Green.

They’re wonderful to be with, but I’ll still miss you.

Originally published at lizkeogh.com. Please leave any comments there.

When we first wrote JBehave 1.0 we quickly recognised that there was power in the scenarios; in the conversations that they could help to drive, and in the reusability of the steps.

I loved the ease with which you could combine smaller steps to make bigger ones, use scenarios as the contexts of further scenarios, and take the necessarily procedural automated tests and turn them into sets of reusable objects.

Now BDD is more widely used, and people out there are using JBehave 2 and RSpec, and I hear complaints. Amongst them, this is one of the more common:

“Every time I change this screen, I have to go through fifteen files and add another step.”

Since JBehave uses plain text scenarios you can’t rely on the common refactoring tools, and that can make it a bit more painful than just messing with code. So, I thought I’d have a go at explaining how I avoid this issue; by sharing some of the ways in which I divide or combine contexts, events and outcomes into reusable components that help me avoid duplication in my scenarios.

Given a context

A context is a state which was set up by irrelevant forces, and which is used within the scenario to alter the outcome resulting from the events.

If the manner or time in which the context was set up matters, then that, too, is part of the context; unless it’s part of the behaviour you’re looking for, in which case it’s an event. The only reason for separating the contexts in which a scenario occurs from the events which are performed in the scenario is because it doesn’t matter how they were created. This means that Givens have more flexibility in implementation than Whens.

A context should matter. If you can remove the context from the scenario without changing the outcomes, it isn’t part of the Givens.

A context should be independent of other contexts. So, I prefer Given a wet newspaper to Given a newspaper / Given that the newspaper is wet. The first is less likely to require refactoring than the second.

A context should create an abandonable artifact. By this I mean that the forces which created the artifact - data in the database, files on the disk, a particular page at a given URL - can safely forget about the context they’ve created. Given an article about Iraq is a good context. Given I am logged in is not so good, even though we frequently use it as an example. Sorry. If it helps, it’s a step that rarely needs maintenance. Given we’ve filled in the comment box and are ready to submit it is likely to cause issues, because of all the other tiny steps that you have to use to get there.

When an event happens

An event exercises the feature whose behaviour you’re interested in when describing or running the scenario.

If you don’t care whether it works as long as it leaves things in a clean state, it’s a context. If you don’t actually need to do anything to cause an outcome - you’re simply checking that given some state, some other state is also present - you don’t need to write an event; just skip straight from Given to Then.

An event should create a valuable outcome.The granularity of the ideal event is very similar to that of the ideal context. As a user, I don’t want to go to the screen with the book, click the purchase button, navigate to the basket, enter the credit card number and click “submit”. I just want to buy a book. By specifying the steps which a user purchases a book inside the granularity of this larger step, we capture the value of that step. Since people rarely do things that they (or their sponsor, paymaster, loved one, etc.) don’t find valuable, this can usually be reused as one large step.

An event may be dependent on context or on another event. So, when I buy a book, and when I cancel my order within 15 days, then I should not be charged for the book.

An event should cause or contribute to an outcome. The outcome is something measurable. It could be that the outcome you’re looking for is an absence of something, for instance if a user’s preferences have been changed, and you no longer want to see all those Facebook groups. If it doesn’t cause an outcome, it’s a fairly irrelevant event.

Then an outcome occurs

An outcome describes the benefit that your system or application provides when the events are performed in the given context.

An outcome should have teeth. If a particular error message doesn’t have the exact wording expected, the world will not come to an end. If my credit card gets billed for the books but I don’t get them when I expect, it might.

An Outcome should be Specific, Measurable, Achievable, Relevant and Timeboxed. Ask a QA if you don’t know what this means. QAs are wise and can break anything.

An Outcome should represent the valuable purpose of the events. Instead of checking that a series of menus exist when you navigate to a particular screen, write a scenario that uses those menus and check that the benefits they provide are accessible through them.

Stories and regression tests

It can take quite a while to run scenarios. I sometimes like to turn mine into regression tests by combining them. I like to add contexts, events and outcomes to existing scenarios to better describe the benefits of using any particular feature in any particular context. This may mean that scenarios are related to more than one story. This will help keep them maintainable, and isn’t a bad thing.

I have never found the need to add a context to a scenario half-way through that scenario, even if it’s been created from several others.

I do frequently use one scenario as the context for other scenarios.

Unteaching the business

Sometimes, we accidentally train our business to talk to us about the solutions they’d like, occasionally in the language of software development. In that case, they’ll quite happily discuss the particular steps they need to take in the GUI to achieve the desired outcome, and may even have an idea of the underlying database tables and discuss what ought to be in those tables after the events.

If this happens, try to draw the conversation back to how the data will be used; why it’s valuable to produce that artifact in the first place. You never know; you may find you need to do less work than you thought you did.

Originally published at lizkeogh.com. Please leave any comments there.

Last week, the XtC London group met up with the SPA2009 attendees. Joseph Perline ran a panel session with Tim Mackinnon, Rachel Davies and others in which they discussed the weakening of the Agile brand.

One of the most interesting comments was Tim’s assertion that Agile “fails the purchase test”. That is; if someone won’t buy the opposite of what you’re selling, then the brand of what you’re selling has no value. In Agile terms, if no team will claim to be “not Agile” then the word “Agile” itself no longer has any value.

How many teams nowadays will actively claim to still be running Waterfall, for any flavour of Waterfall? Of course not. We’re all “Agile”, aren’t we?

At an Agile 2008 keynote, Uncle Bob asked everyone who was on an Agile project to raise their hands, then put them down if they failed any of certain criteria: no unit tests, no acceptance tests, iterations of more than two weeks, no showcases to the business, etc. By the end, hardly anyone had their hands up.

So, given that those of us who are on Agile projects are often less than perfectly Agile, how do you decide whether you’re actually in that space, or are merely one of the teams weakening the brand?

Do you know what “not Agile” looks like? And are you sure it doesn’t look a bit like you?

Originally published at lizkeogh.com. Please leave any comments there.

People often ask me to review their unit tests, or answer questions on how to write different aspects of tests. I frequently find myself making the same suggestions over and over again. So, if you were thinking of asking one of these questions, maybe these common BDD refactorings will help.

I have 10 different instances of this class or enum. Does that mean 10 tests?

Tests should make things easy to change. What you’re doing is pinning down your code so that it’s hard for people to break it. I know that when your code is changed and the test breaks, people will look at the tests and work out what went wrong; that’s because your tests are brittle. Instead, I’d rather people came and looked at the tests because they’re clear examples of how to use the code and why it’s valuable.

QAs use equivalence partitioning. They say, “If I do this, it’s equivalent to doing these 5 other cases. So I don’t need to do those.” They also look at boundary conditions, where a shift in context starts to produce different behaviour. If we can do this too, we can cut down the number of different examples we need to produce for one aspect of behaviour.

So, for your ten cases, I might have just a few examples. This makes it easy for people to add more examples, and encourages them to understand the boundaries and partitions. We want it to be easy for people to change the code.

How do I do <this complicated thing> with my mocking framework?

Tests should make things easy to change. If you’re doing something complex with mocks, this is what it looks like:

• Given <this context>
• Expect <this outcome>
• Also <this really complex stuff that you have to read carefully>
• When <this event happens>
• Then <go back to the expectations and read them, because this is where that gets checked>

If the mocking you’re doing is making it harder to change the code, or you don’t have access to something like Mockito, try rolling out your own. This will make it easier to do the things you want in a legible way, and any assertions can happen at the end of the test, along with the rest of the outcomes.

I’ve called my test should<ReturnTrueWhen...>. Is that right?

Tests should make things easier to change. Why is returning true valuable? Because it triggers some business process? All right, then let’s call it should<TriggerSomeBusinessProcessWhen...>. This will encourage people to read your tests. While you’re at it, you might want to rename the method to the same thing.

Yes, you’ll get duplication between the test name and the code name. That’s because your method is doing what it says on the tin, and you’re providing an example of how to do that.

Now my test is called should<TriggerSomeBusinessProcessWhen...>. Do I need to write shouldNot<TriggerSomeBusinessProcessWhen...>?

Tests should make things easier to change. If I have to look in two different places for the examples of behaviour I want to change, then it’s not so easy. So, maybe not.

There are three ways of doing this. I’m guessing that triggering the process is the “happy path”. If this is the only valuable thing that happens, and it always happens, that’s fine - that’s the first way. But we know you were returning true, so there’s something else we need to consider. Is the happy path valuable without the sad path? For instance, a list tells you when it’s empty. That’s not valuable unless it also tells you accurately when it’s not empty. True for empty, false for not - they’re the same piece of behaviour. Neither is valuable without the other.

If you have two tests - one for each - you might want to put them in the same test method. Now you’re describing the behaviour holistically. I know Dave Astels said “one assertion per test”. We’re only looking at one aspect of behaviour. That’s the second way.

Of course, you might have a third way too. If you have several exceptional cases, you can list these as exceptions. So you’ll have one shouldNot<TriggerSomeBusinessProcessWhen...> for each context in which the process is not triggered. Validation is a good example of when this happens; you would normally have one description of the happy path, and one description for each of the exceptions.

I can’t write these automated tests. It’s very difficult to describe how to use my class.

Really? Probably it’s quite a difficult class to use correctly, then. How did you think of that API? Did you think of the class first, then think about how to use it?

Instead, try thinking as if you were the consuming class. Think, “I need something that does this for me. This is how it should look. This is how I want to use it.” Then write some code that does exactly what you want.

Because you’ve thought about how your class is going to be used, it will be easier to describe how to use it in the examples. It will also be easier to understand. So when you do successfully write your tests, you’ll know that your code is easier to change.

Originally published at lizkeogh.com. Please leave any comments there.

I was warned that there would come a point when the few spam posts I was getting would suddenly multiply to the point where I couldn’t keep up with them, but I didn’t listen. That point just came today.

I’ve deleted over 100 spam posts this morning, and installed a filter. If you made a comment that hasn’t appeared, or has mysteriously disappeared, I apologise - please feel free to repost. It should hopefully make it through the noise this time!

Originally published at lizkeogh.com. Please leave any comments there.

Damien Guard introduces the other *DDs..

I particularly like “Psychic Driven Development” and “Golf Driven Design”. Thanks, Damien.

Originally published at lizkeogh.com. Please leave any comments there.

Finally, an approach to pairing which maximises colocation. It’s guaranteed to bring people closer to my thoughts. I can’t wait for the new batch to arrive.

Originally published at lizkeogh.com. Please leave any comments there.

Simon Baker has written a superb post, capturing the elusive nature of empowerment.

He mentions “an environment that tolerates mistakes to cultivate learning”. For me, this is an essential part of innovation; of the Lean metaphor that suggests a Software Development team is more like a Product Development team (designing new cars) than a Production Line (churning out the same thing repeatedly).

In a Production Line, we try to minimise variance (think Jidoka and Continuous Integration and Deployment).

In a Product Development team, we try to maximise learning opportunities, which means experimenting (think risk, innovation and doing things no one’s done before).

“There is no such thing as a failed experiment, only experiments with unexpected outcomes.”
— Richard Buckminster Fuller

Are mistakes in Software Development really mistakes? Or just experiments from which we learn something new? And if they keep happening… what didn’t we learn?

Originally published at lizkeogh.com. Please leave any comments there.

I’ve been wanting to try out Edward de Bono’s Six Thinking Hats for a while now, and finally got the opportunity in a workshop last week.

I was working with a team who had a vague understanding of the roles we ought to be playing, and we wanted to clarify them. We only had a short time for the meeting, so we used the hats to help us. In an unstructured meeting, everyone will have a particular bias. Some people are very positive and look for the good in everything. Others are risk-averse. Others like to concentrate on the facts, or see the big picture. By focusing on each aspect of these in turn, we were able to give voice to everyone’s preferred bias.

As the facilitator, I took the blue hat - the big picture - and used it to introduce the agenda for the meeting, outline our objectives, and summarise what we’d learnt at each stage. Each stage was simply a brainstorm with post-it notes, which we stuck on different areas of the wall around the room.

The team started with the yellow hat, looking at the positive aspects of the problem - what our proposed solution would achieve, and what resources and people we had available or hoped to use to solve the problem.

Then we used the black hat to work out what risks might jeopardise our solution. I used the concept of a futurespective here, too, as a number of the participants confessed to having a positive bias. “It’s three years from now, and we failed. Why? What happened?”

The white hat - focused on facts - helped us look at what we knew about the problem and the solution, and what was still puzzling.

At each stage we spotted themes. I now took the blue hat again and repeated these briefly for everyone present.

We used the green hat creatively to work out what our roles should be, given the yellow, black and white hats.

As a result, we realised that up until the workshop, we had been very focused on technical detail, and not as much on the people-oriented aspects of the problem. I kept the red hat with its emotional focus in reserve in case anyone seemed unhappy, but everyone was smiling when they left, and my team-mates declared the workshop a success!

I borrowed the programme for the hats from Wikipedia, which has a great summary. We ran the meeting across virtual conferencing in three countries, using big, coloured pictures of hats to remind everyone of the focus, and to provide a visual anchor and memory aid. Dan mind-mapped the results; this also works very well with the pre-defined themes.

Next time I think real (or paper) hats may be in order…

Originally published at lizkeogh.com. Please leave any comments there.