Agile and sailing share many traits. Especially how the two are in constant motion – and teams must regularly adjust to change.
Part two of a series
In the first article of my series, I outlined how competitive sailing and Agile methodology are very similar, especially how the details of that final goal WILL most likely change over the period of time that it takes to reach the end goal – or to complete the race.
What is Agile’s Continuous Delivery Concept?
Now, in this blog, we’ll focus on the Agile concept of “Continuous Delivery” and the sailing similarities there. But first, let’s consider the first three paragraphs of the Agile Manifesto:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
There is a clear call to developers or more broadly to anyone that is producing a product (a.k.a. producers), to not wait until the end to provide value to your customer. All that means is the customer needs to see results on an ongoing basis.
How Does Continuous Delivery Impact Projects?
It’s actually beneficial to both sides to provide software, prototypes, working code, or samples along the way. Here’s how the customer benefits most:
- Sampling / Confirming – Seeing an initial or even partial version of the final product allows the customer to see their vision in reality and then adjust. The sample may show deficiencies in the original vision. Or it may demonstrate that the desired impact is not fully met and needs to be modified for better effect and increased value.
- Brainstorming – Iterations of the product give the customer an opportunity to think about other opportunities and other value that can be derived based on what is now visible. If I add another feature, will that increase the value? If I take away a feature, do I really lose anything? Can I make the product simpler or less costly?
Here are the benefits for the developer or producer:
- Learning – By working on a very focused task and delivering on that product over a Sprint, the developer or producer has a chance to see what works, what doesn’t work, and where new opportunities in the development of the project exist. Do the current components lead to the best result or could we do this better? Are there legacy components or interfaces causing challenges? Can we improve the build process?
- Simplifying / Streamlining – The requirement to deliver a particular feature or product through a Sprint (short time-frame) also brings the benefit of focus. The developer or producer does not have to try and solve the entire problem at once. The goal for the Sprint is to provide a workable (not necessarily complete) product that achieves a particular feature. This focus enables the developer or producer to leave everything else out. Those other items may become important, but that is the role of the Product Owner, who defines what the priorities are for future sprints. Right now, all that is required is to deliver on the product for this sprint.
It’s important to repeat this process on a consistent, iterative basis, so the product or products are continuously developed. Features start to build on features until a broader, more holistic solution is developed. The team and most importantly, the customer does not wait until the end of the process to see the result.
By reviewing the products continuously throughout the development process (with each Sprint review), the customer (Product Owner) is able to test the result as well as verify and validate assumptions about what the product can do. This process also gives customers the opportunity to simplify the solution and focus on those features and aspects of the product that will drive the most value.
Side note: Agile is not a single school of thought. Much as many of the religions of the world have a variety of denominations, Agile also has many variants and subsets. Relevant to this article, there are different perspectives on continuous delivery and what that means. See The Conflict Between Continuous Delivery and Traditional Agile by Kief for a perspective on two of the methodology variants.
What Does Agile Continuous Delivery Have to Do With Sailing?
Now that we’ve addressed how continuous delivery impacts development projects, what does it have to do with sailing? Before the race starts, the racing sailboat must be working on its delivery. (See Start Before the Start by Steve Hunt for some sample strategies)
The boats are jockeying for position, the Bow is calling out the countdown for the race start, and various members of the crew are calling out to other boats indicating where they should and should not be. (As a long-time sailor once told me, there is lots of verbal enthusiasm at this point in the race!)
Once the race has actually started, the boat and her crew must continuously work to maintain position by adjusting for the wind, weather, tides, other boats, and anything else Mother Nature decides to throw out on the course. Continuous development on a race course means adjusting the sails, the tiller, and the heel of the boat (i.e. moving body weight from one part of the boat to another) to optimize both speed and direction.
The results of a given leg (See Detailed Definitions) do not determine the final result. There are many races where the boat in the lead at the end of the first leg is not the winner of the race. Boats and their crew must continue to work and deliver until they have crossed the finish line.
To highlight the similarities between Agile and Sailing, compare the benefits discussed earlier:
Observe that in Agile and competitive sailing, the descriptors are all action verbs. A key similarity between the two is constant motion. Or, to use the phrase from the manifesto, continuous delivery.
In Conclusion
There is a recognition that the world is not static. Customers and the wind do not stay the same over time. Perception and direction change. And, in order for the team (development or sailing) to remain relevant, we must adapt our style and deliverables to those constantly changing dynamics.
Perhaps these messages say it best: Keep calm and deliver continuously. Keep calm and sail on.