Liz Keogh, lunivore

Naresh Jain has very kindly put up the slides from my BDD presentation at Agile Mumbai.

I deviated quite heavily from previous presentations I’ve done and talked about the history of BDD, how it evolved and the people and events that made it happen. You can find links on the last page to some of the more influential sites, groups and people – all good places / entities to hang around for innovative thought and challenging questions.

Many thanks again, and particularly to Dan for being unavailable, Naresh and Agile India for inviting me instead and Thoughtworks for letting me go.

How people

You’ve spent years making yourself invaluable to your friends, family and colleagues. Your confidence is at an all-time high – how many people in the world can do what you do? Watch out, though; pride cometh before a fall. You’re a deep roller. Let’s hope one of your parents was not.

Your tool of the month is Mingle Proj-o-matic.

Why people

Yesterday the room was crowded. The smell of pressure hung heavy in the air. The quiet tap of fingers on keyboards, the whispered conversations, the passionate arguments, the occasional round of applause as a story reaches completion – these were the sounds that punctuated your life. So how come it’s suddenly so quiet?

Your word of the month is anachronism.

Who people

They promised a future in which robots clean the house, food is manufactured by holes in the wall, money is irrelevant, war is history and learning is taken in pill form. It hasn’t happened yet. There’ll always be work for people people – shelve any plans you had for holiday this month; you’re needed right where you are!

Your pub of the month is Leela Palace, Bangalore.

When people

A blank page can stifle the most imaginative mind – sometimes creativity requires a place to start. Still, if mistakes are cheap then there’s room to play. Imagine a world in which you could write things down in English, and just have it work. Imagine what would happen if you didn’t even need to write it down. The brain is the most amazing computer in the world… so far.

Your quote of the month is:
Any sufficiently advanced technology is indistinguishable from magic.

—
What’s my sign?

I proposed an Open Space session at Agile Mumbai to discuss Perverse Incentives and gaming the system in Agile projects.

A perverse incentive is one which produces an effect that works against the interests of the people who proposed the incentive in the first place. Gaming the system can be thought of as working deliberately through the path of least resistance or greatest reward, towards the incentive, even if the effect of working that way is perverse.

Many thanks to the Open Spacers who came up with the practices.

Here are some situations which led to the discussion.

• Situation 1: An IM notices that the team often underestimate cards. He berates the team for not spotting the problems that will slow them down and fixing them or at least factoring them in.
• Desired effect: The team deal with the problems that are slowing them down and speed up. The estimates become more accurate once the surprises have gone away.
• Actual effect: The team factor in larger estimates and contingency – it’s easier than spotting and dealing with the tricky problems. Because they don’t always need that contingency, there’s less pressure to finish the tasks to which they’ve committed themselves. Without that pressure, they slow down.

• Situation 2: Two developers go off on their own to investigate a possible solution to a tricky problem. They don’t tell anyone they’re doing it. The solution they’re thinking of was already investigated and discounted. When the PM realises how much time has been wasted, he puts a process in place to ensure that any work that gets started has been approved with the team lead, that the business value has been agreed with the BAs, and that acceptance criteria have been defined. Anyone who starts work without following the process is reminded of the time wasted on the project by people doing work that’s not valuable.
• Desired effect: Less time is wasted doing work that doesn’t deliver business value.
• Actual effect: Developers waste time waiting for the team leads and BAs to come out of meetings. Refactoring and other cleaning up, which doesn’t deliver business value directly, slides. The project slows down. Developers feel untrusted, and project leads spend all their time chasing up developers to make sure they’re following the process.

• Situation 3: The customer is unavailable when the developers want him. The developers spot the bottleneck and ask the business to assign more of the customer’s time to them.
• Desired effect: The customer answers the developers’ questions, and the developers can deliver the right thing.
• Actual effect: The customer loses touch with the users and with his peers. He doesn’t get to use the end product, so becomes less interested in it. When the product is delivered, the users want many changes and the application no longer solves the needs of the business. The business also suffers because the customer is an skilled expert, and is less available to help the business in its day-to-day work.

These were all real situations which we either encountered or were concerned about happening on our projects. We also brought up some examples outside of the software domain, in the fields of healthcare and education. That prompted a slew of other examples, and the discussion kicked off.

These are the questions we wanted to answer:

• What stops processes delivering their desired effect? When processes are created that do deliver the right effect, how are they crafted and what is their focus?
• What meta-practices could we put in place that would help stop perverse incentives from being created?

Human perception skews us towards perverse incentives.

