Why sprints are taking the joy out of building software

A short rant about broken sprints and possible alternatives

To sprint is to run as fast as you can over a short distance. And what happens after you finish a sprint? You need to catch your breath and rest (maybe even vomit a little if you are out of shape).

Imagine a 100m runner doing 26 sprints, one-after-the-other, no breaks:

And then, start another one…

That’s how most software teams feel!

But sprints are agile!

<Rant>

Stop right there. Let’s break that “Sprints are at the very heart of scrum and agile methodologies” myth. Sprints ARE NOT at the heart of Agile!

Here’s the manifesto:

Source: the Agile Manifesto website.

Think about your last sprint. Do you feel those “Individuals and interactions over processes and tools” and “Responding to change over following a plan” parts worked well?

Or do you feel that everyone cared about sticking to the process above all else?

I still don’t understand the problem

Tell me if you ever heard at least one of those:

• There are only 2 days left in the sprint, so let’s take that random bug instead of the important feature from the next sprint which will take 4 days.

• Let’s give one last push to finish the sprint goals, we committed to them!

• If we finish 100% of the sprint it means we didn’t put in enough, 80-85% is a great result.

• Our sprint goal is to “make progress on feature X”!

• The PM: “We agreed to have only 15% for tech debt in each sprint, you’ll have to move this to the next one”.

• Our team has great velocity, that’s what matters. The features are late because the product didn’t define them well.

• Why the burndown chart doesn’t go down? Let’s start to release things ASAP.

Now stop for a minute. If you had to think about the ideal way to organize your team’s efforts, do you honestly think you would have gone with the current way of doing things?

Do you feel it brings the most value to your customers? Do you think your engineers truly enjoy the process, feeling they contribute from their own creativity?

But first - Exciting news alert! 🎉

---

Launching “EMpower: Hacking Engineering Management”

In a few weeks, Michał and I are going to help 50 ambitious engineering managers to:

• Stop feeling stressed and overwhelmed.

• Have more free time to do the things you want.

• Build a super high-performing team.

We know you are busy with real problems, so we ask for only 10 minutes each week, including the weekly exercise. No BS.

We limit the sign-ups to our email course because we plan to answer every single question you have, to make sure it will be tailored to your needs.

The price will be $59, if you are curious to know more click below:

Ok, back to business:

---

So what is the alternative?

Last week I had a conversation with a CTO in a very small startup. It is just him and 2 developers. When I asked how they organize the work, he said:

We release only when we feel ready, usually in cycles of 2-8 weeks. We first try to release an internal beta with the biggest uncertainty parts, and while we collect feedback we continue to polish things. Once we feel good about the quality and state of the feature, we release and move to the next one.

Hold your objections (‘We need to promise something to the customers! You can’t do that in a mature company with thousands of customers!’).

Let me tell you about Basecamp. A 24-year-old company, which generates tens of millions in profit in year. No roadmaps, no goals.

I covered a book their CEO and CTO wrote in ‘It doesn’t have to be crazy at work’.

For a quick review on their alternative to sprints, read this article:

We work in 6-week cycles. Once a cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six week cycle.

Note: These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

If that interests you, they wrote a free guide on how they operate, called ‘Shape Up’. Fried mentions in his podcast episode with

Lenny Rachitsky

that he doesn’t suggest going all-in and changing everything in the way you work - as that’ll surely fail. He suggests to start with a PoC for a single project, and see how it goes from there.

And if I can’t change the way my company works?

“Anton, this is all nice and interesting, but it’s not up to me to decide how my team works”. I feel you. That’s probably the case for 99% of you, who work in big companies, with existing habits and processes.

Still, there are many things we can do:

• Always leave some room to breathe in the sprint. I constantly fight the argument of “let’s put this in the sprint, and worst case we will move it to the next one” with “let’s not take it in the sprint, best case we can add it if we have time”.

• ‘Make progress on X’ is a stupid sprint goal. Don’t force it.

• If someone finishes their tasks, it’s ok to let them work on what they want.

• Fight for ‘quality’/’break’ sprints. A 2-3 week period where people can fix stuff. Even once a year is better than nothing.

• Think critically. Don’t accept practices you don’t believe in just because you are used to them.

  • Your team doesn’t want the daily standup meeting? Skip it!

  • Do you feel the retros are repeating themselves and do you need some time to address the issues? Skip a couple of them!

</rant>

I’m not saying everything is bad about sprints. They are called so because they are the opposite of ‘Marathons’, which were common in the waterfall methodology. You worked on software for months/years, without any interaction with customers in the middle.

I just think that the software world will be a better place if engineering managers would think for themselves and come up with systems that work for their specific context - industry, company, team.

What I enjoyed reading this week

1. Scope? Perhaps we should talk about thoroughness instead. by

   James Stanier

2. Step back & think about which system you're optimizing by

   Kent Beck
   . One of the authors of the Agile manifesto who also publishes on Substack!

3. Yes, Or... by

   John Cutler
   . A great list of examples for when common wisdom fails.