In my job as a software developer we organize our work following the “Scrum” model for agile software development.
That is a methodology where the work is split up in “sprints” that have a fixed length (e.g. 4 weeks). At the end of each sprint there should be a piece of software that is runnable (i.e. works).
That is different from the classic approach where one defined a set of requirements that had to be implemented which were then organized in a long and very detailed planning phase which was then followed by an very long and often delayed implementation phase.
By using sprints the risk of missing the mark and/or the deadline is highly reduced. One can react quicker to changing parameters (e.g. available time/resources) and still end up with a usable product that might have less features than originally planned but is ready at a predetermined time.
As I looked at the list of open todos that need to be done (some of them need to be ready by April 13th for the Select 6.50, others for the Acores race in july) I realized how much that resembled a software development project.
The target “product” is the combination of a race-ready boat and a well prepared skipper.
So I decided to treat my preparation as an agile project now and split the available time into sprints at which end both me and the boat should always be ready to leave for a race immediately.
And that might sound easier than it is considering that my todo list currently spans rigg work (trimming the mast, splicing halyards), electrics (fuse box is messy, fuel cell needs to be installed), electronics (data logger needs to be rewired, collision alert has to be wired) and personal preparation (fitness, meteo).
But this also sounds familiar from my job as a software developer. When working on a software component we often have to juggle different aspects that all have to be worked on more or less in parallel, e.g.: adding new features, fixing bugs, optimizing performance, interface definition, writing documentation, etc.
Now since the effectiveness of your work is considerably lower when you often have to switch from one area to the other we will often add so called “brouhaha”s to our sprints.
A brouhaha is a timespan of 2 to 5 days in which we will focus entirely on a specific area of work, e.g. performance optimization. It is incredible how much progress one can make by focussing on a specific area of work for some days.
So I will adapt this as well to my race preparations and add brouhahas to my sprints where it seems a good fit to finish a certain aspect of race preparation quickly and soundly.
So, sprints and brouhahas will be a frequent topic for weeks and months to come. It’s only 4 1/2 months left till the start of the acores race and until then more than 2000nm will need to be sailed successfully!
This post is also available in: German