If the only metric you use for measuring and forecasting your team’s progress is their iteration velocity, you’re missing out on a great deal of richer information that, for just a few extra minutes per day, you could easily be collecting. This is information that the team can use during the iteration to help spot and fix problems that are holding them back.

If you’re using scrum, you’re probably familiar with using a Release Burndown chart to track the team’s progress, iteration by iteration, towards a bigger goal:

Here we can see the team’s velocity appears to be slowing down. They might still release at the end of Sprint #9, but there’s a chance, if the flattening trend in their velocity continues to worsen, that they may never finish the project at all.

We have enough information here to know that something may be wrong. We can use this information to warn stakeholders that our release date may be at risk of slipping, and may also start looking though the backlog of stories for things we can drop.

The problem with these responses is that they’re purely reactive. Assuming there is a systemic cause at the root of this slow-down, we’re not doing anything to deal with it and get the team back on track. We can go and ask the team what they think might be wrong, and try to help them correct any problems they can identify. This can often work, but sometimes the team may not have the experience or perspective to be able to see what’s going wrong.

Another problem is that we’ve had to wait until the end of the iteration to get this information. For an organisation that’s used to going into the darkness of 9-month waterfall projects, getting iteration velocity figures once a fortnight can see pretty decent. An awful lot can happen inside an iteration though, and having that summed up by a single number loses a lot of important detail. Like the signal on an old short-wave radio, this is low-fidelity data.

One crucial piece of data that’s hidden within the burn-down chart is what I call the rate of discovery. The whole point of agile development is that it’s iterative: we build and ship something, get some feedback, learn from that, build and ship some more, and repeat until our stakeholders are happy with it. If we’re doing iterative (as opposed to repetitive) development, we’re going to discover new user stories as we go through the project, perhaps even as we go through the iteration. This is a good thing: it means we’re listening to our customers. We need to make sure our project plans can handle this as a matter of course.

Going back to our release burn-down, we want to separate the rate of discovery from the rate of delivery. A great way to do this is simply to flip the vertical axis of the chart, and use a Release Burn-Up instead. On here we can start tracking two lines instead of one. First we draw the number of completed stories (or story points), and then stacked on top of that, we draw the number of stories still to do. That includes any story not yet done – whether it’s in the backlog or being worked on in the next iteration.

We can add extra fidelity to this chart in two dimensions: We can collect samples more often, and we can collect details about just how done the stories are as they move from ‘not done’ into ‘done’. Let’s start by collecting more detail about how done the stories are. Imagine our task board looks like this at the end of an iteration:

One story (Story A) is done, and 8 other stories are not done. As we track these counts over time, we can draw one line on our Release Burn Up chart for each category of ‘not done’ and stack the lines:

This chart has another name, Cumulative Flow Diagram (CFD). We call it this because as stories flow from ‘not done’ to ‘done’ across the task board, we’re drawing the accumulation of that flow on the diagram. There are lots of things we can gleam from this diagram.

If we look at the example above, we can see that work is stacking up in the design stage of our process. Because our CFD chart highlights this, we can put more directed effort into relieving the bottleneck on the designers, perhaps by adding an extra analyst to the team to run ahead and do some more detailed analysis of the upcoming stories in the backlog, or by helping the designers to break the existing stories up into smaller ones that are easier to understand.

You can wait until the end of the iteration to count these numbers, but why stay ignorant? If you collect this data every day, you’ll get quick feedback about where bottlenecks are appearing in your team, and be able to try small tweaks to correct them.

Usage-Centric Design

Narrative Journey Maps

• Duncan Prefers the term Usage-Centred Design to User-Centric Design. There was a book reference here but I missed it.
• Narrative Journey Maps (NJM) are a way to model and visualise the steps a user has to follow as they try to achieve a goal.
• Each Step is decorated with:
• Comments
• Questions
• Ideas
• An Emotional Barometer is draw across the top which highlights pain-points where the user may be particularly frustrated with the process.
• NJMs are usually created from a Contextual Study where users are quietly observed trying to reach the goal.
• They are a way to record the current state of play, and a place to start thinking about how things could change.

