People can multitask. Of course, we can.

We can take a phone call and look for a pen while cooking pasta. We can do a few tasks at the same time without breaking a sweat.

What we can’t do while multitasking, is our best work.

We don’t dedicate 33% of our brain to the phone and 33% to the pasta. We waste the majority of our brainpower context switching, double-checking, and remembering what we were doing.

While we can multitask, it is a waste of our attention.

What’s bad in individuals is horrible in teams.

The average Scrum-style team has a sprint backlog that consists of User Stories that are vaguely related at best. It’s usually a heterogeneous list of Jira tickets that feed the hamster wheel.

User Stories in a backlog should be pieces of the same puzzle. It’s OK if two team members are assembling the head while 3 others are working on the feet. What matters is that we are solving a puzzle of a horse together. We don’t need to hold the same piece of the puzzle in our hands.

In the teams I work with, I often see multiple puzzles being mixed. Engineer 1 is working on the head of a horse. Engineer 2 is trying to find the pieces that contain the tire of a race car.

The result of these mixed puzzles is at best a part of a horse and a part of a car. That’s not how iterative software puzzling works!

Building a little bit of everything is expensive and I’m always amazed at how much we underestimate this cost.

Slow feedback

Barely started puzzles give us no value. There’s nothing we can do with them other than say “keep building”. By building small bits of different features, we never see the product grow. The increment should feel like the next version of our product, not a checklist of Jira tickets. When we demo just a REST endpoint, we prove that we did the task. We don’t show something that could trigger inspiration. While the User Story might be “done”, our increment doesn’t feel that much more useful than 2 weeks ago. So we don’t get actionable feedback. By wasting focus, we stifle progress.

Lack of team building

“Yesterday, I worked on ticket RACECAR-123” she said, while her colleague was reading his e-mail. He doesn’t care about that ticket. He is working on HORSE-456. The only way to build a great team is to build a great product together. Problem solvers bond by struggling and cracking puzzles together. That’s what makes the team. By scattering the attention over multiple backlog items, we deprive the team of that bonding. They don’t feel like they are building the same thing, because they aren’t. They are processing Jira tickets on a conveyor belt.

Wasted attention

Multitasking is wasteful. Devs have to switch context when taking up a new Story. And when reviewing code. Or when their colleagues have a question. Since every ticket is about a different problem, attention is wasted. Just like we didn’t give 33% of our brainpower to the pasta, teams waste the majority of their attention on context switching over a heterogeneous sprint backlog.

The fix is straightforward: have the entire team work on the same puzzle at the same time.

This sounds wasteful. I promise you the opposite is true. I find it hard to convince team leads and product owners to stop the scatterbrain backlogs, but when they do give it a shot, the results are almost magical. Productivity soars, teams bond and great feedback starts to come in.

I fear it’s human nature to “just add one more thing” or to “quickly also do“. The job of technical leaders is to push back against that urge and make sure the team can hold focus. We do that by having the entire team work on one puzzle at the same time. Whether that takes the form of Sprint Themes, User Stories with tasks or even Mob Programming is up to that team. It will definitely involve saying “No, not now” a lot.

One team, one puzzle.

Give it a go.