Scrum and Yacht Racing – Roles

This is a cross-post from my own blog, I hope you find value in it!

Watching the development of yacht sailing teams during a campaign, I have always been struck by the similarities between an effective team on a boat and an effective Scrum team.

If we take an X-35 team, it has 7 to 9 members.  Each member of the team has a very specific set of skills and a role. A team has a build-up to a race or a series of races in a campaign.  Usually there is a main goal – a certain race that stands out like a world cup – combined with a series of smaller events.

Roles

To get an idea of a typical modern sailing team, it is handy to understand what everyone does.  Beginning at the back of the boat:

The Tactician can be equated to Product Owner.  He or she does not actually do any of the physical work but rather decides where the boat should go.  A good tactician knows when to consult with his team and when to make a decision.  Depending on what the tactician decides, the necessary manoeuvres become evident.  The tactician is responsible for where the boat goes, but not how it gets there.

Next up is the Helmsman, or ‘Driver’.  In waterfall methods, just as in old-fashioned skipper-led sailing, this would be the project leader.  However, in modern sailing, the helmsman is simply a part of the crew.  Like a designer, he has a lot of influence on the progress of the team, but he is still a developer and part of the development team.

Then come the trimmers, they set the sails up to give maximum power.  Especially when heading upwind, they will often be doing their own thing without involving the rest of the team too much.  They are responsible for keeping the boat power optimal – in a car they would be the engine.

In the front of the boat there are the bowman or the bow crew.  They have very specific tasks, that affect the handling of the boat: hoisting and dropping sails, tripping shackles, holding and moving gear.  They have to work independently yet also together with the rest of the team – in a car they would be the gearbox.  In a Scrum team you could compare the trimmers and bow crew to front- and back-end developers.

One team member or otherwise an outsider often takes the role of the trainer – that is what a Scrum Master is supposed to be after all.  In fact, I like the fact that not all sailing teams feel the need to appoint a trainer – a really experienced Scrum team should be able to keep to the principles of Scrum without the need for a Scrum Master in the same way.

Self Organising Teams

When I join a boat for the first time as a trainer and I detect that the owner, driver or tactician have an hierarchical view of the roles on board, I often tell them about my experiences as a bowman.  As a student, I started yacht racing aboard a boat where the owner was the helmsman (the driver) as well as being the tactician and the brains, if not the hands, of all the trimmers and bow crew.  A standard race would consist of this gentleman shouting a series of commands at his crew, whilst he steered the boat and decided where to go.  This meant he was effectively deciding everything on board: steering, sail trim, boat handling, tactics and strategy – it was all up to him.  In times of stress, he would sometimes leave the helm to do someone else’s task if their performance was not to his liking.

When I first started to sail on board of the boat, the results were actually pretty good – the boat achieved good results in the local competition and did fairly well in national events too.  However, after a couple of years, I decided it was time to leave.  The team kept changing, people would leave, usually after having been shouted at for not following instructions correctly.  In the incident that had triggered my leaving, we had run aground because the spinnaker had not come down on time.  According to the skipper this was because of my actions as a bowman, according to me it was because he had been shouting at me so much, he had simply forgotten to steer the boat.  Whatever the reason in this case, our competition was clearly getting better – we were winning less and less races.

At this time, in the mid 90’s, the idea of a self-organising team was becoming a more popular style of leadership on many yachts.  The idea being that if each team-member knew his own role and it was up to him to act, the amount of knowledge being used was greater than if it all had to trickle down from the back of the boat.  Modern boats were also harder to drive, meaning that a helmsman would sacrifice the quality of their own work if they started involving themselves with what someone else was doing.  The trimmers and bow crew communicated with each other instead of via the skipper, losing less time and information in communication.

This method developed – in the team I had joined, we determined who would initiate action for all of the standard manoeuvres that the boat would do.  The team that I sail with nowadays has handling-sheets for 16 standard situations, only four of which are initiated by the driver.  This is not to say that there is no hierarchy on board – if a snap decision has to be made, the tactician makes the call, but in all other circumstances each position decides on their own actions.

