Social Patterns: Sacrifice One Person

Sacrifice One Person 

Modern software development is mostly a team sport. Even with AI tools becoming more and more common, most companies organise their product development into teams that own specific parts of bigger software assets. And these teams can then have different ways of working and agreements. Social patterns (how to organise humans and handle communications) is not a new field of study.

I originally found these patterns from the book Organizational Patterns of Agile Software
Development by James O. Coplien and Neil Harrison. It was written in 1995, so exactly 30 years this year. 

Sacrifice One Person is a social pattern where one person from the team takes care of any small distractions that come to the team. This is something that probably many teams in different organisations have tried. I'll give a description of how that is done in the company I'm working in. 

Implementation 

The role is called Investigator and shifts are one week long. All team members are part of the rotation. The shifts affects only the working time, on call is handled by different people. Pagerduty application handles the rotation. It also alerts people if there's problem in their service.

One person answers, others continue work.

The Investigator shift is also visible in the calendar. Person who is one duty, has a full week calendar block that remind them and others that it is their turn. Every team also has a team Slack channel and if anyone needs help from the team, they can ping @Investigator. With this handle the person on duty will automatically be pinged and everyone else can continue their work.

Results 

When this social pattern is well adopted, it significantly decreases distractions and frees a lot of team resources to continue working on the normal backlog work. Without this pattern, probably the whole team would be pinged or the burden would concentrate on the few most senior individuals. By agreeing on the practices (for example that @Investigator pings need to be answered within agreed timeframe) it also improves the service level for internal customers. Because they have an agreed and supported way of getting reply to their questions and inquiries.

Depending on the amount of technical debt, wideness of team scope and size of the customer pool, Investigator shifts can also be stressful. Many teams have then agreed on supporting practices for their Investigators. There can be regular calls during the week or even two Investigators, if the expected weekly workload is very extensive.

With all the potential stress, many developers still seem to like the role. It is a chance for them to diversify their work and often learn something new.

This social pattern has been tried and proven to be useful. So I would highly recommend implementing something similar in your organisation.