What is your truck number?

A closer look in to team sustainability.

The organization truck number is defined as being the number of people in the organization who have unique critical domain expertise (SME). This domain expertise can be anything, such as complex legacy product knowledge or specific testing knowledge. Truck number is a measure of vulnerability of an organization. An organization with a large truck number means that the loss of any given SME would mean a critical loss that could jeopardize the team delivery. Organization with high truck number is a fragile organization with high risk of missing delivery timeline. It goes without saying the higher the truck number, the less agile you will be as an organization.

The analogy of truck number comes from the likelihood that a team can still work on delivery in the unlucky event of a team member absence, such as going on a holiday, be ill, or stepping in front of a moving truck and not come back to work the next day. A team with a low truck number means that there is enough knowledge in the organization to guarantee a sustainable team.

Unfortunately in many organizations, there are incentives to have a high truck number because we tend to give the same work to the same person over and over again because it will be dealt with faster. By doing so, you are doing 2 disservice to the organization: 1) you are taking the chance of other (new) team member to learn the product and gain experience. 2) you create more uber-specialist (SMEs) which will increase your truck number.

Characteristic of teams with high truck number

Characteristic of teams with low truck number

Testing and release period requires the same certain SMEs to be on call because only this person has the right or expertise to do the job.
High stress in the organization because the SME has too much or too little work. Tailoring the priority not based on business value but based on one or two person (SMEs) availability.
One or two SMEs in a team would be the “heros” developing much more than other team member because of the in-depth knowledge about legacy products that no other new joiners have. Similarly other junior team member will “give up” in learning new things because it might take longer. The scrum team as a whole is a weak organization.
One or two SMEs in a team are the “heros” where the stakeholder goes to get things done. Stakeholders bypass the PO and directly go to the one or two SMEs to make a request.
The answer to the question: “If person X goes for a one month holiday, would the team still be confident to deliver the sprint goal?” is team panic and despair.

Testing and release period can easily be rotated between several team member depending on availability. No bottleneck or high pressure on only certain team member.
Stakeholders go through PO as a single point of contact to prioritize stakeholders request. The PO will then ask anyone in the team who is available to get the prioritized request picked up.
There are deputies for every skill needed in the team. Team member can take a holiday with a peace of mind.

Characteristics of teams with high and low truck number

What should we do to be a healthy team/organization?

Here are some tips:

Identify the truck number in the organization by asking yourself “How many people in my team that we can absolutely cannot do without?”, “If person X goes for a one month holiday, would the team still be confident to deliver the sprint goal?”
Strive for low truck number by taking active steps in working on continuous knowledge transfer.
Build a culture of continuous shared knowledge transfer that increases the breadth of knowledge over time, particularly for knowledge that easily can be codified, taught, or otherwise conveyed.
Encourage peer programming.
Architect should also do development. Working side-by-side with the team increases the chance of knowledge sharing.
Encourage peer review where team member having less knowledge actually work on the topic and having the more experience team member review the work
Encourage development team community of practice session where team member share knowledge on what they are working on and how they solve problems.
SMEs should take the “teacher” position and not merely the “executor” of the stories in the sprint.
Do not give the same work to the same person again and again, let other team member pick up the work. They will be slower at first, but in time the other person will pick up speed.
Business and management should acknowledge that there are no fast shortcuts, knowledge sharing requires time and will make delivery slower temporarily. The benefit of team sustainability will not necessarily be short term but certainly be long term. It takes courage to do the right thing for the team and the organization.

How about your organization/team, what is your truck number?

Reference

http://www.orgpatterns.com/Organizational-Patterns-of-Agile-Software-Developm/bookoutline/thepatternlanguages/organizati…