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:

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?
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
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.For stories of 10 successful companies of various sizes implementing Shape Up, check out the Shapers & Builders episode.
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
Scope? Perhaps we should talk about thoroughness instead. by
Step back & think about which system you're optimizing by
. One of the authors of the Agile manifesto who also publishes on Substack!Yes, Or... by
. A great list of examples for when common wisdom fails.
I think this sounds really good, but I doubt moving away from sprints would work well in most organizations. Smaller startups, sure, but rarely in established companies. The biggest hurdle, in my opinion is that lack of certainty from those running the business. Business people think they need estimates and certainty. They want to know what is going to be done and when, thus, knowing what work is going to be done in two weeks. If the people who run the organization can trust their development team, then maybe, but if the trust isnāt there, I really donāt see how they would move away from sprintsā¦
Having said all that, thank you for this write up and some suggested approaches!
I like that approach much more than sprints and waterfall, but of course the best approach would be based on your company's needs.
I am working in a huge corporation and we (devs) are giving feedback for improvement of the work process, a lot of teams started a transitioning from waterfall to sprints because of that, but I believe that the shape up would be the best approach and our team has been doing it without even realising we are doing that, thanks for sharing your thoughts, I'll do more research about the approach for sure and suggest to the people above me implementing it.