Much of the agile process literature is very general. There is a lot of focus on practices and philosophy and empowering teams (nothing wrong with that by the way), but there is also often a lack of practical advice on how to solve the day-to-day problems you run into when working in an agile environment. It is difficult, as every team encounters different problems and even similar problems often have a different root cause depending on the environment. Regardless, I can see a need for a cookbook type of text, but in the meantime I’d like to weigh on an issue that I have seen quite often with agile teams, that of pair programming and the apparent reluctance of many developers to actually swap pairs regularly.

If this kind of thing is of interest to you then remember to subscribe to my RSS feed as I often write about this sort of stuff. 

A Novice Agile Team

I don’t really want to spend too much time here as the issues in the case of novice agile teams are reasonably clear. It is likely a people or a team dynamics problem. I would look at one of two things:

  1. Did you introduce all the agile practices at once (the big bang approach)? If so, you’ve likely found your problem. It is often best to introduce practices slowly to allow everyone to acclimatize. Otherwise people start to feel adrift and try to anchor themselves somehow. The easiest way to do that (anchor yourself) is to make sure you complete the stories you start and so people avoid swapping pairs. It may be worth ignoring the lack of pair swapping and giving the team some more time to get used to the new process (focus on pair swapping a little later).
  2. If people seem comfortable with the practices then your problem is probably lack of buy-in. The team doesn’t understand the benefits of pair swapping and sees no need for it. Once again, there is a certain level of discomfort involved with pair swapping. You’re leaving a story in a half-finished state and developers don’t like to do that. You’re also potentially leaving someone you get along with really well (you current pair) for a person who is less familiar to you. Without buy-in there is nothing to counter-balance that discomfort and pair swapping suffers. Your path here is clear, you need to sell people on the benefits that pair swapping brings. Communicate with the team and explain, until you get to the point where people start to prompt each other to swap pairs. 

It is that simple when it comes to a novice agile team.

The Experienced Team

When it comes to an experienced agile team, the problems are not as easy to diagnose. The people are fully aware of the benefits and everyone is comfortable with the process and yet pair swapping is still an issue. It is likely not a people or a team dynamics problem, the culprit is elsewhere in your process. Consider the fact that your stories might be too big – it takes too long for a pair to finish a story.

In order to comfortably swap pairs a developer needs to reach a certain level of understanding regarding a story:

  • have a clear idea of the business requirements (where the current story is concerned)
  • be comfortable with how everything will be implemented from a technical perspective
  • have a good idea of how everything will look in a finished state

To get to this level of understanding you need to be involved with a story until it is approximately half-finished (based on personal experience). Otherwise you feel like you don’t really have a handle on the situation, haven’t yet made enough of a contribution and so will be reluctant to move on to something else.

One of the benefits of pair swapping is to get more people across a particular story, so it is actually beneficial to swap half way through a story. Unfortunately, not all stories are the same size even when the estimated point value is the same, so all stories reach the half-way point at different times. This is why most teams try to swap pairs at regular time intervals (i.e. half way through the day, start of every day etc.). But, if your stories take two or more days to implement, there will be a lot of reluctance to swap half way through the day. You can certainly make the swap interval longer, but then the new person needs to make up so much ground as far as context is concerned that it is almost counter-productive, they become a passenger. Not to mention the fact that when a story is long and complex you want to see it through to the end to get that satisfied, “job-well-done” feeling.

You would be better off recalibrating the point values for your estimates so that a 1-pointer becomes a lot smaller (less complex and so takes less time to implement) and consequently larger point-value stories are also smaller. I would go as far as to say that the majority of the stories should be 1-pointers with a few 2-pointers, anything bigger than that should be broken up.

If all of this is unconvincing, here are some reasons why smaller stories are better stories.

  1. They allow the team to check in more often (not as many conflicts)
  2. Smaller stories are easier to wrap your head around
  3. Go along way to preventing situations where you’re half way through multiple stories at the end of an iteration (because when you underestimate a small 1-pointer, you’re only a few hours off, when you underestimate a huge 3-pointer, you could be off by more than a day)

And of course, people will be a lot happier to swap pairs when the stories are smaller as it takes a lot less time to reach that level of understanding (that I talked about above), where a pair swap is no longer a pain.

The “Rules” For Breaking Up Functionality

I have found that people tend to write stories according to a set of pet rules, e.g.:

  • each story must be a vertical
  • each story must have tangible business value (must be tied directly to requirements)
  • you must be able to express a story in the form – “As an X I want to be able to do Y”
  • etc.

The thing to remember is that all those are guidelines. If sticking to those rules makes a story too big then break them. Don’t worry too much about business value and it is ok not to make a story a complete vertical. When you break a story up, remember that stories don’t have to be completely independent. Agile teams often try to maintain the illusion that each story is independent and the system is built up from a bunch of discrete verticals. This is never true, there are always dependencies, so if you need to, you can reorganise your task board to make these explicit, this way it becomes easier to break up stories, since you no longer have to try and make each story make sense in isolation.

The lesson here is this, if you see an issue in an experienced agile team (like the reluctance to pair swap), don’t automatically assume it is a people problem or lack of understanding. Look to other parts of your process, there may be a connection you wouldn’t expect. Do you think there are other reasons why people are often reluctant to pair swap? If so, please leave a comment, I’d love to hear them.

Image by mikebaird