Pairing
I was thinking about a discussion we had recently on our project at ThoughtWorks about how often our pairs rotate. We’re coming close to the last few iterations of our first release, and we’re reluctant to shift focus away from delivery. As a result, we’ve started switching pairs approximately once a day, less often than some would like.
The advantage of switching pairs more often being:
1. Spreads knowledge
2. Aids an emergent and coherent design
3. Ubiquitous language within the domain is honed quicker, and the model solidifies quicker (i.e. more people share the same world view sooner).
4. I find moving around far more invigorating, and contributes to the idea of an energised workplace.
5. Shared knowledge and shared code ownership – empowering people to share changes, rather than code being ‘owned’ by individual developers.
At present, we feel like there’s too much context to our stories, making swapping pairs frequently ineffective due to the cost of change – the cost of bringing the new person in the pair up to speed with current progress.
Our Iteration Manager made the point that if a few things were different, that would reduce the cost of context switching, and ultimately make it easier to switch pairs.
1. Smaller scoped/more vertically focused stories would mean the amount of context pairs have to absorb as part of their work would be reduced.
2. More frequent check-ins would enable pairs to move more easily, avoiding the need for pairs to stick together through merge hell where context can be important.
3. Smaller more focused groups would mean that people wouldn’t have to make large context switches. They could stay focused within functional areas, but switch frequently within to spread knowledge.
To me, this has a lot of similarities to the way Toyota (and other lean manufacturing followers) have approached the problem. Instead of attempting to get the greatest efficiency from a single manufacturing process, they instead seek to minimise the cost of change to their process. So, as their teams find new ways to organise and improve, they can do so quickly and efficiently. As new products come along, factories can re-tool faster than competitors.
In the XP world, with a high cost of change pair rotation is discouraged and consequently, problems strike with code coherency, ubiquitous language fragmentation, code duplication, and inconsistent design.
However, it goes beyond pairing. One of the most important things (to my mind) I’ve spotted with hindsight is how important refactoring (which is all about reducing the cost of change, right?) is to estimating and planning.
Estimating
To me, the success of estimation within extreme programming (since that’s where the majority of my experience lies) relies hugely on the cost of change being as small as possible.
For instance, during the planning game developers estimate work based on high-level story requirements. Their estimates are based on past experience, gut feel, expert opinion and discussion. However, this is often done under the assumption that the existing code base is sufficient to allow a developer to work as they would want.
I’m sure everybody can think of examples where their stories which touched certain classes, or areas of the system, would be blown because of complexities within those areas (read: God Class). Or, those areas were not well maintained and the code wasn’t well factored, so to even get to a position where you could add value would involve some serious refactoring bordering on redesign.
To me, it is this which demonstrates the real ‘business benefit’ of refactoring (if it’s not been acknowledged as a primary principle of ‘professional’ software development) – it puts me in a better position to deal with tomorrow’s stories.
In short, without having well factored code, how can any individual developer feel like they can offer a decent estimate of the work without having had direct and recent involvement with the code? And even if they have, they may be in no better position anyway! In the past I’ve definitely had to introduce a risk multiplier to my estimates in the planning game when considering stories that touch ‘untouchable’ areas of the codebase.
Without refactoring, decent estimating becomes difficult (and more variable), making planning more difficult. And the cost of change at introducing new functionality, or changing design becomes that much greater, going against one of the key value propositions of lean approaches.
So, think about how you can reduce the cost of change as you develop, so you can change what you do when you need to – which is what agile and lean (to me, as a developer, is all about – making my working life more enjoyable through empowering me to change what I can).
I’m sure there’s more, but those are just the ones that sprung to my mind this afternoon.