How a yacht race turned me into a Scrum Master

This is a re-post from my blog, but one that is still relevant today.

Continuous Improvement, Autonomy, Validation – these terms are becoming so worn that they feel like business jargon. But if you have experienced the pain that Stagnation, Command & Control and Big Bang Deployment brings, you have ample reason not to look back.  The mild embarrassment that comes with joining the ‘Agile cult’ is greatly outweighed by the soul-numbing awfulness that is the alternative.

Although the above is my experience too, this is not that story.  I have also had experiences with Chaos – the inferno that regularly erupts in Startupland and in many Open Source projects.  It, not Agile, is the real antithesis to the frozen hell that is Waterfall/Taylorism/TheoryX.  This is not that story either.  I actually started appreciating what I now call the Agile mindset, on a sailing boat.

As an adolescent I was pretty interested in ‘Team Building’ and while training as an outdoor sports instructor, we learned about Tuckman’s Forming/Norming/Storming/Performing.  I had noticed that cohesive teams had better morale and more fun but that they also sometimes missed creative solutions to problems that messier, argumentative teams seemed to come up with.  This even led me to study social psychology, although that field had disappointingly few insights on offer.  And really, I didn’t want to just understand teams, I wanted to be a part of one.

As a student and later as a Yacht Master I did a lot of yacht racing.  Now in the nineties, mirroring the software development world, yachts were starting to organise themselves differently.  Being a relative pauper but a skilled sailor, I was used to being ordered around the boat by the owner, who would also steer the boat. If you wanted to win races, you had to find that rare combination of the rich and skilled sailor.

Imagine my surprise when one day I stepped aboard a boat, shook the hand of the young man at the helm and he diverted me to the owner!  Here was a man who had given up the driver position to some pipsqueak, fresh out of a dinghy!  I recounted the experience to my skipper later that evening and we laughed about this.  What chaos it must be on board!  They’ll never win a thing.

That year the boat, Yellow Rose, won every series it entered.  The next season it won all the major series in the Netherlands and thereby the national title.  The season after that, it won the national title and its own class – X-332 – internationally, as well as Cork week – one of the biggest fleet races in the world.  I had gotten to know them well by then, I knew that they were a relatively young crew and that they hardly ever changed members.  I was allowed to join them for a race, the nationals in Hamble, UK.

I had never seen anything like this.  The owner took the position of tactician, but not the helmsman ‘driver’ position.  He completely trusted the crew with his boat, concentrating instead on the wind, tide and competition.  There was almost no shouting on board and if emotions flared up because of an inevitable mistake, these were evaluated after each race.  But the evaluation was of what went wrong in the situation, no blame was assigned.

Even more astonishing was that: no one person gave a call when a manoeuvre was initiated – each time it was initiated by a different person.  The helmsman initiated a tack, the mainsail trimmer initiated a gybe, the bowman initiated a kite hoist.  I saw manoeuvres called and then initiated seconds later that would have taken minutes of complicated instruction by the tactician on my previous team. And they improved all the time, every race was meticulously discussed and adapted to.

I was addicted – I sailed with Yellow Rose as much as I could.  I progressed to training other sailing teams too and started to spread the goodness there.  I wanted to spread this goodness to my work in software development too, but it took me another five years of searching before I found a team where I was allowed to apply what I had learned on a boat.

I am not going back.

Agile blog Marc Quirijnen

Ben agile, niet scrum

September jl. heb ik samen met mijn Valueminds collega’s het Agile Amsterdam event bezocht. Tijdens dit event stond Agile door de hele organisatie centraal en hebben we mogen genieten en leren van een aantal sterke sprekers rondom dit thema.

In de trein terug, richting het Brabantse, druk bezig alle indrukken van de dag te verwerken, drong het langzaam tot me door dat ik wat belangrijks geleerd heb die dag. In veel Agile gerelateerde cursussen, gildes, meet ups, conferenties etc. die ik de laatste paar jaar bezocht heb, wordt Agile gezien als een manier van werken, waarin de scrum methodiek bijna heilig wordt verklaard. ‘Als je de scrum methodiek volgt, ben je Agile’ wordt ook in veel organisaties gedacht, niet beseffende dat met die aanname, een aantal Agile principes omver worden gegooid.

Agile en scrum worden vaak in één adem genoemd, waardoor ik geen verschil meer zag. Agile is scrum, scrum is Agile. In de trein besefte ik echter dat Agile een gedachtegoed is en scrum slechts een werkwijze om het Agile gedachtegoed over te brengen. Een denkwijze versus een werkwijze. Scrum is slechts een middel en dus absoluut niet heilig, waarvan ik moet bekennen dat dit voor mij (en voor vele om mij heen) wel zo was. Vrijwel altijd als ik met iemand praat over Agile, gaat het over scrum en de scrum rituelen, maar niet over bijvoorbeeld het Agile manifesto.

Een ander punt wat centraal staat binnen het Agile gedachtegoed is zelf organiserende teams dan wel autonomie. Desondanks leggen we met scrum, teams toch weer een manier van werken op, in plaats van het Agile gedachtegoed over te brengen en het team daar zelf invulling in te laten geven. Er wordt zelfs krampachtig vastgehouden aan zaken die niet werken. Denk aan retro’s zonder vervolgacties, demo’s zonder werkende software, sprint planning op basis van planning poker zonder dat iemand ook maar echt begrijpt waarom er punten worden gebruikt in plaats van uren en ga zo maar door. Alleen maar ‘omdat we agile moeten werken’.

Ik besef dat het de taak is van een scrum master om de scrum rituelen en toepassingen in goede banen te leiden, zodat bovenstaande fout situaties niet voor komen. Echter vasthouden aan scrum terwijl je weerstand blijft voelen van het team is ook niet de beste oplossing. In dat geval is het toch beter om het team zelf invulling te geven aan hoe het Agile gedachtegoed gevolgd wordt? Dus als retrospectives niet werken, dan kan een team toch vast wel op een andere manier leren van hun fouten? Als het team zich vertrouwder voelt door te plannen en schatten op basis van uren, dan moet dat toch geen enkel probleem zijn?

Ik probeer onderstaand echt geen nieuwe agile principes in het leven te roepen (daar hebben we het manifesto voor), maar als ik kijk naar wat ik wil bewerkstelligen met een Agile manier van werken, kan ik dat als volgt samenvatten:

  • Krijg zo snel mogelijk feedback
  • Reflecteer en experimenteer
  • Werk samen en communiceer
  • Ben transparant

Dit kan prima bewerkstelligd worden via scrum, maar ook op andere manieren. Uitgangspunt moet blijven dat het Agile gedachtegoed in acht wordt gehouden en niet scrum. Dit zal ook veel scrum masters helpen die worstelen met weerstand in teams met betrekking tot de te volgen scrum rituelen.

Zelf ga ik binnenkort ook aan de slag met deze bevindingen en zal starten om tijdens de eerst komende retrospective alle scrum rituelen ter discussie te stellen. Benieuwd hoe het team gaat reageren. Wellicht dat dit leidt tot een interessante volgende blog.

Marc Quirijnen

Product Owner