Sailing, Sex and Software Development
What do Sailing, Sex and Software Development have in common? Two things. First: You can read a lot of books and listen to people talk, but you don’t really know what it’s about until you’ve actually done it.
I’m going to focus on the sailing and product management parallels because in spite of claims to the contrary.. I do have filter. You’ll have to fill in the sex bits as we go along… :| And as a reward for reading I’ll tell you the second thing at the end.
Why should we care about sailing and uh… software development?
I recently came across an article in Fortune by Rob Ashgar (management consultant) and another in The Globe and Mail by Ken Tencer (branding and innovation thought leader) who derided the Fail Fast, Fail Often mantra as nonsense. I’m not going to bother with a point by point takedown because their arguments are based on a straw man.
Since we’re talking about professional software development, let’s use competitive sailing as our counterpoint.
Assembling a crew:
Each member of a competitive sailing crew brings different strengths and weaknesses along with different experiences. They’ve sailed different boats, in different regions and in different conditions. If you’ve carefully selected your crew you know they have the bonafides to do the job. Would you drop them onto a boat they’ve never sailed the day before a race and expect them perform optimally?
Of course not. They may have never worked together. They may not have a lot of experience with this type of boat. They may not have sailed in the location this race is going to be held or under the types of conditions anticipated for this race.
The same is true with a development team. Even if you could assemble a previous dream team and set them about developing a nearly identical solution to one they built before you’re not assured of success. They have different knowledge and different tools. They aren’t going to approach the problem the same way they did before. And all the while we’ve been talking the market conditions are changing around you.
Shakedown cruise:
You’ve assembled your crew and you have a pretty good idea of what you want the final product to look like, but you need to get from here to there and you need make sure your crew works well together.
The shakedown cruise simulates working conditions for the vessel, for various reasons. For most new ships, the major reasons are to familiarize a crew with a new vessel and to ensure all of the ship’s systems are functional. A vessel is typically not committed to any timetables or tasks until it completes its shakedown cruise. As such, problems detected during the shakedown cruise can be fixed at minimal cost. — Wikipedia
Those in the development world know that process of failures begins before we’ve even untied the boat from the dock. But it’s not about the failures, it’s about what we learn from them and how we improve our processes based on those learnings.
In a shakedown cruise sailors expect problems; they expect failures. They don’t expect to sink. And that’s where the detractors of the Fail Fast, Fail Often mantra miss the boat.
Out to sea:
A ship in harbor is safe, but that is not what ships are built for.
There’s a dirty secret in sailing… it’s a lot of hard work. Relatively speaking very little time is spent headed downwind. Instead, under the direction of the captain the crew tacks back and forth making headway against the wind in ever changing seas. The captain course corrects not just at each turn, but during each leg minor adjustments are made to maximize performance.
In the software world the product manager provides direction at the beginning of each sprint. Priorities and focus have changed based on market conditions, customer feedback and product performance. As each sprint is in progress daily scrums alert the product team to currents and changes in the wind as it makes it way. The product manager’s job is to scan the horizon and make course adjustments as necessary…. generally subtle changes as tacking is an expensive operation that needs to be done just often enough to maximize forward progress. They’re also anticipating the next two or three major moves and evaluating them against new data as it arrives.
Building software is ugly, dirty business. The tides, currents and winds shift with unpredictable force. These changes require course constant vigalance and minor course corrections to react. Otherwise you risk being blown off course or making changes too late to maximize your velocity.
In the software world this constant stream of inputs; successes and failures inform our navigational decisions. By failing fast and failing often we look to keep our failures small and managable. To ignore the signs of danger puts the ship and crew at risk.
Fail Fast, Fail Often?
Yes! Failing is not only an option, it is inevitable. The question is will we manage our software development in a mananer which anticipates those failures, with systems designed to correct them? Or will we blithely sail on until the cumulative impact of failure risks sending the ship and crew into the deep?
Oh yeah… that second thing? You can have a lot of fun if you try.
Like the article? Please click the ❤.
