The Importance Of Small Wins

One of the really core principles of XP is the idea of small, frequent releases. The most obvious benefit of this is that it allows users to see the product and provide feedback about what could be done to improve it. What’s not so obvious, but is part of the reasoning behind a number of XP principles, is that the developers benefit from this just as much, if not more than the users. Being couped up in an office somewhere slaving away creating software that no one’s using just isn’t fun. Getting your software out to users and having the feeling that you’ve achieved something is a big feel-good moment and it energizes the development team, allowing them to keep going full pace instead of getting tired and stressed.

This feeling of accomplishment doesn’t just come from an actual release though – even completing a story makes you feel like you’ve added value. The last few weeks I’ve experienced first hand how deflated you get without those little wins. I’ve been focussed on a big complex area that was too experimental and unknown to break down into small user stories with any real success. It really felt like a death-march – I had no idea how much further I had to go before I finished and as each day passed I felt more and more like I wasn’t making any progress at all. Today I suddenly reached the end, the feature was done. Although it’s overly dramatic, it reminds me of a single passage about stepping onto the summit of Everest for the first time: after weeks of looking up at the slope ahead of them, for the first time they were looking down. I’m going to have to find a way to avoid such long hauls in the future.

According to XP, what I should have done at the start was a spike to find out what the major obstacles were and find a way to break the story down into something manageable. We did in fact have the story broken down into smaller sections, but it didn’t reflect the actual work and I wound up with a pile of six or seven cards that I felt I had to work on simultaneously. Perhaps I could have been more focussed on a single story and just done what was required for it, but looking back at what was required, I don’t see that being a much more successful approach. The simplest approach that would have worked for some of the stories would have had to be rewritten to work for the later stories. I also don’t know how I could have approached a spike to identify the problems that I ran into, most of them came completely out of the blue.

In the end, I really don’t know how I’d do it differently next time, I just know that I want to do it differently because it made me feel bad. It may turn out to be the quickest way to get that particular feature done, but the fact that it made me feel bad feels like a warning sign that it’s not a sustainable pace. Perhaps next time we’ll be in a better position and be able to share the work around the team more so it doesn’t feel like a burden on one person’s shoulders. I’d certainly feel better with that if only because it didn’t make me feel like a prima donna – I’ve been so focussed on this one task that I’ve been delegating pretty much everything else to other people. Fortunately, my colleagues have been fantastic at doing what needed to be done. Thanks guys.