These new methods resulted in the old-fashioned way of doing things, let’s call it the skipper-driven (waterfall?) method, being less effective than the new, self-organising method.  And that’s the nice thing about formal competition – it doesn’t get much more empirical than the results in a race.

User Story Mapping tijdens Agile Meetup Breda: de Retrospective

Op 22 april hebben we met Agile Meetup Breda een online workshop gehouden met als thema “User Story Mapping”.

Initieel was het de bedoeling om de meetup in levende lijve te doen op een mooie locatie in Breda. De coronacrisis gooide echter helaas roet in het eten. Omdat we toch aan de slag wilden met het onderwerp en we ook erg benieuwd waren of we dit op afstand konden doen hebben we de meetup alsnog door laten gaan maar dan online.

Een overzicht van onze aanpak en de stappen die we hebben doorlopen kun je hier vinden.

De meetup was van 15:00u tot 17:00u. Met van 14:30u tot 15:00u digitale inloop. We hadden 15 deelnemers. Als digitale hulpmiddelen hebben me Microsoft Teams en Mural gebruikt.

Dit was voor ons de eerste keer dat we het op deze manier hebben gefaciliteerd. Heel veel ging goed, maar er viel zeker nog genoeg te verbeteren voor een volgende keer. Onderstaand de belangrijkste punten uit onze retrospective:

Wat ging goed

  • Overall hebben we in een korte tijd de belangrijkste aspecten van de techniek kunnen behandelen. Voor een volgende keer gaan we nog goed kijken of bepaalde onderdelen meer of minder of op een andere manier aan de orde moeten komen. Hiervoor gaan we ook beter vooraf luisteren naar de behoeften van de groep.
  • We hadden een zeer enthousiaste groep deelnemers. Voor zover we dat goed meekregen had iedereen er lol in en was het voor iedereen een interessante ervaring.
  • Naast centrale onderdelen hadden we ook twee breakout momenten, waarin een facilitator met een groepje van 3 tot 5 mensen in een aparte teamroom werkte aan het invullen van een gedeelte van de User Story Map. Dat was erg geslaagd. De sfeer was goed. Omdat je met een klein groepje bent wordt het gelijk wat intiemer en persoonlijker.
  • Richting het einde vielen er een aantal kwartjes, met name voor wat betreft waar User Story Mapping past in een flow met andere technieken. Bijvoorbeeld dat je begint met een product vision, dan maak je een User Story Map en vervolgens komen de User Stories hiervan als items op een Sprint Backlog terecht, al dan niet via een Product Backlog. Hierdoor kwam er meer beeld bij de context van een User Story Map.

Wat kan beter

  • Microsoft teams werkt in de huidige vorm niet goed genoeg. Ondanks vooraf gestuurde uitnodigingen met toegang tot onze Teams omgeving duurde het zeker 20 minuten voordat we van start konden omdat mensen toch tegen toegangsproblemen aanliepen. We hadden verschillende rooms aangemaakt voor de break-out onderdelen. Ook daarbij duurde het langer dan wenselijk voordat iedereen op de juiste plek zat. Een volgende keer gaan we gebruik maken van Zoom of een andere online tool.
  • Daarnaast willen we de volgende keer dat een persoon als moderator optreed voor wat betreft technische zaken en mensen die inlogproblemen hebben. Dat moet ook duidelijk zijn voor de genodigden. Nu waren er een aantal mensen bezig, o.a. de gene die het eerste gedeelte aan het uitleggen was, met mensen toegang te verlenen en troubleshooting.
  • We hadden vooraf een half uur inloop gepland voor het officiële gedeelte zou beginnen. Net als bij een fysieke meetup. We merkten echter dat nu bijna iedereen pas in de laatste minuut digitaal binnenkwam. De volgende week maken 20 tot 30 minuten inloop onderdeel van de officiële planning. Zijn we eerder klaar, dan is het mooi en gaan we van start, maar andere loop je gelijk al achter op de planning.
  • We hadden een vrij strakke planning, met het schakelen van gezamenlijke onderdelen naar break-out onderdelen verloren we tijd, waardoor de planning nog meer in het gedrang kwam. De volgende keer gaan we dus ruimer plannen.
  • De intro die we gaven m.b.t. User Story Mapping was te kort. Gedurende de meetup kwamen we er achter dat niet voor iedereen duidelijk wat nou precies het doel is en wanneer je het goed kunt gebruiken. De volgende keer gaan we hier vooraf langer bij stilstaan.
  • Ondanks dat User Story Mapping redelijk gangbaar is, merkten we toch dat er verschillende interpretaties zijn van de techniek. Ook als facilitators. Hier hadden we vooraf langer bij stil moeten staan. Voor een volgende keer gaan we bijvoorbeeld duidelijker bepalen of we gaan focussen op het maken van een back-bone of dat we meer aandacht gaan besteden aan het maken van slices en een development strategie. We hadden een redelijk complexe casus gekozen, met als onderwerp het Havenbedrijf in Rotterdam. Erg interessant, maar wellicht dat we voor een volgende een iets minder complexe casus kiezen.
  • Twee uur voor een meetup/workshop met een onderwerp als dit is erg kort. Om het onderwerp echt recht te doen en tijd te hebben om er zelf mee aan de slag te gaan, heb je al gauw 4 tot 6 uur nodig.

