Why We Should Probably Stop Sprinting
A cautionary tale of deadlines, rushing and burnout.
We’ve had sprints in software development for a while now.
They’re seen in a lot of Agile frameworks, primarily in Scrum, but also now in a lot of bastardised approaches like “hybrid” (essentially waterfall but development, and development only, is done in sprints for some totally nonsensical reason) and other frameworks too.
The idea of a “sprint” is that it is short in time and has a clear goal. Just like the 100m, 200m and 400m (if you’re especially masochistic) sprints in track and field athletics. You go flat out, give everything you can and then finish, with your time recorded on the scorecard.
In software sprints, you pick a goal, choose some items from the backlog and get to work, reviewing your progress after (typically) two weeks and seeing if you’ve met the goal. Then, you choose another goal, some more tickets, and start again.
I see very, very few similarities between the two.
Firstly, sprints by their very nature are a 100% flat out effort.
Sure, you don’t go off at max pace straight out of the blocks on a 400m or you’d start flagging by the time you get to the home straight, but it is a flat out effort for that distance. So whether it’s 400m or two weeks, it’s a maximum effort, get as much done as possible, all you can code buffet.
I’d argue that’s counterproductive.
We know that relaxed people do better work, so I’m not a huge fan of pushing people to the limit, squeezing in extra tasks because “it’ll be a quick change” or trying to increase velocity week after week. It doesn’t work.
Secondly, sprints finish, and that’s it!
Once you cross the finish line, that’s you done. You don’t have to get up and go again and you definitely don’t get told once you cross the finish line that, actually, the race has been extended by 50m.
In software teams, the work rarely ever stops. Sure, there might be a push to a go live date or some other big milestone, but 99% of the time the sprint planning happens on a set cadence and the whole process starts over again.
Sprint, then sprint, then sprint, then sprint… 🏃
Okay, so you get the point. Sprints aren’t repeatable but in software we are sprinting all the time. So what?
I’m not being pedantic about a name.
I’m taking a shot at the mentality that goes around sprints:
- “it’ll be a quick change”
- “can we squeeze this in?”
- “we really need it”
- “we have to up the pace, management are unhappy”
It’s not healthy.
The point I’m having a crack at making here is that we’d do well to move from a “sprint” mindset to more of that of an approach of running a “lap” of a longer distance race, say a 10k 👟.
A goal is still in mind, of course, but it takes focus off of constant sprint goals and moves focus more towards the overarching product goal, which is a nice side effect of this type of thinking.
Don’t get me wrong, you are not going to get your higher ups to agree to change the name of this time period from “sprint” to “lap”, but if you can try and get that longer distance mindset in, it’ll help your team and you’ll probably build better software while you’re at it 👌.
— — — — — — — — — — — — — — — — — — — — — — — — — — — —
I’m a Product Manager in the UK who talks about trying to build things that people love to use 🚀. I currently look after a mobile application with over 150k users and write about product management and agile stuff 🔥.
You can find more of my writing here.
