A couple weeks ago, I was speaking at VSLive San Diego doing a talk on project management with GitHub Projects. And if you've ever seen me talk, you know that I almost always find a way to show my favorite chart about multitasking and waste from Gerald Weinberg's Quality Software Management, Vol. 1: Systems Thinking. Combine Weinberg's data with Little's Law and it starts to become really clear that it's essential to limit your work in progress (WIP) -- ideally, limit it so that you're only working on one thing at a time.
Each additional thing you're juggling eats roughly another 20% of your time. By the time you're up to five things, only a quarter of your day is going to actual work. The rest is lost to switching. I think of this as the Weinberg Penalty. (Shout out to Gerald. I think about this stuff every day.)
The discussion during my session morphed from a multitasking discussion into a discussion of team structures and dysfunctions. Fast forward to the weekend and I watched my daughter's soccer game. That soccer game made it clear how deeply weird we are in software when it comes to working in "teams".
TL;DR
- High WIP kills cycle time. Multitasking kills cycle time. Suboptimal cycle time means slower feedback, more risk, and (eventually) lower throughput.
- My advice: your team should work on one requirement at a time -- together.
- Working on one thing together isn't multitasking and doesn't trigger the Weinberg Penalty. But everyone working on their own thing eventually does.
- If your team has trouble working on one thing together, that's a symptom.
- If your team's daily scrum or daily meeting is boring and no one cares what anyone else says, that's a symptom.
- If you're on a soccer team, everyone's playing soccer. One game. One ball. One scoreboard.
- In software, if you're not able to work on one thing together, your team composition is wonky and/or your work structure is wonky.
On a Sportsball Team, This Would Be Obviously Weird
I'm not a sportsball guy. I'm a life-long computer nerd and a jazz musician. Sports was never my thing. But then I married a soccer super-fan and then my daughter got into soccer, too. So now I watch a lot of soccer. I don't understand it -- for example, WTF is "offsides" -- but now I like watching it. Frankly, I'm amazed that I'm actually using sports in a blog post.
Anyway. I was watching my daughter's game and I still had the VSLive project management session discussion about team structure going through my head.
If you're working on/with a software development team, it's not unusual to do a 'divide and conquer' style of delivery. Let's assume a team of 5 people and let's also assume you're working in iterations or sprints. For this sprint, the team has 5 requirements in front of them. It's not unusual for the team to 'assign' a requirement to each team member and tackle the work that way.
But that 1-requirement-per-person approach has a really weird side effect: you've got no interest in what anyone else is doing.
One team. Five requirements. No one cares about what anyone else is doing until you go to merge your feature branches at the end of the sprint.
Why would you even call that a team? You didn't do anything together.
If this were soccer, this would be the equivalent of simultaneously running 5 games in parallel on the same pitch. Or maybe having a team where some people are playing soccer and some people are playing baseball and some people are running cross-country races.
If that "soccer team" was playing different games, it would be OBVIOUS. It would probably look ridiculous.
It wouldn't be soccer. The team wouldn't really be a team -- they'd just be occupying the same field. They almost certainly wouldn't care about what was happening in the other games except for making sure that nobody got in their way.
When you think of it like that, it starts to sound like stuff we'd say in software development -- "yeah...don't step on my changes. I'll create a branch." (And we all know how long-lived branches tend to work out.)
Is Swarming Just Multitasking with Extra Steps?
Here's the thing about Weinberg's data, though. It's about one person juggling multiple things. The waste comes from context switching: you drop one problem, load a completely different one into your head, and pay the Weinberg Penalty every time you switch.
Now think about a team where everyone's working on the same requirement. Is that multitasking? Not in the Weinberg sense. Sure, someone might ask you a question or pull you into a quick "how should we handle xyz" discussion. But that's not a context switch. You're still thinking about the same problem. No Weinberg Penalty. It's not like switching from writing code to practicing the Lydian dominant scale in twelve keys on piano.
You'd never watch a soccer team and say "wow, they're really multitasking out there." Eleven people. Eleven different jobs. One game.
The irony of divide-and-conquer software development is that for something that ostensibly is all about keeping everybody focused, it makes THE TEAM pay the Weinberg Penalty all over the place. You're heads-down on requirement A and someone needs a code review on requirement D -- boom. Or they want to know why their branch won't merge with yours. That's a context switch. Different game. On a team that's swarming, a teammate's question is a pass. On a divide-and-conquer team, it's an interruption.
On a team that's swarming, you're not interrupting each other and you're not stepping on each other because you're aligned on the same thing. Everyone's effort is headed in the same direction.
Team WIP Is Still WIP
But let's say you somehow dodged the Weinberg Penalty entirely. Everybody has exactly one thing. The 1-task bar. 100% productive. Divide-and-conquer still has a second problem.
Zoom out to the team and the picture changes. The team has five things in progress. And team-level WIP is still WIP. Little's Law doesn't care whether those five items are spread across five people or juggled by one. When you have a bunch of stuff in progress at the same time, everything takes longer to finish. Your cycle time goes up. (Cycle time = the total time for an item to go from "started" to "done.")
In the divide-and-conquer sprint, all five requirements are "in progress" for basically the whole sprint and they all land at the end. (Hopefully.) If the team swarms, the first requirement gets done in a fraction of the sprint, then the next one gets done in a fraction of the sprint, and then the next one, and the next one.
I'll concede that five people on one requirement probably isn't exactly five times faster. But 5 people on a requirement is a lot faster than just one person.
The Downsides of Longer Cycle Time
And when cycle time goes up, a whole bunch of other stuff goes sideways with it.
- Feedback slows down. Nothing gets to Done until the end, so nobody gets to look at it, so you find out you built the wrong thing later rather than sooner.
- Risk goes up. Five 80%-finished requirements are a lot riskier than four finished ones. Half-finished things deliver exactly zero value.
- Throughput suffers. Everybody's busy all day long and somehow not much actually ships. Then the end of the sprint becomes a merge-and-integrate fire drill.
- Less frequent 'customer delight'. This one is a little bit of a people-skills-intangible. Your customers and stakeholders (whatever you call them) like to have their dreams come true. They like presents. They like getting their features and bug fixes done. Divide-and-conquer tends to mean you deliver big batches of stuff less frequently -- aka. bigger gifts, less often. Swarming means smaller gifts, more often. Getting gifts (done, working features and fixes) more often tends to mean happier customers. And happier customers and stakeholders tend to trust you more and are easier to work with.
"That Would Never Work Here"
Back in the San Diego session, when I suggested that teams should work on one requirement at a time, together, the room did not universally agree.
I got a decent amount of pushback. Not the hostile kind -- the honest kind. People were basically saying "that sounds great, but you haven't met my team. Our requirements don't work that way."
The reasons boiled down to two things:
- Our requirements are too small. There's not enough work in one item to keep everybody busy.
- We have too many people. You can't put eight or ten developers on one requirement. They'd be tripping over each other.
And you know what? They weren't wrong. They were probably dead-on accurate. Those things are probably EXACTLY what's going on on their teams.
But that also doesn't mean that their team structure and requirement structure is correct or ideal.
Maybe the Team Is Too Big
If your team can't work on one thing at a time, it's probably not a team. Or at least it's not the right combination of people. It's worth asking the question about whether the team as currently constituted actually makes sense. Maybe it made sense before and then covid happened and it kinda drifted.
Notice something about that first objection: "there's not enough work to keep everybody busy." I wrote about that exact sentence in The Scaling Trap. When the work is pulling you forward, nobody asks how to keep people busy. You only hear it when the team is bigger than the work.
The second objection has math behind it, too. Five people have 10 communication channels between them. Ten people have 45. So when someone says "you can't put ten developers on one requirement, they'd trip over each other," they're right. But the problem might not be the requirement. It might be the ten.
To be fair to my San Diego crowd, though, "too many people" isn't the only possible answer. Sometimes "our requirements are too small" really means the backlog has been sliced for individuals instead of for a team. Every item is sized so one person can grab it and go. That's divide-and-conquer baked right into the backlog. If that's what's happening, you might not need a smaller team. You might need to slice work at a size the whole team can swarm on.
Either way, if the work can't absorb the people, you don't really have one team. You've got a bunch of people who happen to share a manager, a board, and a recurring calendar invite.
And there's a dead giveaway for this. Go to your team's daily scrum and watch what people do while everyone else is talking.
Are they listening? Or are they staring at their phone, waiting for their turn, and then zoning back out the second they're done?
If nobody gives a femto-toot about anybody else's update, it's a symptom. Your daily scrum is boring and maybe even pointless. People checking out and/or barely paying attention is EXACTLY what you'd expect to happen. Nothing is relevant to anyone else on the team except for the (eventual) integration work.
Yah. It's not great. (But you can fix it.)
From Five Games to Five Sports
Divide-and-conquer is the five-games-on-one-pitch version of the problem. Everybody's still playing soccer. They're just not playing it together.
But when a team gets big enough -- or gets handed enough unrelated work -- it turns into the other version. You've got eight people on "the team." A couple of them are playing soccer, one is playing baseball, some dude's playing cricket (because why not), there's some hockey, and then rounding it all out, one person is off doing cross-country running.
Swell. 🤦♂️
I'm not sure what that is but -- well -- that's not a team, bro.
Invisible: It's Part of the Software Culture
If you walked onto a field and saw one guy in shin guards, one in a batting helmet, and one on ice skates, you wouldn't call that a team. You'd call that obviously wrong.
But in software, nobody sees it. Why not? It's just kinda the way we tend to work.
You can't see the field. On a soccer pitch, the work is the game and it's clearly visible. It's the whole point. Software's thought work and it happens inside people's heads and on their laptops. Nobody can look across the room and notice that three people are working on stuff that has nothing to do with each other. Negative bonus points for remote teams -- you have people in their own houses all working on separate things and that's even harder to spot.
The artifacts look like teamwork. Everybody's on the same board. Same standup. Same Slack channel. Same manager. Like bear scat in the woods, it's evidence of a bear team. A board with eight cards in progress looks like something is happening and it's all on the same board so it MUST be related. Right?
The org chart is the only picture anyone draws. When leadership asks "what are our teams?" the answer comes from the org chart. So "team" quietly ends up meaning "people who report to the same person." The team now becomes more like a box on an org chart rather than anything related to actual software delivery. That's an administrative definition that governs HR stuff and compensation concerns.
And once something has a name and a box, nobody thinks about it again because everyone is busy doing their work.
Positions, Not Sports
At this point somebody always says "but Ben, we have specialists. Our backend dev and our tester and our UI person don't do the same work."
Right. And I'm informed by people who know about sportsballs that there are these things called positions on a soccer team.
A goalie and a striker do completely different jobs. They need different skills. They spend most of the game in different parts of the field. But they're playing the same game, watching the same ball, and they're both on the hook for the same score.
"Everyone works on the same requirement" doesn't mean "everyone does the same work." Your backend dev and your tester are a defender and a midfielder...or something clever and sportsbally...I dunno. I'm hitting the extreme outside limits of my sports knowledge.
The problem isn't having different positions on the team -- it's when the "team" isn't really playing the same game.
And once you think of it that way, a couple of other things click into place:
- Passing. Soccer only works because players pass to each other constantly. On a divide-and-conquer team, collaboration is an interruption. On a real team, collaboration is how the game gets played.
- The scoreboard. A soccer team has one score. A team playing five different games can't have one, so you end up measuring individuals -- and then everybody optimizes their own game. The team's throughput is the goals, not how many passes each person made.
Summary
If your team can't work on one requirement at a time, don't start by blaming the practice. Start by asking whether you've actually got a team. Maybe everybody's playing the same sport but in five separate games. Maybe it's five different sports entirely. Or maybe five different coaches are handing your team five different sports. I wrote about that flavor in You Think You Have 5 Backlogs. You Have 1 Team with 5 Bosses.
Either way, if people tune out at standup, if the in-progress column is a grab bag, if nobody needs anybody else to get their work done, you don't really have a team. You've got a box on an org chart.
The good news is that it's fixable.
I hope this helps.
-Ben
-- Is your team playing five different sports? Want help figuring out what your teams should actually look like? Need a hand with Scrum, GitHub Projects, or flow metrics? We can help. Drop us a line at info@benday.com.
