Recently, I was attending a sailing seminar on racing small keelboats. As the lecturer talked about the crew requirements for winning races, I noted a lot of similarities with effective software development teams. Both situations require a small group of people to work in coordinated concert to achieve a common goal. No one on the team succeeds alone–they all reach the finish line together. There is a mix of specialized skills and general work that almost anyone can do. And there is a constant need for improvement, coupled with a desire to go fast.

In casual but competitive racing on a boat the size of mine, a total crew of six is generally considered a full crew. That includes a foredeck person, two jib trimmers, a main trimmer, a helmsman, and moveable ballast who can attend to anything else that needs it. Each of these jobs has specific responsibilities, but most crew members have general enough skills to jump in on other responsibilities when needed. If the crew is smaller, people can take on multiple jobs, though at some expense of efficiency.

One of the recommendations made was to get out on the racecourse an hour before the start and sail, with that crew and in those conditions, for 30 minutes to get acclimated. Then, relax and review what was learned during those 30 minutes. Finally, discuss what is the goal and strategy of the race ahead.

Looking forward at the goal and strategy ahead is very much like chartering. Every project needs a good liftoff. Ainsley Nies and Diana Larsen have just written a great book about why and how that’s necessary.

The pre-race practice at the technical skills of sailing the boat together, and the subsequent retrospective on that practice, are a fairly obvious strategy for sailboat racing. I hadn’t considered it, but I think the same approach would be beneficial for software development. What would happen if you assembled your team prior to chartering and held your own Code Retreat or other day of kata exercises? In one day, each technical member, both programmers and testers, of a small team could pair with every other on the team. They would gain familiarity with each other’s style of working and build a foundation for trust. The katas could be performed using the language and tools expected to be used in the project, but without the pressure to produce shippable functionality.

In sailboat practice, if a tack goes slowly, crew members get confused about their roles, or lines get tangled, then you can immediately stop, discuss it, and try again. In a race, the pressure is on to get things straightened out and then focus on what needs doing next. That “next thing” is often harder than it would have been because of the delay and confusion that follows a mistake. The same is true in software development.

“You can’t improve your fundamentals during a race.” This was the statement that caught my attention to the parallels between sailboat racing and software development. The lecturer recommended other practice days to hone fundamental skills such as tacking the jib, gybing the spinnaker, and making sail changes. The correlation between a race and a development project starts to break down in this metaphor, but the fact remains that we need to practice to improve. We learn far more if we practice mindfully, thinking about and discussing what we did and what we might have done, and then practice some more.

Most software projects I’ve seen make the assumption that the developers already have sufficient skill, or they should work on their skills on their own time. These things are somewhat true, which make this assumption very seductive. It’s also true that skills can always be improved, and most projects can benefit from spending time on improving those skills. How much time and how often is a balancing act decided in the context of the current skills and abilities, and the needs of the project. Of course, spending all your time on developing skills won’t get the project done, but spending zero time on developing skills is unlikely to be the fastest way to get the project done, also. Even the best teams will find there are new wrinkles to learn on every project.

And if you don’t spend time improving your fundamentals, you’ll lose the race.