Personas

• Alan Cooper 1985
• Based on real data: capture and use direct observations of real experience
• Group and merge those observations to form personas
• Personas have:
• Motivations
• Goals
• Frustrations
• Behaviours

It seemed that what had worked for the presenters was to focus on just one persona at a time, when it became obvious who their core user was, and work at satisfying their needs. Once they’d started to make significant inroads into this, it became clearer and more worthwhile to look for other personas.

To Read

Luke Hohman’s Innovation Games Mr Squiggle (seed drawings for workshop excercises) Consensus:

• Quaker Business Method
• Sociocracy
• Formal Consensus (CT Butler)
• “Participatory Decision Making” – Sam Kaner

“The Logical Thinking Process” – H William Dettner. A book on conflict clouds. “Round the Bend” – Neville Chute. Like Zen and The Art of Motorcycle Maintenance but English

Other Conferences

Keith Braithwaite was heading out to ‘Next Generation Testing’ and said he was really looking forward to it. He said it was quite easy to stand out from the crowd of big vendors, and that if you have something original to say you’ll likely be asked back. He also mentioned ‘Test Expo’ as being another conference in this vein.

Really interesting it taking the Cucumber message to these conferences.

Remote Pairing and Wolf-pack programming

I met several people who are making use of or would like to make use of this more. Many of them were using Ubuntu so don’t have access to iChat, and were struggling with slow VNC connections. I suggested screen + emacs/vim to a few people (not that I’ve used it myself, but I’ve heard good things). People mentioned plug-ins for eclipse, and my old favourite SubEthaEdit came up. It does feel like there’s product missing here.

Some guys did a BoF trying out a crazy contraption they had using a smalltalk environment that allowed a dozen people all edit the same code at the same time, on their own workstations. It sounded pretty amazing.

My Session

I ran a session, Robot Tournament at the conference. Despite what I had considered thorough preparation, I had some rather exciting moments when the tournament engine spluttered and needed some running repairs. Overall though the feedback I got was positive. Some observations:

• The (accidental) downtime gave people an opportunity to make build scripts and so on. I wonder whether this could be engineered deliberately another time.
• More logging and visibility of exactly what’s going on when a player runs would be useful to help participants with debugging.
• The warm-up should include calling a robot with a command-line argument so that any teething problems with reading the input can be resolved at a relaxed pace.
• A better explanation (role play?) of how the tournament works would help.
• Need to limit the number of players to 1 per team. Although it was worth experimenting with allowing more than one, there were a couple of disadvantages that seemed to outweigh the advantages:
• when people realised they could write scripts to add several robots, this really slowed down the time to run a round due to the number of permutations of matches. I guess here you could deal with this by using a league system, but for now the simplest thing seems to be to just limit the number of players.
• there is a strategy (which the winning team used) where you use a patsy player which can recognise a game against another player from the same team and throw the game, thus giving that player an advantage. By releasing several patsy players you leverage that advantage.
• I was surprised (and a bit disappointed) at how conservative most of the language choices were. I think we had 3 Ruby robots, 2 Java ones and one Haskell robot. Sadly I couldn’t get smalltalk working for the guy who wanted to use that. It seemed clear that rather than one language being particularly better than another for the problem at hand, teams who used a language they were familiar with did best.
• It was hard for people to see what was going on when they were getting their robots running. More visibility how exactly what it looks like when their program is run on the server environment would be helpful.
• Also more functionality on the UI to slice the results and look at just how your own robot had performed.
• The problem was so small that tests were hardly needed. Pivoting, changing the rules of the game half-way through the tournament might have helped here.
• I would also be interested in trying out variable-length iterations – some long ones, some short ones.
• Shipping simple solutions early was definitely a strategy that had worked for everyone.
• People enjoyed the fact that the goal – getting points – was clear, so that rather than it being about writing clean code or writing tests, it was more realistic to a business context.
• Trying a more open game where you could learn more about your opponent might be interesting
• Getting teams to swap code might also be interesting
• Doing a code show & tell wasn’t in my plan but worked really well

