Always sprinting
The thought came to my mind that it really doesn’t seem hard to set records for distance running. It’s just a matter of willpower, isn’t it? I wouldn’t need much of a plan to set a new record — all I’d need to do is sprint as fast as I could, all day, every day, indefinitely.
If I feel pain, I can just push through it and keep sprinting. If I get tired, maybe I can eat something or take a short nap, but then I should get right back to sprinting. It’s clear that this is the optimum strategy, right? Time not spent sprinting is time when I could have been sprinting, so I should just avoid ever stopping or slowing down. If I can do that, those records will be mine in no time.
Anyone who knows anything about fitness knows how this will turn out. Even if I could muster that willpower, this strategy still would not make me the longest distance runner in the world. Every minute I spend sprinting inflicts damage on the muscles and tendons in my body. Ordinarily, if the body has a chance to repair that damage, then it can grow stronger and let you run faster and farther. But if I don’t give my body that rest, and I keep sprinting day after day, then the damage will endlessly continue to accumulate. If I’m lucky, I’ll just find myself getting slower and slower. But in all likelihood, I’ll suffer an injury within the first few weeks that will keep me from running altogether. Either way, I’ll be left a long way from any distance records.
Sprints in software
This isn’t a fitness blog. This whole thought exercise came from me considering sprints in software. The term “sprint” originated with scrum, and while most teams don’t follow scrum perfectly, the word has become a standard vocabulary word in software project planning. Sprints typically last one or two weeks, during which time developers have a set of goals that they try to accomplish before the end of the sprint.
The simple fact that it’s called a sprint suggests that during this period, developers should be working as hard and as quickly as possible, pushing themselves to get some ambitious tasks done under a tight deadline. When they tear through the codebase with that mindset, the code accumulates damage — what we often call “tech debt” — just like a runner’s muscles and body.1
While scrum is a very useful framework in many ways, its setup contains a single, dangerous rule that has infected organizations that use sprints as a framework: “A new Sprint starts immediately after the conclusion of the previous Sprint.”2 With this rule, software development fell into the trap of always sprinting. Software projects that sprint in this way risk encountering the same fate as our naive runner from earlier.
Can teams combat this? I believe so, but it requires a different approach. Here are the three alternatives.
Stop running
This is the simplest approach. Choose a milestone and decide that, once that milestone is reached, the product is done, the race is over, and all development of the product will cease. It’s like a runner who goes all out for her last race, knowing she’ll never need to run again and therefore doesn’t have to worry about the long-term consequences of pushing herself too hard. Likewise, the wear and tear that the code accumulates won’t matter once product development is over, because developers will never have to touch the code again.
I offer this proposal first because it is the simplest solution to the problem, but I don’t expect most teams would consider it. In practice, very few software products are ever considered “done,” and the ability of software to evolve is one of its main selling points. This approach could maybe work for simple products with very particular specifications, but for the rest of us, we should look at the other alternatives.
Run sustainably
The second proposal is essentially: slow down. Stop sprinting.
In the movie Forrest Gump, there comes a point where the protagonist decides to run, and to “just keep on going.”3 He goes on to spend years running back and forth across America, accumulating thousands of miles beneath his feet. Spectators and reporters marvel at his ability to keep running every day for years and years.
Something I noticed watching this scene recently was that throughout his journey, Forrest never looks like he’s sprinting, at least not after his first few miles. His run is always shown as a comfortable jog. Realistically, that’s the only way a person could achieve such a feat.
How might a software project look if it took a similar approach? Could developers find a sustainable pace at which to work? I believe that’s possible, but only by eliminating sprints altogether. There could still be periodic check-ins, goal-setting, and reviews, of course, but they should really use terms very different from “sprint.”
A key piece of this approach is that developers wouldn’t be under pressure to get features out as fast as possible. Instead, they would be encouraged to take the time they need to implement new features carefully, and they’d have the freedom to take time to clean up messy code as the come across it. Their goal would be to eliminate tech debt as fast as it’s introduced. If they can do that, then they have a sustainable pace of work that can last indefinitely.
In practice, I think this is a difficult equilibrium to find. It’s a decentralized model, where each developer would need to find for themself what a sustainable pace is. This is not easy. External pressure can push developers to go faster than they should; perfectionism and risk aversion can push them to go slower than they should; and it can take a long time to find out if your pace is too fast or too slow, during which time you either introduce extra tech debt or lose out on potential feature work.
Aiming for a sustainable steady pace can be a decent approach for projects with a single developer, and it could maybe even work with two or three developers if they stay on the same page and check in regularly on the pace of development. But for most teams, I expect the most practical suggestion will be my third.
Take rest periods
I first got the idea for this post when reading this article from a former PM of mine, about hitting aggressive milestones under tight deadlines. While it’s not specifically about sprints and scrum, that’s what came to mind as I read it, and by considering the shortcomings of sprints that I had encountered in the past, I was led to the metaphor in the intro. But the article does make good points in favor of sprinting as well, like how the pressure of a deadline can encourage better prioritization and creative problem solving. Is there a compromise that could let us realize these benefits without the long-term damage of always sprinting?
Well, let’s consider that there are plenty of people who sprint in running races in the real world without destroying their bodies. They simply take time to rest between each sprint, allowing their bodies to repair the damage from the last sprint before running the next one.
We could take the same approach in software. Instead of following the scrum prescription that a new sprint starts as soon as the last one ends, we could introduce rest periods into the development cycle. Developers aren’t idle during a rest period, just as the body isn’t idle when recovering from a workout. Their responsibilities simply shift to work that is important rather than urgent. Developers would use this time to focus on 1) cleaning up any shortcuts and tech debt introduced in the last few sprints, and 2) preparing for upcoming features by improving those areas of code ahead of time to be easier to work with.
The full development schedule in this proposal would therefore consist of alternating periods of sprints and rests, such as one week of rest after each two week sprint. (Teams would need to experiment to find the right amount of time for rest periods, but I think this 2:1 ratio is a good starting point). In sprints, developers would build new functionality quickly, taking compromises as necessary to meet the deadline. In rests, they would clean up these shortcuts, putting the code back into a healthy state so they won’t be slowed down by it in a later sprint.
The idea of cleanup and preparation is not novel, of course, and many teams do allocate some time to this work.4 But to shove that work into the framework of a “sprint” is to kind of miss the point. Sprints and rests require different mindsets, but the switch between them is difficult to make if they’re treated the same when planning. Without a clear division between the two, rests may be approached too much like sprints — working fast and taking shortcuts and therefore not fully repairing the code — or sprints may be approached too much like rests — not treating work with urgency and letting feature work drag on. By being explicit about which time is for sprinting and which is for resting, the team can benefit from the advantages of both.
Conclusion
In fitness, software, and really almost everything, sustainability is key. The speed of a sprint can only be sustained for so long before the damage catches up. For long term success, you don’t need to stop sprinting entirely, but you do need to make sure you’re giving yourself time to repair the damage from each sprint. By specifically allocating time for rest, teams can keep their projects healthy and ensure that they can maintain their development speed for a long time to come.
In addition to the damage inflicted on the code, there is also mental damage that individual developers take on, which can lead to burnout. But that’s more subjective, and is more about mental health and culture and good management practices. My focus here is on the more objective health of the project, which even a heartless manager couldn't fix (and would probably make worse) by firing burnt-out developers and hiring new ones.↩
Not often enough, though. In my experience, tech debt is typically an afterthought. At most maybe one week per quarter is set aside for it, and otherwise it only comes up when the damage has gotten too big to ignore. The other benefit of the third proposal here is that it builds regular time for fixing tech debt into the calendar, rather than requiring advocates to schedule time for it ad hoc.↩