Being busy is the silent killer of Scrum Team effectiveness

Stop spinning plates before they all come crashing down.

Do you experience any of these symptoms?

• Simple tasks, such as sending an email to a group of people, can take weeks.
• You need many meetings to stay in “alignment” and everyone is too busy to collaborate.
• Your day is packed with back-to-back meetings on different objectives.
• You have to schedule weeks in advance to have a one-hour meeting with someone.
• New fires or urgent tasks seem to pop up weekly or daily, and nothing in-flight stops while you fight these fights.
• Obstacles are no problem since you can simply switch to one of your other items in flight.
• You can’t always remember what you did last on a task, since you only spend a slice of time on it every week or two.
• Your team makes mistakes or repeats work when switching between too many items.
• Your team members are all working on seperate items, so it is difficult to collaborate with them if needed.

I find these situations to be more and more common these days. Being busy has become our obsession as we juggle multiple things at once. But in the midst of this frenzy, all we have to show for our efforts is exhaustion and partially done work.

Our engagement plummets in this type of environment. Purpose, mastery, and autonomy are all diluted when we attempt to keep too many plates spinning. We can’t focus; we spend more time trying to keep the plates from falling than delivering value.

Scrum Teams find attempting to gain a foothold impossible in this soup of frenetic busyness. The Scrum value of Focus does not stand a chance. And poor focus has a negative impact on our teams, our customers, and our stakeholders; nobody is happy.

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.

The 2020 Scrum Guide¹

Despite this, we keep riding the busy train. We worry if we slow down, we will miss our goals. But by staying busy, we are getting less done and delaying or outright missing our goals.

Why can we not see the problems of being busy when we are in the midst of it? Staying busy on competing priorities creates an illusion of progress. And when we are all in this illusion, it is difficult to observe what is really going on. So, we keep plodding along, spinning plates, believing we are making progress to our goals.

This post is a bit more in-depth than normal. But stay with it; let the impacts of focus dilution sink in. I will conclude by sharing some things I have seen work to counteract the chaos and how to self-assess if you are staying focused or being busy.

So, let’s slow down for a few minutes and take a look at how poor focus destroys our ability to deliver value.

How multitasking destroys value flow

Let’s take a simple example to illustrate how multitasking to stay busy thwarts your Scrum Team’s efforts to deliver value to customers and stakeholders.

Team “Star” staying busy to please all customers

Imagine a team (team “Star”) who produce a product of colored squares with a star symbol. It has five customers who have each requested a different colored star square. Assume it takes team “Star” five days to complete customer delivery of a colored star square.

The customers are eager to get their order, so each ask for status updates soon after the order request. Team “Star” wants to please its customer, so it starts each customer’s order at the same time. This allows the team to tell each customer it has started work on the requested order.

Figure 1 shows the weekly activity of team “Star” as it attempts to deliver for all customers at the same time. Each day, the team performs work for one customer. Then it switches to another customer order the next day.

Everyone on the team is busy working on customer needs. And all the customers feel satisfied their orders are in progress.

But while all hands are busy, no-one notices the work for each customer is not flowing well. Each customer star square sits and waits four days between development days.

The team delivers all customer orders in week 5 — one per day. This is a week of great celebration by team “Star” as all the hard work concludes. And the team feels pleased to have delivered valuable products to its customers.

But what happens when team “Star” focuses on completing one order before starting the next?

Team “Star” could approach delivering for its five customers in a more focused manner. Instead of starting all at once, it could focus to complete each order in the sequence received. Figure 2 illustrates this approach.

Often called one-by-one production or swarming, this focused model has instant benefits.

Swarming allows work to flow to “done” sooner for most customers. Four out of five orders complete before week 5 as team “Star” delivers a customer order each week. In fact, the first order delivers in week 1 — sixteen days faster than when multitasking all orders.

Finishing early also spreads out the dopamine rush of completion. Instead of all accomplishments pooling up at the end, they spread evenly throughout. This generates a steady stream of momentum and energy for team “Star”.

As you can see, focus is powerful and simple to put into practice with a change in perspective.

The actual difference between the two approaches is much more striking

In reality, there is a hidden productivity killer when we work on too many things at once. We call this stealthy parasite context switching. And it can have dramatic effects on the time we have available to make progress on our work.