The session format ended up being something like this:

• 10 minutes introduction
• 25 minutes warm-up
• 30-45 minutes faffing around fixing the engine while people started to build their real robots break
• 7 x 7 = 50 minutes tournament rounds
• 25 minutes code show & tell
• 15 retrospective looking at what we’d learned and any insights

Did I mention that I like pair programming? Here are some reasons why it’s good for you and your boss.

More Trucks

The higher the truck number of your team, the more resilient it is to losing people. Pair programming spreads knowledge of the code around the whole team meaning each team member has a much more broad knowledge of the system than on a traditional team.

Free Training

Every time I pair with someone, I learn at least one new trick, be it a keyboard shortcut for my editor, a new command-prompt command, or a language idiom. This training costs nothing and builds the confidence of even the most junior team members who always have something to contribute, to say nothing of how much they will learn from sessions with their more senior colleagues.

Team Bonding

Working together in pairs breaks down barriers between people much more quickly than when they are working alone, and provides a natural environment for teams to learn to trust one another, and enjoy one another’s company. These are vital attributes that will get your team though the tough times, ensuring they can pull together when necessary.

Better Designs

Experienced programmers know that coding is much more a process of design than of mere implementation. When subjective design decisions are taken by at least two people on the team, those decisions have much more authority and are more likely to be understood and accepted by the rest of the team than if they had been taken alone. When one member of the pair has a good idea for a solution to a problem, this may stimulate an even better one from their pair. Science says so.

Less Bugs

The perpetual code review that’s done during a pairing session not only produces better designs, but it also catches a lot more defects as they are written. Pairs will tend to write more thorough automated tests, and are more likely to spot holes in logic that would otherwise have to be picked up by subsequent manual testing.

More Fun

Generally, programming in pairs makes for more a more relaxed and enjoyable atmosphere in a team. People become comfortable with their own strengths and weaknesses and are able to talk and joke about their work much more readily, since they are already used to that dialogue. This is obviously terrific for morale and staff retention.

More Focus

Pair programmers do not check their emails when they’re waiting for a script to run, disappear into their inbox for 20 minutes, then come back and have to remind themselves what on earth they were doing. When they hit a little break-point, they review what they’ve done so far and make a plan for their next steps. They stay focussed. Twitter can wait.

I’ll be running a preview of my Agile 2009 workshop ‘Debugging Pair Programming’ at Skills Matter on Monday 10th August.

If you’re on a team that’s using or trying to adopt pair programming, this is a great chance to explore and understand some of the complex reasons why this is such a difficult skill to master.

The session is free, so sign up soon to avoid disappointment: http://skillsmatter.com/event/agile-scrum/debugging-pair-programming

Estimate: an approximate calculation of quantity or degree or worth

Commitment: the act of binding yourself (intellectually or emotionally) to a course of action

• Estimates are not commitments.
• Plans based only on estimates are bad plans.
• Commitments based only on estimates are at best foolish, at worst dishonest.

Estimates are certainly a useful tool for making realistic commitments, but there are many others too that are equally, if not more, useful. Working at a sustainable pace, measuring data about past performance, and facilitating the genuine consensus of the whole team when committing are the way to make plans that can actually be achieved.

At work, we have been practising something approximating Acceptance Test Driven Development now for several months. This means that pretty much every feature of the system that a user would expect to be there, has an automated test to ensure that it really is.

It has given me a whole new perspective on the value of tests as artefacts produced by a project.

I made a pledge to myself when I started this new job in August that I would not (knowingly) check in a single line of code that wasn’t driven out by a failing test. At the time, I thought this would always mean a failing unit test, but I’m starting to see that this isn’t always necessary, or in fact even wise.