De volgende keer dat we aan de slag gaan met User Story Mapping is op 27 mei, met Agile Meetup Rotterdam.

Product owner: Domeinkennis is slechts een pré

‘Een veelvoorkomende situatie: Wanneer een organisatie wil transformeren naar een agile manier van werken, is het redelijk eenvoudig om een scrum team samen te stellen. Ontwikkelaars, testers en business analisten worden bij elkaar gezet en omgedoopt tot scrum team. Eén van de teamleden krijgt de deeltaak van scrum master[1] en vanuit de business wordt de persoon met de meeste domeinkennis naar voren geschoven als product owner. Scrum team compleet!!!

De backlog zal wellicht nog gevuld zijn met backlog items die in het verleden al in detail zijn uitgewerkt en opgepakt kunnen worden in de komende sprint(s). Zodra het team echter aan nieuwere items wil gaan werken, blijkt het detailniveau te hoog te zijn om op te pakken. Niet erg, daar zijn uiteindelijk refinement sessies voor. Helaas heeft de product owner een overvolle agenda en kan niet aanwezig zijn.

Het team probeert dan maar op basis van aannames de refinement uit te voeren, om vervolgens de backlog items in te plannen in de volgende sprint. Tijdens die sprint, rijzen er vanwege de aannames veel vragen, maar wederom blijkt de product owner te weinig beschikbaar om alle vragen voldoende te beantwoorden. Tijdens de sprint review, of nog erger, na in productie name, blijkt dat het team de plank volledig heeft mis geslagen en opnieuw kan beginnen. Zie je wel dat Agile niet werkt….

Oké, ik overdrijf in bovenstaande situatieschets misschien wat, maar de kern van het verhaal staat als een paal boven water. Zonder product owner die voldoende beschikbaar is voor een scrum team, is het werken in scrum teams gedoemd te mislukken. Toch wordt in veel organisaties domeinkennis gezien als groter belang dan beschikbaarheid voor een product owner, waardoor meestal iemand met veel domeinkennis wordt aangesteld. Echter zijn dit ook altijd personen met overvolle agenda’s, die daardoor het product ownerschap er ‘maar even bij gaan doen voor een paar uurtjes per week’.

Die paar uurtjes zijn niet voldoende voor de taken van een product owner, dus lijkt de “ideale kandidaat” die bovenstaand beschreven wordt niet geschikt voor de rol. Echter is domeinkennis wel nodig om de taken van een product owner uit te voeren en lijken we te belanden in een vicieuze cirkel.

