Busses and Trucks - Oh My!

As Scrum Masters we should be familiar with the ‘vanilla’ metrics used for agile teams. These measures include velocity (throughput and consistency), and burndown diagrams (progress). But these measure the ‘steady state’ of a team. We must also prepare for disruptions to our teams.

There are two measures that are often overlooked, yet provide invaluable insight to us as Sheepdogs to protect our teams.

Bus Number

The first measure is known as either bus number or truck number. This measure attempts to provide an answer to the question: How many people can you lose (for example, hit by a bus) on your team before the project is stalled or in serious life-support?

As a hypothetical example, consider a team of six members. On this team Fred is a senior developer. Fred has been the sole developer for a core architectural component. He knows this component inside and out, and he has produced only a little documentation for it. Then Fred gets hit by a bus (or truck) and goes into hospital for a month. What happens?

What typically happens is that the project grinds to a halt, or progresses at a glacial pace. Changes to Fred’s component cannot occur quickly. The rest of the team has to designate one or two members to start reading the component code to understand its structure, any patterns to be maintained, and how the component’s functionality has been implemented. Pull Requests involving this component pile up because they cannot be approved until the remaining members understand the existing code and the effect of the PR changes. The flow of the team is severely compromised.

In this example the bus number for the team is “1”. This is the symptom every effective Scrum Master should be evaluating for each team. And there are variations to consider regarding the threat suggested by bus number.

While the example with Fred is the worst case scenario, your team may not have a “key” developer like Fred. Perhaps you have achieved some dissemination of product knowledge in your team so that, say, two developers are the repositories for significant knowledge of your code. In this case your bus number would be “2”.

What should your aspiration be for the bus number on your team? You can surely see that you want number to be as high as possible. Could you achieve a “6” on a six person team? Probably not, but it should be imperative to increase a “1” to at least a “2” as soon as you identify a critical-path person on your team.

Replacement Number

But there is a second measure that I have found equally valuable. Replacement number is the number of team members who can immediately step in to take over the work that another team member was pursuing.

This measure is one that I apply to every member of my teams. Replacement number does not have the global, project-stopping scope of bus number, but the two are inter-related at differing levels of scope. Bus number is evaluated at the whole-team level. Replacement number is evaluated on each team member.

Replacement number informs a Scrum Master of when loss of any team member will introduce impediments (slowing) or blockage (stopping) of work on a single story or activity. I will introduce a simple abbreviation for replacement number as RN(k), where k is the number of team members who can immediately take over an absent member’s work.

Knowledge of replacement number is critical for every Scrum Master because of the primacy of maintaining flow of delivery. Consider the team of six again, and on this team you have a Fred. If Fred becomes unavailable, and you have no one to immediately move in to take over his work—you have an obvious RN(0) on Fred. You can think of RN(0) as analogous to an open electrical circuit: current stops flowing.

Replacement numbers of zero are severe symptoms of disruption on your flow of delivery. If you have a team in which most, or all, of the team members have replacement numbers of zero, then you have a team of siloed specialists. This is a worst case scenario. Every team member who is RN(0) could cause a slowing, or stoppage, of your flow of delivery.

If replacement number is a diagnosis, what is the therapy to overcome the threat it represents? 

Cross-pollination, wherever you can achieve it.

Work load and schedules will push back on achieving this. Skill gaps will push back. Team inertia and disinterest will push back.

But an effective Scrum Master will find a way to push forward.

And I would be remiss not to address this small elephant in the room: What is your own replacement number as the Scrum Master for your team? Is your team capable of operating without you? Does anyone on the team have the minimum knowledge to facilitate daily standups and the oh-so-important Sprint Planning session? Can you establish an “emergency plan” which divides your responsibilities across several people on your team?

I strongly recommend you step back for a few moments and estimate both your whole-team bus number, and the replacement number of each person on your team—including yourself, and your Product Owner or Business Analysts. Identify the scope of risk that you have, and begin the simplest changes you can make to increase those numbers. Then, when you lose a team member for any reason, you will be so glad you made some preparations.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.