I don’t like sprints.
The name doesn’t make any sense, and the execution of the idea usually is even worse. Often you end up sprinting right into a waterfall.
You shouldn’t be sprinting when trying to deliver something.
Instead, you should be prioritizing things and doing them one at a time.
What’s a sprint?
A sprint is a fixed period of time where a team tries to accomplish a goal and ship some kind of value. Both the goal and value should be variable, but in practice tend to be static.
Why is it broken?
You literally can’t sprint forever. As you move, energy is consumed. There is a finite amount of energy. It takes time to recharge this energy.
Let’s say you are a typical product-delivery team, working on 2-week sprint cycles.
You’ll meet for planning, define the object, maybe do some estimation, and maybe generate some stories/tasks. Then you’ll start the sprint.
You’ll get some work done, maybe chat with design on the UX requirements, maybe plan out some data models, maybe start stubbing out an API endpoint or two…
Then you hit a roadblock.
An assumption you made is not true. Maybe you thought implementing a specific UI requirement would be easy and it turns out not to be. Maybe an API endpoint is taking longer to develop than you anticipated. Maybe a third party is taking a long time to respond to questions about their API documentation.
Now it’s nearing the end of the sprint. You are definitely sprinting, but, you notice that you have a calendar event coming up: “Retrospective”.
And then right after that, “Sprint Planning”.
You are not sprinting. You are running a marathon. Your energy is depleted and you are already jumping into the next run.
How do we fix this?
Stop sprinting. Limit your in-progress work, stick to an obvious, prioritized list, and build in cooldown periods to recharge the batteries.
Doing sprints in the Agile-prescribed way is not sustainable. It does not unlock the potential of your team.
- Sprint planning meetings
Work on one thing at a time
It’s really hard to keep a lot of things in your head at once. With sprints, you always have an entire iteration’s worth of stuff to think about. You might create a theme or a goal, but in practice, there’s always a lot of stuff that we shove into our sprints.
Stop doing that!
- People on your team should only work on one thing at a time and they should work on it until it’s finished.
- Estimate the effort when you start working on it.
Use a single, prioritized list
You’ve probably heard of Kanban. I’m not going to prescribe it, but I’m going to prescribe a concept crucial to its implementation.
- Have one list of work that is always prioritized from top-to-bottom.
- Always start new work from the top.
- Only ever work on one thing at a time.
Take a cooldown
To my previous point, energy is finite! You need to take a break. And by a break, I mean, working on things that are not at the top of our priority.
When you finish something, take some time to work on something else.
Depending on your team, this can be an hour, a day, a week, or anywhere in between.
- When you finish something, take a break! Tackle a bug, do some professional development, pay down some debt, or work on a side project.
Is that it?
Yep! Stop sprinting. Create a prioritized list. Do one thing at a time.
But what about roadmaps? Stakeholders? Requirements? Discovery???
Maybe you should approach those with this framework in mind. 😆