Kent Beck has an excellent idea in his book ‘Extreme Programming Explained’ about how an XP team should play to win rather than playing not to lose.

I think most of us have seen those football matches where the underdog takes the lead in the first half and shocks everyone, only to lose in the 2nd half. In the first half they went all out, but the pressure of maintaining that winning position then compromises their 2nd half.

Imagine someone on the team has spotted a refactoring opportunity that will save the team time in the long run, but if you choose to do the refactor, you won’t meet this sprints forecast.

Sadly, in the above situation, too many teams avoid the refactor for the sake of meeting forecasts (don’t call them commitments - the only promises in software development are the asynchronous kind). The team is too afraid to look bad or have to break the bad news to managers/clients, so lives with the technical debt for the rest of the project but at least meets this sprints forecast.

A team playing to win would do the refactor and take responsibility for it. Taking responsibility, in this case, would be admitting to the parties involved that they will not be meeting their forecast this sprint. In some environments, this might annoy people and said people might start frequently asking ‘why why why’ and that the team needs to get its act together.

As an individual, which team would you rather work in? One where you have to implement shortcuts/hacks or do overtime to ’not lose’ or one where you can genuinely do the best work you can. When we make these kinds of tradeoffs, we always take into account the time making a change is going to make, but we don’t think about the human aspects of it at all. A team that never has enough time to refactor is going to be a team of de-motivated developers ticking off tasks with little improvement. That can cost lots of time.

Next time your team has to decide on something like this, ask (publicly, or if that isn’t very safe - yourself) - are we playing to win?