During the discussion, we quickly realised that we have an emotional attachment to weakness. Good practices and implemented solutions are invisible; they don’t impinge on our consciousness. A bad practice or a problem stops us from doing what we want. It demands our attention; demands that we stop what we’re doing and fix the problem. So our focus is skewed, and we automatically allow our efforts to drift. We fix the bad practices, instead of introducing good practices. We confront the problems, instead of finding a route around them.

Some practices which help us avoid perverse incentives.

NB: Whenever I’ve used words like “measure”, I would also like to include curious observation, intelligent reasoning, judgement through experience and blind intuition – anything which is going to affect the changes you make as a result of the measurement. Some of these ways of measuring are more practical than others, depending on the context, and who’s doing it. Pick one that works for you.

1. Measure reality, not comparative reality.

   Don’t measure how many stories were underestimated; measure how much they were underestimated by. Don’t measure how often the customer is unavailable; measure how many hours he’s there / not there. This will help you to measure the true scope of the problem. It will also help to remind you to…

2. Keep the balance when measuring.

   If you’re measuring underestimation, also measure overestimation. If you’re measuring how often a customer is unavailable when you want him, also measure how often a customer is available, but unused. If you’re measuring how many developers waste time because they haven’t followed the process, measure how much work gets done because developers don’t have to wait to follow the process.

3. Consider aspects of the practice you’re about to change that might be beneficial.

   Consider how those meetings in which the customer spends his time might help your project. Measure how much the developers who went off on their own learnt about the domain and the technology, and how much work they got done in the following month as a result. Consider the time that project leads who aren’t chasing up errant developers can spend on other things.

4. Measure objectives as directly as you can.

   If you want to make your customer happy, get your customer’s feedback, not the devs’. If you want to deliver business value faster, measure how much business value you’re delivering. If you think that rogue developers are slowing down development, look at the change in velocity. Don’t guess or apply reasoning if you can get real figures.

5. Fit your process to reality, not reality to your process.

   If your process requires your customer to be there and he’s not, maybe change the process – get some BAs, or arrange for another customer to help you. If the estimates are consistently awry, change the process of estimation rather than trying to fix problems that may be unfixable (there is no silver bullet). If your developers waste time doing something that’s already been investigated, make sure the results of investigations are published in a place where they’ll read it.

6. Concentrate on the things that enable you to get work done.

   Counteract the skew towards weaknesses by deliberately emphasising strengths. We know this works when applied to people and their abilities. It can also work when applied to a process and its practices. Appreciative Enquiry can help create an environment conducive to spontaneity, to getting things done and coming up with imaginative solutions based on things that worked before (and which are therefore less likely to be perverse).

7. Give feedback, especially if something or someone works well.

   We tend to focus on weaknesses in ourselves. Help the team appreciate their strengths, and avoid focusing on their weaknesses. If there’s something that needs doing and nobody is doing it, don’t berate the team – find someone who does it well and get them to join in.

8. Provide evidence when providing feedback.

   What evidence is there that the developers have slowed the team down? That the customer’s unavailability has negatively affected the project? How many unfinished or rejected stories were there as a result?

   What did the developers learn as a result of their investigation? What did we learn about our processes? What did the customer provide us with as a result of the meetings?

9. Make sure that the person in charge of an aspect of the project has an interest in maximising that aspect.

   Don’t praise the IM because his team meets the estimates – praise him because the amount they’re actually doing goes up.

   Make sure the customer assigned to answer the team’s queries has an interest in the final product.

   If you want developers to stop wasting time, introduce them to the customer, and ask the customer to tell them how valuable their work on the end product is – give them the motivation to deliver.

10. Bring in a fresh perspective.

    Good improvements are often incremental. Sometimes it’s hard to see which practices you’ve put in place that enable a project everyone said couldn’t be done. An external observer can make you re-examine what you do, as well as helping you to pass on those unique practices to other projects and teams.

    Alternatively, try teaching your practices to people who aren’t familiar with your project or methodology. When they ask questions about how that works, given your situation, write the answers down.

I used to get angry with ignorant people, until I realised that it only made them hide their ignorance. Then I realised that I was ignorant too. Now I love ignorant people best of all. I deliberately seek them out; they give me the greatest buzz in the world.

I particularly love helping them appreciate their ignorance, mitigate against it, and eventually displace their ignorance to somewhere else.

Some people like to call this movement “learning” and the act of helping people with it “teaching”, but really, the idea that we can somehow put an end to ignorance is entirely illusory. The only thing we can do is to move the ignorance around, and find out which places it moves fastest and with the most fun attached.

