Doing one thing at a time is the best way to build software
Teams should solve one problem at a time. It's a productivity multiplier that we struggle to embrace.
We've set up entire systems to squeeze the last ounce of productivity out of our developers. Roadmaps are only ambitious when they are crammed. Teams are only productive when they churn out lots of features.
We preach the gospel of more.
Yet, in this race for productivity, we often damage our product. Our ambitious roadmap turns out to be a lie. The features we cooked up in the last sprint are often untested and undocumented. Knowledge sharing is non-existent, and if you ask a developer which problem they're solving, they can only reply in Jira ticket numbers. Context switching numbs our team's brain.
We know multitasking is bad, yet we glorify it on a team level.
A team that solves one problem at a time is the best way to build software. We define a timebox where the entire team will address a single problem. There's instant knowledge sharing and developer engagement. There's zero context switching. There's room for quality assurance, team building and improvement.
Yet whenever I introduce monotasking to a team, there's always reluctance. Teams and their stakeholders push back. Let's look at the most common objections and try to answer them.
We can't all work on one ticket, right?
Of course not. While monotasking works great for proponents of mob programming, it isn't what I'm talking about. When addressing a problem, we can't guarantee to solve it completely. We can only aim to move the needle in the right direction. If we give our team two weeks to "improve the user reports", we can't expect perfect reports. We can expect better reports.
We start the timebox with a good problem definition. Which pains are our users experiencing with the current reports? Our developers then come up with solutions that move the needle. While our front-end developers might work on the UI and the design of the reports, the back-end developers might try to speed up report generation. There are an infinite amount of things we can do to improve the report experience without getting in each other's way.
It's never one ticket.
What if not all developers can contribute to the problem?
Most teams have a heterogenous skillset. Some developers excel in the back-end, and others work their magic in the front. There's the one mobile app guy and the lady who's knowledgeable about infrastructure. A lot of "keeping the team busy" consists of finding tickets that suit the team's members. "We still need to come up with a few tickets for Sally."
That's about utilization and has little to do with team productivity.
A team should own a product or component. That means it should be designed to best solve that (part of the) product's problems. While it's natural to occasionally struggle to find problem-related work for the mobile app guy, it should be the exception. For the occasional struggle, we can get creative. We could give our users in-app notifications when their report is ready. That's mobile work that leads to a better report experience. While this might sound like "making up busywork", we include the mobile dev in the team's problem-solving. That's great for growth, team building, and knowledge sharing. We underestimate how valuable that is.
But if we consistently struggle to find relevant work for certain developers, it tells us there's something wrong with the team composition. We may need to consider starting a separate team for the mobile app.
Isn't working on more problems more productive?
Stakeholders worry about productivity. Instead of having the entire team work on a single problem, wouldn't it be better if they did "more"? Surely they can take on some extra tickets?
Yes, multitasking is more productive in the sense that it produces more code. If each developer works on their own problem, the team gets to type more. But that's not what we're after. Context switching is a silent killer that stakeholders are rather unaware of. When a developer works on redesigning a report and switches to implement an analytics feature, their brain doesn't switch as fast as their git branch. It takes time to readjust to a new context and problem. So, the worst thing you can do for productivity is a report ticket, followed by an analytics ticket, followed by another report ticket. Developers often batch these report tickets to avoid the context switch. So why not take this one step further? Why not pick a timebox to only work on report tickets and avoid the context switching altogether?
That's how monotasking increases your team's productivity.
Will there be enough well-defined work when the developers start?
Managers worry about idle time. Will there be enough work for everyone? What if they run out of tickets and have to twiddle their thumbs?
Idle time feels like the opposite of productivity. If developers aren't churning out code, they're not being productive. When I was a young project manager, I dreaded idle time. But if I look back now, I can clearly see that my worry wasn't about developer productivity. Idle time reflected badly on my efficiency as a manager: it meant I wasn't doing my job! Idle time is only a problem when you need to spoonfeed developers requirements. Only when someone else needs to spell out the solution do you risk running out of spoons.
I often compare Focus Blocks to hackathons, and if you've ever attended one, you notice how nobody is twiddling their thumbs by the end of the night. There's always something to improve, test or fix.
That's how it works for your team as well. It's like a positive version of Parkinson's Law. If, at the end of the timebox, there are still a few hours left, your developers will always find something valuable to improve.
If we only can work on one thing, what happens if we get blocked?
It's the developer's equivalent of idle time. You work on a ticket, run into a question you can't ask the busy Product Owner, and get stuck.
When I was a developer, I often got blocked on tickets. I red-flagged those and picked up another one to keep busy. When the Product Owner was in-between meetings, they could unblock me. Again, looking back, I never got stuck because I didn't know what to do. I got stuck because I didn't know what they wanted me to do. When somebody tells you what to build, you depend on that person's approval. You can only make assumptions with their OK. That's why you park the ticket and incur the cost of context switching.
That's why monotasking is so much better.
At the start of the focus timebox, the entire team gets together to design the solutions that will move the needle closer to solving the problem. When developers contribute to designing the solution, nobody is spoon-feeding them scope. We unlock our best problem solvers' creativity to develop a better product.
They can unblock themselves.
The history of software development management is based on tasks, tickets, and work items. We list a bunch of steps that need to be taken, and when those are done, the product is ready.
It's an incredibly inefficient way to look at software development. Not only are we bad at predicting these tasks, but we also consistently underestimate the magic that happens between these work items. Knowledge sharing, design, team building, and documentation. We're also extremely blind to the detrimental effect context switching has on our team's productivity.
Monotasking is a much more natural way to build software. Individual developers build software one problem at a time. That's the nature of effective problem-solving.
Why not apply that to your teams?