In Quality Software Management: Systems Thinking², Gerald Weinberg outlines the wicked impacts of context switching. When we switch from one task to another, our brain has to offload the mental context for one task and load the new one. Figure 3 shows the heinous effect this has on our productivity.

This chart depicts a 20% context switch loss for every task done in parallel. Task switching also results in more errors or repeat work. For instance, I find, when I multitask, I repeat what I have already done because I forget I had already done it.

So let’s apply context switching to both approaches for team “Star.” The result is stunning.

In the first approach, five customer orders are in flight at once. According to Figure 3, this should leave only 20% of available time for working on customer orders. To be conservative, let’s assume only one day of impact for each context switch.

In the second, focused approach, only one customer order is in flight at once. The only context switch is when a new customer order starts after finishing another. We will also assume here one day of context switch loss between customer orders.

Figure 4 depicts the two approaches with context switching time included.

In the light of context-switching, the customer delivery gap widens between the two methods.

In the first approach, no orders complete until weeks 9 and 10. But in the second approach, we stay with close to a weekly delivery and finish all customer orders by week 6. In striking contrast, approach one delivers the first order two weeks after the final order delivers in approach two.

And the difference in the loss to context switching between the approaches is a conservative estimate. If we were to take Figure 3 at face value, only one day a week is available for working on a customer order in approach one. Four days per week fall in the context-switching black hole. As such, team “Star” would need a whopping twenty-five weeks to complete the orders in this case.

What could team “Star” do with all the extra time they gain in approach two? It could reduce the technical debt that never seems to get prioritized. To regain sustainable pace, the team could take a break or improve to make its job easier. If customer demand is high, it could deliver more product to fill more customer needs.

So, should we waste our customer’s time by starting everything at once like this? No, we should not. In short, focusing on less at once helps us achieve more for our customer, our company, and our team.

How can we focus on one customer need at a time?

Being deliberate to focus on finishing a single customer need before moving on is not easy. For some reason, it feels less productive. And we don’t like telling our customers they need to wait in line.

But since we now understand the flaws of multitasking, we can tell our customers a compelling story. We can explain how they will get their need solved faster if we work their needs one at a time.

Here are some quick-hit suggestions for helping you focus on less to get more done. My goal is not to provide an in-depth explanation or a step-by-step guide. Rather, I intend to give you starter ideas you can possibly apply to your context.

Try: Reduce your work-in-progress limit to one

This is the most obvious recommendation. I almost called this “slow down.” But this characterization would be misleading. Reducing the work-in-progress to finish one customer need at a time does not slow us down.

Take the team “Star” example above. I would not call approach two, “slow,” where the team completed one order before moving to the next. Customers received all orders sooner, much sooner, than when working on all needs at once.

Limiting work-in-progress helps us deliver everything earlier and more sustainably than the alternative. Nothing is slow about that.

Try: Stop fretting about prioritization

Many get stuck attempting to prioritize which thing to focus on first. I recommend you don’t worry too much about this. Any approach to order the work suffices — first-in-first-out, random, or highest impact.

I’ve often heard the statement, “Everything is high priority.” But if everything is a priority, nothing is a priority.

Let’s assume, against all logic, this statement is true. Then, your best bet for completing all items as soon as possible is to work on them one at a time. Simply pick any item and deliver it before picking another.

The key is to do one thing at a time. Focus allows you control of what gets done first. And it allows you to complete all things sooner.

Try: Break through blockers

Many also worry about what to do when the inevitable impediments or blockers arise. Most assume impediments allow a bypass of the work-in-progress limit. So they move to another customer need while they wait on blocker resolution.

But the better approach has the team swarm on the blocker instead. This avoids context switching between customer needs and resolves blockers faster.

Customer delivery flows better when we stop to fix things that impede our progress.

Try: Make simplicity a priority

When you produce extra feature polish, other needs have to wait longer to get focus.

As we focus on one customer need at a time, we should take care to solve for that need and nothing more. When we add unnecessary bells and whistles, we end up gold-plating the product.

In software product development, producing features customers never use is commonplace³. So we must work hard to avoid it.

Good enough is better than great in most circumstances. It allows your customer in focus to get its needs met sooner. And it helps other customers wait less for their product needs.

Producing something “just-in-case” strips away your focus on what matters. It ignores what your customers actually need.