We call those places “strengths”, and people who can move their ignorance quickly are “fast learners”. “Experts” have done more shifting of their ignorance than others. “Gurus” are the ones who’ve managed to handle an exponentially increasing amount of ignorance, finding more of it in themselves than most people can ever handle. Some of them have found patterns for shifting the ignorance quickly. It’s still there, though.

I want to be a guru one day. Gurus are the best. They teach me all the new places of ignorance that I never knew were there, and open my mind up to just how much of the stuff there is. I can’t imagine anything worse than running out of things to learn. Having lots of ignorance to play with is just lovely.

Now, where did I put that Ruby tutorial?

Last year, my colleague Ben introduced us to the joys of hand-rolling mocks. This allowed us to ignore interactions we weren’t worried about, leading to cleaner tests.

This year, I’m mocking again. I’ve mentioned it briefly before, but now that I’ve used Mockito a bit more, I really love it. Here’s a quick summary to show why.

public class GameBehaviour {
    
    @Test
    public void shouldApplyRulesToOriginalGridThenEachGeneratedGridInTurn() {
        // Given
        Rules rules = mock(Rules.class);
        Grid firstGrid = mock(Grid.class);
        Grid secondGrid = mock(Grid.class);
        Grid anyGrid = Grid.NULL;
        
        GridFactory factory = mock(GridFactory.class);
        stub(factory.createGrid(anyInt(), anyInt())).toReturn(firstGrid);
        
        stub(rules.applyTo(firstGrid)).toReturn(secondGrid);
        stub(rules.applyTo(secondGrid)).toReturn(anyGrid);
                
        // When
        Game game = new Game(5, 5, rules, factory);
        game.nextGeneration();
        game.nextGeneration();
        
        // Then
        verify(rules).applyTo(firstGrid);
        verify(rules).applyTo(secondGrid);
    }
}

There are some quite complex factors in this Game of Life – infinite, bounded or wrapped grids, rules which could be Conway’s or the High Life rules, etc. – hence the design pattern overkill. Here’s something simpler:

public class GameFrameBehaviour {

    @Test
    public void shouldHaveAButtonForTheNextGeneration() throws Exception {
        // Given
        WindowControl windowWrapper = new WindowControl("game.frame");
        Game game = mock(Game.class);
        new GameFrame(game);
        
        // When
        windowWrapper.clickButton("next.step");
        
        // Then
        verify(game).nextGeneration();
    }
}

I leave it to you to work out what these look like with other mocking frameworks. You can look at Szczepan’s comparisons to get an idea.

Thanks, Szczepan.

How people

God grant you the serenity to accept the things you cannot change, the courage to change the things you can and the fortune to have little need for either. Some things exist just to make your life easier. Hope you get yours soon.

Your tool of the month is the MacBook Pro.

Why people

It seemed a simple enough task, so you gave it to someone else to do! You thought that a few hints and tips would be enough to set them in the right direction – but now you come to look at it, you realise that hidden underneath the simplicity was a right can of worms, which they’ve happily opened up and tipped back onto your desk. Messy.

Your word of the month is lumbricide.

Who people

We started with drums and beacon fires, moved on to mail and semaphore and eventually developed the radio. Now the internet provides the ultimate in communication. Pity the signal-to-noise ratio is so low! Still, with sites like FaceBook and MySpace, you too can ensure that the web is a better place for having you in it. If you get the chance, send me zombie blood.

Your pub of the month is Styx, Bangalore.

When people

You know you’re too busy when you get off the plane and get onto the phone; get off of the phone and get on with the job; get off to a good start and get on with the new guy. With all this getting on and getting off, it’s hardly surprising you’ve forgotten something. If only you could remember what it was!

Your quote of the month is:

Footfalls echo in the memory
Down the passage which we did not take
Towards the door we never opened

T.S. Eliot

—
What’s my sign?

I finally got around to updating / rewriting the BDD page on Wikipedia.

This is either based on things Dan’s said or written, or things others (including me) have said or written and which he’s approved in my hearing as “official BDD”. I may well have made mistakes. I haven’t written any in-text citations as yet; will do that as and when I next have time (if no one else gets there first!)

Now, when someone asks me what the difference is between BDD and TDD, I have somewhere to point to. Many thanks to the contributors who wrote the predecessor. BDD’s come a long way since the article was first written, but your thoughts really helped me formulate mine.

Go edit. 🙂