Don’t get me wrong. Unit testing is extremely important, and there’s no doubt that practising TDD helps you to write well-structured, low-defect code in an really satisfying manner. But I do feel like the extent to which TDD, at the level of unit testing alone, allows for subsequent changes to the behaviour of the code, has been oversold.

If you think you’re doing TDD, and you’re only writing unit tests, I think you’re doing it wrong.

As new requirements come in, the tensions influencing the design of the code shift. Refactoring eases these tensions, but by definition means that the design has to change. This almost certainly means that some, often significant, portion of the unit tests around that area of the code will have to change too.

I struggled with this for a long time. I had worked hard on those tests, for one thing, and was intuitively resistant to letting go of them. More than that, I knew that somewhere in there, they were testing behaviour that I wanted to preserve: if I threw them out, how would I know it still worked?

Yet those old unit tests were so coupled to the old design that I wanted to change…

In my mind, I have started to picture the tests we write to drive out a system like little strings, each one pulling at the code in a slightly different direction. The sum total of these tensions is, hopefully, the system we want right now.

While these strings are useful to make sure the code doesn’t fall loose and do something unexpected, they can sometimes mean that the code, like Gulliver in the picture above, is to restrained and inflexible to change.

The promise of writing automated tests up front is regression confidence: if every change to the system is covered by a test, then it’s impossible to accidentally reverse that change without being alerted by a failing test. Yet how often do unit tests really give us regression alerts, compared to the number of times they whinge an whine when we simply refactor the design without altering the behaviour at all? Worse still, how often do they fail to let us know when the mocks or stubs for one unit fail to accurately simulate the actual behaviour of that unit?

Enter acceptance tests.

By working at a higher level, acceptance tests give you a number of advantages over unit tests:

• You get a much larger level of coverage per test
• You get more space within which to refactor
• You will test through layers to ensure they integrate correctly
• They remain valuable even as underlying implementation technology changes

Admittedly, the larger level of coverage per test has a downside: When you get a regression failure, the signpost to the point of failure isn’t as clear. This is where unit tests come in: if you haven’t written any at all yet, you can use something like the saff squeeze to isolate the fault and cover it with a new test.

They’re also much slower to run, which can be important when you’re iterating quickly over changes to a specific part of the system.

To be clear, I’m not advocating that you stop unit testing altogether. I do feel there’s a better balance to strike, though, than forcing yourself to get 100% coverage from unit tests alone. They’re not always the most appropriate tool for the job.

To go back to the metaphor of the pulling strings, I think of acceptance tests as sturdy ropes, anchoring the system to the real world. While sometimes the little strings will need to be cut in order to facilitate a refactoring, the acceptance tests live on.

The main thing is to have the assurance that if you accidentally regress the behaviour of the system, something will let you know. As long as every change you make is driven out by some kind of automated test, be it at the system level or the unit level, I think you’re on the right track.

At XP Day 2008 I proposed an open-space session on pair programming. Specifically, I wanted to explore the reasons why programmers might not want to pair, or find it such an unpleasant experience that they’re put off doing it again.

Judging by the great number of people who turned up and stayed for the session, it’s clear I’m not the only one who is struggling with these issues, adding more weight to my suspicion that pair programming is the hardest of all the XP practices to master.

I worked with Laura Plonka to devise and run the session. Laura is researching her PhD thesis on pair programming, using video footage to analyse pair programming sessions, then running a retrospective where the pair get to debrief and share their experiences of the session.

Despite the huge contribution from everyone present, at the end of the hour, I felt as though we had only started to scratch the surface of the problems we’d identified. It seems as though too many teams, even at organisations who are ostensibly keen to embrace ‘agile values’, suffer from some toxic cocktail on this menu of dysfunction:

• an agile-zealous leadership which forces people into unwilling or poorly-chosen pairs
• a culture that, at some level, values heroics over craftsmanship, such that programmers may feel a subtle or unconscious reluctance to chose to pair on a task unless it looks utterly daunting, and there could be no shame in being seen to ‘ask for help’.
• a team that disagrees on the types of tasks that should be done as a pair
• team members who are far enough along the autistic spectrum (as Joseph Pelrine and Ben Fuchs pointed out, we have a higher proportion of these than many other professions) that they find the level of inter-personal communication required for pairing difficult or impossible.
• ‘Experts’ on the team who feel that pairing with less experienced members of the team will slow them down too much
• ‘Newbies’ on the team who are afraid to ask for help, or feel the work they’re doing is too mundane to need to be done in a pair

There were masses more issues brought up – these are just the main few that I can remember now. Hopefully more people will write up their sections on the session’s page on the XP Day wiki, or maybe comment on this blog post.

I spent the latter half of the session in a small group discussion the influence management can have on the adoption and enjoyment of pair programming. Paul Field and I enumerated the benefits that teams who embrace pair programming and create a culture where it works, can enjoy:

• Better system knowledge across the team (higher truck number)
• Skills transfer between team members (free training)
• Team bonding
• More defects found & found earlier
• Better solutions/designs
• More fun (better staff retention & morale)
• Better focus (less time wasted in email / facebook)

It’s worth holding onto this list, and thinking about it when experimenting with pair programming within your team. Not all these benefits will be immediately apparent, so it’s worth being patient and trying to figure out ways to measure them to give you feedback as to the success of your experiment.

Another great idea I heard for teams that want to try pairing but are unsure as to which tasks are appropriate: try doing every task in a pair for at least five minutes. If, after that time you both agree that it’s a waste of time to do it as a pair, you can split up.

I still feel like there’s huge amount of work to be done to collect and disseminate the patterns and anti-patterns around pair programming, but I’m glad to have at least stirred up the pot a little. Thanks to everyone who turned up and contributed so much, and thanks especially to Joseph and Ben for organising a follow-up session later in the day where we had the opportunity to drill down into those psychological barriers a little bit more. Great stuff.

I’m just back from this year’s XP Day, London. Thanks to everyone who came and packed out the room to hear Rob and I talking about our experiences evolving our team from Scrum to Kanban. The slides are here.

There’s also a great transcript of the talk here on Tom Hume’s blog. Thanks Tom!

A while back, I asked the Cucumber team for the ability to call in the steps of one scenario from another.

The canonical example of this is the ‘log in’ scenario:

Scenario: User logs in
  Given there is a User whose username is "matt"
  And I follow "log in"
  And I enter "matt" in "username"
  And I enter the User's password in "password"
  And I press "Log In"
  Then I should be logged in
  And I should see the text "Hello matt"

Phew. Now obviously I don’t want all this noise in the scenario every time I specify behaviour that requires a logged in user. I want to write something like this:

Scenario: User views their dashboard
  Given I am logged in
  And I follow the "dashboard" link
  Then I should see "This is your dashboard"

Thanks to the fabulous creativity of the Cucumber community, this is now possible. It’s also highly recommended, as it’s a great way to help you keep your step files tidy and DRY of excess duplication.

Given /I am logged in/ do
  Given "there is a User"
  Given "I follow \"log in\""
  Given "I enter \"#{User.first.username}\" in \"username\""
  Given "I enter \"#{User.first.password}\" in \"password\""
  Given "I press \"Log In\""
end

I’m doing this more and more now – writing simple ‘building block’ steps and assembling them to make steps that read nicely and make sense to the stakeholders.

Pair programming brings a great many benefits to a team that’s truly mastered it.

Those of us who are lucky enough to have experienced working on a really effective XP team know about that almost magical thing that starts to happen when the barriers between different members of the team break down, egos and code ownership are cast aside, and the team starts to evolve the codebase as one, mighty, coding machine. It’s truly a joy to be a part of, or even just to watch.

Continue Reading »