Try: Remove external consent and gates

External approvals often block us from keeping a work-in-progress limit of one. When teams need to seek an external stamp of approval, they typically have to wait for that consent. Waiting leads to starting something else, and we know the bad impacts of starting many things at once.

Agile leaders must create the conditions for teams to operate with autonomy. A big part of this is eliminating unnecessary bureaucratic processes. Agile leaders must ensure the team has the ability to self-govern its decisions. Above all, they must provide a safe environment for teams to make decisions — whether they result in good or bad outcomes.

Heavy external approvals strip teams of autonomy, erode trust, and slow down decisions. And these extra processes dissolve focus. Get rid of them.

Try: Encourage teamwork not individual work

When every team member focuses on a separate customer need, you no longer have a team. Instead, you have a collection of individuals working alone. When team members have split focus, the collective might of the team vanishes.

The work-in-progress limit of one acts as a team forcing function to focus all team energy on one customer need at a time. When all team minds focus on the same thing at the same time, a multiplier effect takes place. Quality goes up and many hands and minds make for quick, light work.

You have heard the saying, “a team is greater than the sum of its parts.” Let’s put that truism to work through a single team focus.

Try: Have fewer meetings and more collaboration

The number of virtual meetings we each have in our new remote reality is a giant drain on our effectiveness. Teams having seven to eight videoconference meetings a day is not uncommon. It’s exhausting.

Many of these meetings feed the various customer needs in flight at once. If we reduce the work-in-progress limit to one, many of these meetings will evaporate.

But a good number of meetings get used to feed the status beast. I’ve noticed these often take the form of one-on-one instead of team discussions. And status meetings don’t allow for real-time collaboration on the work.

Scrum has a great mechanism to replace all those status meetings — the Sprint Review. Sprint Reviews are richer and better than any status meeting. Stakeholders get to interact with working increments, engage with the team, and provide feedback.

Moreover, every Sprint Event in Scrum provides a place for the team to focus on their work. These Events provide a rhythm for collaboration internal and external to the team. No other special meetings should be required apart from blocks of collaborative time where the team swarms on its work.

Meetings interrupt focus and drain energy. We should limit meetings to the bare essential, so teams can focus on the customer need.

How to measure if you are busy or focused

I mentioned symptoms at the start of this article that can signal you have a problem staying focused. Below are some metrics you can study as trends to measure your focus effectiveness over time:

• Number of Product Backlog Items in flight at once per team (target is one)
• Number of Sprint Goals in progress per Sprint (target is one)
• Number of Product Goals in flight at once (target is one)
• Blocker age (target is as low as possible; minutes or a few hours instead of days or longer)
• Number of meetings per week outside of Sprint Events (ideal is zero)
• Number of teams each Scrum Team member serves on (target is one)
• Number of external approvals Scrum Teams need to deliver customer needs (target is zero)
• Lead time for new customer feature delivery (a few days rather than weeks or months is the goal)
• Feature adoption % (the higher, the better; higher percentages denote less overproduction)

Play around with some of these metrics. Don’t try them all. Pick a few and see what the evidence tells you.

Taking it forward

When we have a starting culture, we stay busy. But without a focus on finishing, our ability to deliver customer value is slow and painful or nonexistent.

To solve this dilemma, we must increase our focus. We have many tools to help us dial in our attention.

• Deliver one customer need at a time, finishing what we start before we start something else.
• Pick something and deliver it; stop worrying about prioritization.
• Obliterate your blockers instead of ignoring them.
• Find the beauty in simplicity and deliver only the essential.
• Bring authority into the team to make safe decisions without external approval.
• Use the power of a team rather than individuals to swarm on one focused piece of valuable work.
• Stop the meeting madness.

Focus is a core value of a Scrum Team. As such, teams should measure how well they live up to this value and adjust behavior as needed.

Remember, time is a limited resource. We never get more of it, and we should not waste it. Let’s use it wisely for our customer, our business, and ourselves.

For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.

Related Reads

References

1. The 2020 Scrum Guide, Jeff Sutherland and Ken Schwaber, November 2020, scrumguides.org
2. Quality Software Management: Systems Thinking, Gerald Weinberg, September 1, 1991
3. The Standish Group Chaos Report, Standish Group