Dit probleem kan verholpen worden door iemand aan te stellen met voldoende tijd om beschikbaar te zijn voor het scrum team, maar wel met vaardigheden om de daarvoor benodigde informatie te verzamelen en dit op een eenduidige wijze kan delen met het scrum team en andere stakeholders. Die informatie kan gehaald worden bij iemand met veel domeinkennis, uit andere lagen van de organisatie, maar ook zeker van buiten de organisatie (lees: klanten en gebruikers). Daarnaast is het belangrijk om zo snel mogelijk feedback te krijgen op features die ontwikkeld zijn, wellicht zelfs voordat ontwikkeling plaats gaat vinden, om de backlog eventueel bij te sturen. Daar ligt ook een belangrijke rol voor de product owner.

Met de groei van Agile zijn er vele technieken en middelen geïntroduceerd om backlog items te bespreken en te beschrijven, zowel tekstueel als visueel, zodat ze voor het scrum team en voor andere stakeholders op een eenduidige manier te begrijpen zijn. Om maar een paar technieken / termen te noemen die ik veel gebruik; ‘User story mapping, ‘Three amigos’, ‘Sketching’, ‘User Feedback’.

Iemand die over dit soort technieken en middelen beschikt kan prima zonder domeinkennis de rol van product owner invullen. De domeinkennis zal de product owner zich te zijner tijd eigen maken, maar kan dit eventueel beperken aangezien hij of zij weet waar informatie vandaan te halen en kan zich daarom richten op de belangrijkste taak, beschikbaar zijn voor het scrum team en stakeholders om de juiste informatie op een eenduidige wijze over te kunnen brengen. Door de rol van product owner op deze manier in te vullen, kan de product owner zowel van binnen als buiten de organisatie ingevuld worden.’

Marc Quirijnen
Ingezet bij Philips HealthCare als product owner in bovenstaande context.

[1] Of dit een deeltaak van een van de developers/testers/analisten moet zijn of een dedicated functie is overigens ook een interessant punt van discussie, maar dit voor deze blog terzijde. Mijn collega René de Leijer schreef daar een interessante blogpost over.

Value points

André Heijstek, directeur van Valueminds:

‘De kosten van een user story worden in de regel ingeschat in story points, waarvoor we meestal de Fibonacci-reeks gebruiken (1,2,3,5,8, etc.). Maar hoe schat je de waarde van een user story in? Dit kan op dezelfde manier. De product owner kan samen met zijn stakeholders de inschatting maken met dezelfde Fibonacci reeks. Hiervoor kan je planning poker kaartjes gebruiken. Het kan natuurlijk ook met een andere set getallen. Ik zelf werk altijd met een reeks van 1 t/m 1000, waarbij 1000 het meest belangrijk is.

Als je de backlog hebt ingeschat op zowel de waarde als de kosten, dan is een deel van de prioritering van de backlog gemakkelijker geworden. Je kan dan per user story de prioriteit berekenen als business waarde/story points, bijvoorbeeld:

planning poker kaarten Valueminds

Stories zoals story 4 met veel waarde en weinig kosten kan je zo snel mogelijk oppakken. Stories met weinig waarde en veel kosten (story 3) kunnen van de backlog verwijderd worden. Natuurlijk is dit niet het enige wat de product owner mee moet nemen in de prioriteitsstelling. Technische afhankelijkheden tussen stories kunnen tot een andere volgorde leiden: je kan story 5 pas bouwen als story 13 eerst gebouwd is.

Daarnaast is het vaak ook slim om soortgelijke stories in 1 sprint bij elkaar op te pakken. Je krijgt dan een heldere sprint goal zoals: ‘in deze sprint doen we alle rapportage-stories.’

Het kan ook zijn dat je met stories op meerdere niveaus werkt, zoals thema’s, epics, etc. In dat geval moet je oppassen dat je maar op één niveau waardepunten toekent. Wat mij betreft is het laagste niveau (het niveau van de user stories) de plek waar je waarde zou moeten toekennen. Wanneer je dit niet doet, ga je dingen dubbel tellen. Ik kies voor het laagste niveau omdat ik van mening ben dat elke user story de waarde zou moeten hebben. Wanneer je punten op dit niveau gaat toekennen, dwingt het je ook om er zo over na te gaan denken.’