Alaskan Agility:
Lessons about Scrum found in the Last Great Race on Earth®

In 1925, a very serious disease outbreak in northern Alaska was narrowly averted by the heroic agility of a sled dog team that delivered a life-saving serum by braving the 1100-mile trail from Anchorage to Nome in the harshest of wintry conditions. Today, this heroic event is commemorated annually with the famous Iditarod race. During a recent vacation to Alaska, I discovered a number of interesting parallels between the Iditarod and Scrum that can be found by observing the way in which the musher and team compete in this famous sled dog race.

Incremental Progress

It goes without saying that an 1100-mile race is too long to do in one continuous leg. Obviously it needs to be broken down into smaller more manageable increments. But what is interesting about the way that most teams run the race is that they organize these increments into identically timed segments that follow a fixed duration and cadence like we do in Scrum. With the exception of a few mandatory long breaks that all Iditarod teams must make along the long trail, most of the teams will for example run for 8 hours and then rest for 8 hours and do this in a continuous cycle. During the rest period they set up a camp, prepare meals, sleep and then break camp. This fixed cadence with defined events is somewhat like the fixed schedule and defined events within Scrum. The beginning of the iteration in Scrum is like breaking down camp and packing up the sled for the next Sprint, and then at the end of the Sprint, the team focuses on the health and well being of the team with a review and a retrospective. And much like in the Iditarod, an important aspect of what will allow a team to do this for a long stretch of time going forward is to ensure that we are doing it at a sustainable pace.

Team Dynamics

The Iditarod is considered the “Super Bowl” of dog sled racing. The last time I was in Alaska, I had the pleasure of meeting Jeff King, who has won the race four times (which would make him the “Tom Brady” of the Iditarod). At his “Husky Homestead” training facility just outside of Denali, he explained that his dogs don’t need to be driven and controlled by the musher. This dispelled quite a few myths I had about how sled teams were organized. He doesn’t use a whip to drive the team like I remember seeing in all those vintage Klondike Cat cartoons. The team is a pack that knows how to run as a group. The team is aligned with a shared purpose and knows what direction to run, and the musher is not pushing or driving the team, but instead is being pulled on the sled by the team. The primary role of the musher is that of a servant leader. In a lot of ways, the musher is playing a role much like that of a Scrum Master.

Servant Leadership

At Jeff King’s training facility, I also learned that the primary role of the musher is to care for the well being of the team, and to remove obstacles that may impede the team’s progress. Sometimes there are trees that fall down across the trail which need to be removed. Sometimes the musher needs to care for individual team members by rubbing their cramped feet. Some of the musher’s other key responsibilities include setting up camp, laying down a bed of straw, preparing the meals, and when the next leg of the race is about to begin it’s then time for the musher to break down the camp and pack up the sled for the next iteration.

Team Size

Much like in Scrum, there are some guidelines and rules as to the minimum and maximum team size. In the Iditarod, a team must have a minimum of six team members (not including the musher) when it crosses the finish line, and it must have at least 12 team members to start the race. The maximum amount of team members to start the race is 16. I recall Jeff King once explaining that in his experience, the ideal team size is actually between 8-10 team members and that any incremental team member above and beyond that will actually not result in any increased sled velocity by the team.

Cross-Functional Teams and Pairing

Within an Iditarod team, there are a number of specialty skills embedded within the team. Some dogs are better at certain types of terrains and weather conditions. There are four different positions a team member can be running at during a particular segment of the race. The lead dogs run at the front of the harness, followed by swing/point dogs, followed by team dogs and the pair of dogs at the back of the harness are known as the wheel dogs. During certain conditions, a pair of dogs may be running as the lead dogs, but in other conditions it may be a different pair based on their individual strengths and capabilities. It’s critical that a team have all the necessary skills and specialties embedded on the team for all the possible trail and weather conditions they expect to face. What’s also interesting is that the team members train and run in pairs.

As you can see, there are a lot of lessons on what makes for a great Scrum team that can be found in the wildest of places. Much like in the Iditarod, some of the elements of a successful Scrum team include being able to work incrementally at a sustainable pace, self empowerment and self organizing teams, servant leadership as opposed to command and control, proper attention to appropriate team sizes, and last but not least, cross functional teams and pairing.