Scrum is a popular process to develop and deliver digital products. The most common form of scrum is an endless string of subsequent sprints, a draining drudge without room for long-term investments like continuous research. It doesn’t have to be that way. Scrum can give energy instead of taking it.
Let me start with an example:
Usain Bolt is an incredible runner. Seeing him on the 100-meter sprint is comparable to seeing Superman fly. He makes it look easy, almost effortless. If we’d make him run a marathon, he would slash the world record in half! Just keep sprinting, Usain!
Imagine we’d propose that to Mr. Bolt; the reigning world champion would most likely answer: “that’s stupid and dangerous, you will die if you keep sprinting”.
In hindsight this is a logical conclusion.
Why is it that most companies are doing endless sprints?
In this article, I’ll list the reasons why back-to-back sprints are a bad idea, and which three solutions you can try to alleviate the problems.
You will die if you keep sprinting
— Imaginary Usain Bolt, September 2024
1. Endless sprints kill you
A popular form of product-development is agile development and the most popular method is scrum. All companies I work with use scrum in one way or another; either following the rules strictly, loosely, or with a complicated framework like SAFe (shudder).
For all the varieties of scrum I’ve experienced, a basic tenet is that the end of one sprint marks the beginning of another. Endless sprints.
Endless sprints lead to several interconnected problems: demotivation in the team, lapses in quality, detachment from ‘the business’, and unrealistic estimates.
Do you recognize any of these problems in your company?
(let’s do a mini-poll in Medium: highlight or comment on the issues you have)
1.1 Unrealistic estimates
- Stories are difficult to estimate: the requirements and acceptance criteria are not clear enough
- Ironically, teams complain that requirements and acceptance criteria are too well defined and they cannot use their creativity to create the best solution due to this lack of flexibility
- Teams overestimate due to uncertainty. Which leads to stakeholders finding shortcuts, like removing heavily debated requirements
1.2 Distance with the rest of the business
- Business stakeholders find it hard to get stories ‘into development’, it takes a long time to develop features, and the end-result is not what they expected. It’s unclear what to specify
- Stakeholders over-ask because it takes a long time before it’s ‘my turn again’ — worsening the problem for others
- There is a gap between ‘research’ and ‘development’. Researchers have trouble communicating their findings, while the development team feels they are flying blind without knowing the user needs. Developers have no time to join in on research sessions such as usability tests
1.3 Demotivation
- Tasks spill over from one sprint to another: creating zombie-tickets that follow the team for many sprints
- Teams stop celebrating important milestones because they are always working on the next thing
- Developers find it difficult to get user-stories into the sprint for important issues like architecture updates, unit-testing, refactoring, improving existing features, or simply ‘time to think’ — because of the apparent focus on ‘shiny new thing’ from ‘the business’
- Scrum-team members talk about ‘the grind’ when describing their work 😿
1.4 Lapses in quality
- Releasing features with bugs left unfixed (“we will fix those next sprint”) because of overrunning expectations and end-of-sprint pressure. This leads to rework, aka the-haunting-of-work-of-sprints-past
- Once done, it’s difficult to iterate on a feature to incorporate learnings and get the best impact for end-users as the backlog is filled with next-things
- Learnings during the sprint are hard to incorporate as developers work on stories (and designs) created months prior
1.5 Procedural arguments and pointing blame
The problems above lead to procedural arguments and pointing blame. The stories are not small enough, or too small, need more refinement, designs shouldn’t change during a sprint, we need to be more adaptive to change, not enough communication, too many meetings, the ‘business’ doesn’t understand, etcetera.
This can be solved, but first another problem.
2. Some things can’t be rushed (like continuous research)
Besides the destructive nature of back-to-back sprints, there is another important truth to address: not all activities fit in scrum.
Scrum needs neatly estimated stories. But that requirement can’t be met for open-ended questions in research, design, and IT-architecture. The type of questions that need alignment, ‘nights of sleep’, long-term thinking and flexible experimentation. Scrum was not made for that. Sure, we can force these activities into the scrum-process with time-boxed spikes, or by dragging along stories for several sprints, but it rarely really works.
In some companies, the solution to this is doing this type of work outside the development sprints, in a non-scrum process or in parallel sprints of the same cadence. This creates silos and distance in the organization, even though the power of scrum lies in multidisciplinary teams.
We can solve all of this, but first we need one more building block before I introduce my solutions.
3. Fulltime scrum is a lie
A “three week sprint with 8 FTE” sounds very impressive, and it is: that’s 320 hours of raw development power!
Or is it?
No. Of course not. No one is working on user-stories 40 hours per week every sprint.
People need holidays. They do trainings. Go to conferences. Attend company meetings. Do the scrum-rituals (standup, refinement, retro). Bring their sick cat to the vet. Go to the dentist. Have meetings. Read research reports (just kidding). Take hours to answer ‘quick questions’ in Slack. Have more meetings. And (gasp!) drink coffee and talk about the weather with their colleagues.
None of these things are inherently bad or evil. Most of the things mentioned contribute to a good work-environment. We’re not robots. Not yet.
Scrum promises us sprint-weeks look like this:
But our in reality, weeks look more like this:
That’s an optimistic simplification: I bet you have more than two meetings per day!
It gets worse. There is no focus if we keep getting interrupted. Our focus-flow is busted by each interruption and subsequent context-switching. On average, a person needs up to 15 minutes recovery from an interruption to get back into a concentrated flow. Four 30-minute meetings add another hour of lost focus!
On top of that, interruptions reduce the possibility for collaboration. How can we work together, if you are in meetings half the day, and I’m in meeting the other half of the day.
If we plot team-member agendas on top of each other, we see there’s only limited time to work together on tickets:
That looks horrible. But solutions are coming, I promise!
Quick recap of the hole we’ve been digging
Scrum promises focus, responsibility, continuous improvement, and collaboration. Instead we get:
- no collaboration between those ‘in the scrum teams’ and those ‘outside’
- no focus because of non-scrum interruptions
- no collaboration within the team because team-members have different interruptions
- activities unsuitable for scrum (e.g. as continuous research) is either not done, done in a silo or forced into ‘user story’-format
- no continuous improvement as the grind makes it difficult to take a broader view
- disillusionment and dread from endless-sprints
Enough negativity, let’s crawl out of this hole!
Alternatives to endless scrum
Yes, I’m reusing the title of this article as a subheading. That is allowed as a writer. Let’s look at three alternatives to endless scrum.
First, a quick introduction of myself. I’m not a scrum-hater. Before I worked as an awesome-strategic-product-designer-currently-available-as-freelancer-contact-me-on-linkedin, I was scrum master on a couple of projects. I have seen the method work.
When scrum works, it can be magical. A multi-functional team with equal members. Full alignment. Full-throttle building. Seeing the product come to life in front of your eyes. Tears of joy streaming down your face as your trust in humanity is restored. Okay, maybe not that last one, but trust me that scrum can work and can even be (gasp) fun.
How do we get there?
Alternative 1: scrum-days
Nowhere in the scrum-manuals does it say that scrum is a full-time activity. The rituals of the process bring a lot of overhead, so it makes sense in theory to go all-in, every day. In practice it brings the aforementioned problems.
Instead we can separate the week in ‘scrum days’ and ‘non scrum days’. Each team-member is ‘in scrum’ for a limited amount of time per week: two or three days.
Three days of scrum per week may sound unworkably low compared to the five days you are used to, but hear me out.
What do ‘scrum days’ look like?
During the ‘scrum days’, there is a strict ‘scrum only’ policy for people who are ‘in scrum’. People outside the team are not allowed to disturb them with meetings or quick questions, people in the team don’t plan any non-scrum-activities.
That is harsh. But the benefits are overwhelming. Because of the lack of ‘outside disturbance’ the scrum-teamers get three days of concentrated, full-focus work on their stories. No distractions, no context-switching, full-time togetherness of the scrum-team. You get a dedicated, cohesive, multifunctional team during those days.
The rest of the company will need to get used to the information- and meeting-lockdown during the ‘scrum days’. But, paradoxically, they get to work more intensively with the scrum-team during the ‘non scrum days’.
The ‘non scrum days’
‘Non scrum days’ are what regular people would call ‘normal days’. Days spent in meetings, quick calls, 1:1s, trainings, knowledge-sharing sessions, collaborate in user research, go to conferences, take time for team-bonding, etcetera.
And now scrum-team members can reap the benefits of these days as well. They can have ample time to do long meetings with deep thinking, and intense but fruitful workshops — without end-of-sprint pressure looming over them.
Researchers can work together with developers. Testers can spend time on improving their automations. Designers can work on long-term deep-dives. Architects can fill up whiteboards and discuss with stakeholders.
Scrum days give teams more time to work on stories, and more time to work on other stuff.
Scrum days in practice
The descriptions of ‘scrum days’ may sound overly optimistic.
Let’s do an example. Look at happens to our previous calendar when we introduce ‘scrum days’:
I only moved stuff around. I did not remove any meetings, didn’t shorten them, all I did was organize the scrum-days. The observant reader will remark that ‘solo work on tickets’ is gone. This has in its entirety been overtaken by collaboration with the team.
If we account for the context-switching, the new ‘scrum days’ have more than 95% of the previous time-spent-on-tickets. Five days of work squeezed into three days. That’s in this theoretical example with a maximum of two meetings per day. The benefits in reality are much larger (are there days when you have less than two meetings?)
When I worked as a scrum-master, this is how we operated. Developers and testers worked three days per week ‘in scrum’, designers, researchers, and product-owner two days per week. I was a strict scrum-master and did not allow any other work than stories, I even physically separated the team from the rest of the organization by working in a different location.
We had a blast. During the scrum-days, designers worked together with developers on the details. Outside the scrum-days developers worked with designers on the larger picture and helped in research. The product-owner was always available to make instant-decisions during scrum-days, and he had ample time to align with the rest of the organization during non-scrum-days.
There was team-cohesion and tremendous speed.
We moved mountains. Scrum days work.
Alternative 2: scrum holidays
Even when working with no-scrum-days, teams get exhausted from the constant barrage of intense work pressure.
Simply put: no-scrum-days keep teams healthy, but you need a bigger battery-boost to bring out the best.
I introduce to you the scrum-holiday: a week-off from scrum every two or three sprints. Sounds crazy. Crazier even than no-scrum-days. But it works.
Why? Well, scrum works best when teams are fully focused on their tasks and put in their best work. A two-week (or three-week) sprint can deliver massive amounts of product when that happens. Those are the examples the scrum-enthusiasts talk about! But it requires a team that is full of energy and enthusiasm. Not a team beaten down by sprint-after-sprint-after-sprint.
During a scrum-holiday your team can focus on clearing technical debt, investigate the root cause of problems or user research.
Back when I worked as a scrum-master, we’d work in batches of two-sprints. Each sprint had a specific sprint goal that we set together as a team: a big feature or ‘epic’, or another commonality between the stories (e.g. a ‘bug hunt and fix’, ‘accessibility push’). Finishing that goal became a healthy obsession. Pushing people to stretch their limits (within working hours, of course, no unhealthy overtime allowed by this scrum master) — and a joyous feeling of victory when we made it. If we made our ambitious targets, I celebrated those victories with food and drinks at the sprint review.
That team delivered. We finished a complicated project in five sprints, with six people. The type of project that would normally take at least a year.
You simply cannot do that with back-to-back sprints.
Taking breaks increases productivity.
(Insert callback to Frederick Winslow Taylor, who proved this in the early 20th century)
Alternative 3: Thinking more flexibly 🙈
At the beginning of this book article I mentioned scrum is a form of agile working. It’s not the only form.
There’s Kanban, Shape-up (by Basecamp), Lean, Crystal, feature-driven, Dynamic Systems Development Method, and countless others.
Or you can roll-your-own type of process instead of following a prescripted method. Adapt to the team and the needs in your context. Try out new things, keep what works, throw out what doesn’t (it might help to read articles about Demming).
The original agile manifesto was written by four consultants on a ski-trip, as a summary of the similarities between the different processesthey took. The manifesto celebrates diversity in approach and flexibility, not trusting in a pre-baked framework:
we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Each company operates in a different context, each team within the company has different needs and strengths. No pre-built method will be a perfect fit, and there’s not one method that fits all teams equally.
True agility means learning, understanding, experimenting and subsequently adapting your process (and strategy, and product, and…).
Conclusion
Scrum can be fun and energizing. Sadly, that’s not how it’s implemented in most companies.
I introduced three simple steps to free yourself from the droning-on of endless-sprints:
- introduce scrum-days: bring back focus to the team and expand collaboration with those outside the team
- introduce a scrum-holiday to recharge teams and make scrum pack a powerful punch again
- be more flexible in your approach to work, instead of stoically following a predefined process. Learn from other methods, try stuff out.
One last reminder: any change you introduce takes time to come into effect and introduces a bit of noise. There is a learning curve. Don’t stop an experiment after a mere two weeks of trying, and don’t introduce too much change at once.
Good luck, and have fun experimenting!
Looking forward to hear your thoughts: leave a comment, or contact me on LinkedIn
