In this series, we compare sailboat racing to agile methodology. This post lays the groundwork with background and definitions.
Part one of a series.
In the summer of 1989, fresh out of high school with about two clues, I interviewed for a summer job at the local foundry. The Human Resources Manager asked about my interests and I indicated that I’d always lived next to the water, but had never been on it.
Within a week, I was told there was no summer job, but an open invitation to start racing with the team of one of the plant managers. And, just like that, a love affair with sailboat racing began.
Over the next 13 years, I sailed on a lot of different boats. Big boats. Small boats. One hull. Two hulls. Brand new. And lucky to still be afloat. All of them raced – and got me out on the water.
In 2001, I took the plunge and became a boat owner. And a whole new world of experiences awaited me. Along the way, I’ve lost more races than I can count, I’ve won a handful, I’ve made many friends, and I’ve had a tremendous amount of fun. (Here’s a glimpse into that.)
In the professional aspects of my life, I’ve been a consultant for over 20 years.
I started as a developer, programming in C and shell script while learning all about Software Development Lifecycle (SDLC), specifically the Waterfall model. That is the standard approach of documenting requirements, designing a solution, building and testing it, and finally deploying the solution all in a lovely waterfall of activities.
This approach worked well and stays with me to this day – even as I transitioned from coding to DevOps to business analysis and project management roles. But, over time, approaches evolved.
A little over 15 years ago, Agile was documented as a new approach to developing software. The goals of the original signers were threefold: to improve interactions between users and code, decrease the time to deliver working solutions, and address the reality of changing requirements in a meaningful way while reducing bureaucratic documentation. (Read the Agile Manifesto)
My introduction to Agile came in 2011 as I stepped into a development team that was building a custom B2B portal. While learning how the team was using this “new,” 10-year-old methodology, I learned about this approach that valued ongoing customer feedback, working software, and direct interaction.
How Agile and Sailing Compare
I was also struck by the similarities between Agile and competitive sailing. In both scenarios, there is an overriding goal that is governed by a core set of rules. Both activities require preparation, tools, and teamwork.
To be successful with Agile or competitive sailing, you must adapt and adjust to change.
So, over the course of several articles, I plan to review the basics of sailboat racing and agile methodology. Whether you’re a seasoned pro, an experienced amateur, or a beginner to either Agile or sailing, I hope you’ll learn something through these explorations.
To lay the groundwork for the comparison, here are some terms for Agile and competitive sailing:
I’ve included detailed definitions for each of these terms below. Until next time, here’s a quote that highlights the ethos of Agile and sailing well:
“We cannot direct the wind, but we can adjust the sails.”
Agile Sailing Definitions:
Epic – What’s the big picture? What’s the overriding functionality that we’re trying to deliver?
Regatta – A series of races that are totaled together to provide a score in a competition (a regatta is made up of a minimum of one race and will typically have three to 10 races depending on the duration of the regatta).
Release – What’s a minimal viable piece of software that will provide some function? What can be developed and presented to users for feedback?
Race – Competitive event with a common start and finish. The course is predetermined and may include a defined route around fixed landmarks or may be a “movable course” around temporary marks.
Sprint – Defined period of time where an agile team is working to accomplish a defined set of functionality. Multiple sprints typically make up a release.
Leg – Defined portion of a race between two marks of the course where boats are actively working to move from one mark to the next. A race is make up of multiple legs.
Sprint 0 – Period of time that the team takes to prepare before starting to develop functionality. This includes working out team dynamics, establishing technical environments, and getting all of the tools in place for the team to be able to develop a solution.
Boat Setup / Rigging – Period of time before a race begins where the sails are connected and raised, the stays are tuned to the appropriate tension, and general maintenance of the boat is completed to ensure it is seaworthy and tuned for optimal performance.
Product Owner – Representative from the impacted business function. This individual directs the priorities of the team and indicates which functionality is the most important.
Tactician – Member of the race team that is responsible for directing the course of the boat. Which way should the boat go based on the wind pressure, currents, and next mark of the course?
Project Manager / Scrum Master – Master coordinator for the team who is responsible for the collective efforts of the team. Resolves issues, breaks ties, and ensures the team has what it needs to be successful.
Helmsman / Skipper – This person drives the boat and controls the tiller. Coordinates the execution of all maneuvers. And is responsible for the immediate safety of the crew and the boat.
Business Analyst – Works with the business to understand the functionality that is desired. Ensures sufficient documentation is provided so the rest of the team can successfully develop a product and then tests the results to ensure a successful product is delivered.
Pit – Person working in the middle of the boat to ensure all of the lines and halyards are running smoothly. Ensures the appropriate lines are pulled at the correct time in support of maneuvers.
Developer – Team members that create code to produce a functional result.
Bow / Trimmer / Grinder – Team members that trim and manipulate the sails on a boat to generate forward movement.
Stand-up – Opportunity for an agile team to come together and communicate with one another about what they are working on and what dependencies they have.
Pre-race Prep – Time for the sailboat race team to come together and talk about the upcoming leg, race, regatta and what will be required to get the best possible result.
Retrospective – Meeting after a sprint, release, or epic to discuss the details of the period and learn what actions should be started, continued, and stopped.
Race review – Meeting after a race to talk about what did and didn’t go well and how the team can do things differently for a better result in the future.
- Bookmark this page to read other installments in the weekly series
About the Author
Kevin Bracy is the Director of our Cleveland team. An experienced consulting executive, he has worked within a variety of service delivery companies to provide a wide range of solutions to clients. Kevin’s areas of expertise include ERP implementations, program management, system test delivery, technical infrastructure design/implementation, call center operations, and application development.