We need to stop calling them “Sprints” - Couch to 5k is the right analogy

Image for post
Image for post
Neukoln [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)]

Last week I spent a bit of time tweeting about my approach to software development and how teams and developers are often their own worst enemy in terms of the speed of development and the approach to development.

The idea is simple:

Start slower.

Build your base technology on which to build, and you will go faster later on.

Yes you will go slower to start with, but it is better to be slower at the start than slower later on.

While there were some criticisms of this thread, one of the things that I realised is that the word “Sprint” to do development work is really unhelpful.

“Sprints” are the most widely used term for chunking up the work for developers to do into cadences of development, and these are usually something like 2 to 4 week cadences. The idea is that at the end of a “Sprint” there is a complete product.

I never liked “Sprints”. The idea and concept is a good one, but…

I think “Sprint” is a really bad name.

I’m not the first person to think this and I won’t be the last, but the idea behind the name is that it’s about an “intensity” of work. When you sprint, you are running hard at a goal, and a “Sprint” is the same.

Not to mention that most teams that utilise “Sprints” aren’t really doing Scrum, but are using it as an approximation of what they think “Agile” means, but that’s another blog post…

With Scrum you should have a Sprint Review after every Sprint, and this should be the moment, you review and reflect and look at the backlog, and look forward to what should be in the next Sprint.

All well and good you might think.

But I think the “Sprint” focus is wrong.

And I think the “Sprint” focus is the wrong analogy.

Couch to 5k (c25k) Development

Image for post
Image for post
Couch to 5k Photo by Mike Lee

There’s this way of getting into running if you’ve never been into running before called Couch to 5k (that’s an NHS link if you’re not sure) which is hugely popular and successful.

The idea of c25k is that you don’t try running 5k on day one, but that you build up to it. Your first session is exercising for the approximate time you would run 5k in at the end —20 minutes (moving to 30 minutes eventually) — and you do a 5 minute walking warm up, then 60 seconds running, 90 seconds walking and alternate, then warm down.

And the point is this: the goal is the 5k, not the 60 seconds running.

The goal is to get to the 5k at the end.

In development, the goal isn’t to make sure we sprint well over and over again.

In development, the goal is to get to the right solution at the end.

The analogy is simple. If we keep “Sprinting” without making sure that we’re reviewing our direction and our overall strategy, then we’ll simply keep “Sprinting”.

Keeping on “Sprinting” is a recipe for burnout.

C25k is simple.

C25k is “start slowly, get the basics right, then you build up to running 5k”

In tech we should be exactly the same.

Build up your stamina

Build up your basic core skills

Build up your cadence

Build up to the end goal

The “Sprints” are not what developers are here for!

So why do I see the same mistakes over and over?

Your first iteration

The biggest mistake most developers make, and a lot of managers make as well, is that you have to start off “Sprinting”.

A lot of the arguments around this from development teams come from discussions of “time pressure” and “runway”, where those in senior management want to see results “quickly”.

I completely understand this pressure. It’s a completely valid pressure. And it’s a pressure I have felt numerous times.

However, it’s also a false pressure.

Most first iterations of projects contain significant amounts of technical debt. The number of rebuilds and core reengineering work I’ve seen in startups and internal projects after a year to 18 months is numerous. This would seem to suggest that this initial “pressure” actually does not help produce the right solution.

The start of a project is when you have the least amount of actual data, and the most amount of time.

The start of a project is when you should be finding out as much as possible about your customers with the least amount of effort.

Think of it like starting off with your 60 second runs, with 90 second walks in between — your couch to 5k.

Your cadence is completely different, and your intent is completely different. I reckon you would find a lot more out a lot faster this way though.

The biggest danger development teams have is over-promising and under-delivering, and this is what most often catches development teams and managers out.

How developers think

The hardest thing to do is to trust in a process though.

A lot of this comes down to how developers think through a problem:

Developers see a solution, and try to fix it… with code.

This is very often true when developers step out of their domain and try to talk to business people.

A developer will so often come up with “Oh that can be fixed with X software/app solution” when talking to a non-developer about something.

And that is the problem.

Because most things are a people problem, and not a tech problem.

Tech is mostly an enabler for people to do things, not the solution itself.

So when it comes to the idea of “Sprints” the problem manifests itself in a big way, because if you give a developer a simple problem, and a simple solution, they will go “head down” and fix the problem.

And if they are “head down” they often won’t consider the wider context, or more to the point, if they are continually “Sprinting” won’t have the time to consider the wider context.

And if the manager is under pressure to keep some KPI measure up (“how many cards did you get done in the last sprint?”) and not actually given the freedom to understand the business metrics, then you’ve got a recipe for disaster.

Sharpen the axe

I’ve heard several variations of this, and used my own too, but the point is an incredibly simple one:

“If I had six hours to chop down a tree, I’d spend the first four hours sharpening the axe” — Abraham Lincoln

I’ve no idea if this was Lincoln or not (quotes on the internet are always a bit iffy), but the point is valid.

The idea of continually using the “Sprint” idea over and over is to me a problem. Unless there is someone who will “sharpen the axe” at some point and regularly during the process as well, then you are destined to blunt the effectiveness of your development team.

I know that there will be advocates of “Scrum” coming on and saying “that’s not how it works” and telling me that if it’s done “right” then it works really well — I know! I’ve seen it. The problem is I’ve seen it so little, and so infrequently, that it’s pointless to make that point. I’m not talking to them, or you. I would say, change the name from “Sprint” to something else.

A great development team can be a fantastic tool.

Just make sure you sharpen them regularly, and give them the right cadence to work with.

Stop making your development teams “Sprint”. You’ll burn them out.

ServerlessDays CoFounder (Jeff), ex AWS Serverless Snr DA, experienced CTO/Interim, Startups, Entrepreneur, Techie, Geek and Christian

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store