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.


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.

10 Microsoft Teams Tips for working from home

Microsoft Teams comes with most Office 365 accounts, but it is also available for free with limited features. Due to the outbreak of the Covid-19 Microsoft decided to expand the free features. Teams has the potential to replace Outlook for all internal communication in your organization. The basic features are explained well in the videos of Microsoft.

In addition, I’ve collected 10 tips and tricks primarily for Scrum software development teams. Other teams might benefit from this too.

1. Extra chat options

In both chat and channels, this button gives you the option to add code snippets and hyperlinks. You can also mark the message as important to let it stand out from other messages.

2. Channel your information

Especially when working from home, there will be a lot of textual communication. If you use 1 chatgroup or channel, it basically becomes impossible to find back previous messages. Everybody will also be notified of all new messages, no matter if they are relevant. Compare it with replying to all in an e-mail and changing the topic. Isn’t that confusing? Create different channels for different topics and let people set their notifications according to their needs.

3. Connect with your build server

Just like Slack, Teams has the option to connect with your buildserver and post messages of builds, releases and pull requests directly in a channel. The advantage is that you can easily have a conversation about a release, build or pull request without opening a separate window. Combine this with the previous tip to create a channel for pull requests and a channel for your test automation run for example.

4. Channel vs chat group

In a channel every post is basically a topic that people can reply to under the topic, similar to how a forum works. In a chatgroup, although you can quote someone, the messages are always sequential. If two topics are discussed simultaneously, a channel will have a better overview of those 2 discussions than a chatgroup, if used correctly. Take this into consideration when structuring your communication.

5. Initialising a call and adding people

A (video)call can be initialized from a chatgroup or a meeting invite. Every meeting invite is by default a call which you can join. Typically meeting invites are used for regular meetings and (video)calls in a chat group to discuss ad hoc topics. In any call, people can be added manually. Both people who are already invited, so they get a pop-up or people who were not invited yet. This can both be done in the ‘show participants’ screen.

6. Poker during refinements

During a (video)call, people can share their screen to show JIRA for example. In addition, each call has their own chat integrated, which could be useful to poker during refinements. I would also recommend separating the votes per story with any comment (e.g. a dotted line), to avoid confusion which values are given for a story.

7. Online whiteboard

Besides sharing a screen, you can also set up a online whiteboard where all participants can draw on at the same time. This is an option in the share screen window. Multiple colors are available, and I would recommend assigning people to colors to see who draws what. In addition, an iPad (with MS teams app) or device with a touchscreen (e.g. Microsoft Surface Pro) combined with a pencil will improve this feature. Alternatively a Wacom drawing tablet could also improve your drawing skills over a mouse.

8. Add tabs for additional tools

In addition to Posts and Files (Sharpoint) can add ‘tabs’ to any channel or chatgroup. This can be a OneNote document, Wiki, a Trello board and many other free and paid options like brainstorm tools. People can work in these documents simultaneously. For example, a OneNote can be very useful to store meeting notes.

9. Digital sticky notes for a retrospective

During any call, you can go back to teams and your call will remain active and viewed in the top left corner of the screen. For example, you can go to your shared OneNote document or Trello board.  This can be used as alternative for anything you would normally do with sticky notes in a retrospective for example. In Trello you can add tasks and assign them to yourself to show that this is your ‘sticky note’. If you create a board with Start/Stop/Continue columns, you can still have a very basic online retrospective. There are probably paid options with better visuals and more features, like Miro for example, but with free options and some creativity you can do a lot.

10. Record a meeting

Any call can be recorded to view later for those who missed it. This is a built-in option when the call is active. This could be particularly useful for a sprint review. Although the feedback might come later, the demonstration can be shared with a wider audience more easily. If many people would like to join your review though, Teams has a Live events option that supports up to 10.000 viewers.


For people who like dark mode, there is a setting for this in both the browser and desktop app. Click your icon in the top right and go to settings. Here you can change the color palet.


Nieuwe leden in een Scrum team binnen een traditionele organisatie

Hoewel onze teams door de afgelopen jaren heen redelijk stabiel zijn gebleven, staan we nu voor de uitdaging om één van de teamleden te vervangen door een nieuw teamlid. Wij werken als Scrum teams binnen een traditionele organisatie waar het “officiële” selectieproces nog van kracht is. Dit houdt in dat een vacature wordt opgesteld, sollicitanten worden gescreend, uitgenodigd voor een eerste en tweede gesprek en op basis van, voornamelijk, skills aangenomen.

Doordat wij binnen de Scrum teams, over het algemeen al jaren samen werken, hebben we elkaar goed leren kennen. We kennen elkaars sterke maar ook zwakke punten. Hierdoor zijn we in staat om elke sprint weer waarde toe te voegen aan onze opleveringen door elkaar te helpen om onze sprintdoelen af te ronden. We hebben met elkaar de taken en verantwoordelijkheden van de verschillende rollen binnen onze teams vastgesteld, we spreken ons uit richting elkaar, kritiek wordt niet gezien als persoonlijke aanval maar als constructief en taakgericht en we voelen ons als teams verantwoordelijk voor het halen van onze doelen. En hoewel in mijn opinie de fases niet zo rechtlijnig lopen als Tuckman beschrijft maar meer cyclisch, denk ik dat wij de meeste tijd in de Performing stadium doorbrengen.

Tuckman; vijf fasen van groepsontwikkeling

Doordat wij de rollen en verantwoordelijkheden, de manier waarop en hoe wij willen werken in onze teams uitgebreid hebben besproken en blijven bespreken, proberen we de kwaliteit in onze teams hoog te houden.

Als Scrum-teams willen wij echter ook een stem hebben in wie wordt toegevoegd aan ons team. Want voor ons is het niet alleen belangrijk dat iemand de juiste skills set meeneemt maar ook dat diegene als persoon binnen het team past. Wij hebben daar de volgende oplossing voor bedacht.

Het eerste gesprek vindt plaats met mij in mijn rol van Scrum Master, samen met één van de teamleden (meestal iemand die een soortgelijke rol vervult). Indien wij de sollicitant een goede fit vinden, vindt een tweede gesprek plaats met de manager van de afdeling met, meestal zijn leidinggevende of iemand van P&O (het “traditionele” gesprek). Na een positief advies, doen wij dan een introductieronde in het team waarbij het aspirant teamlid een opdracht krijgt om uit te werken. Hiervoor wordt hij (of zij) een paar uur uitgenodigd om deel te nemen aan het team. Op die manier zien wij enerzijds wat zijn expertise is maar zien wij ook hoe diegene deel neemt binnen het team. Wordt er interactie opgezocht, neemt diegene deel aan de discussies en hoe laat hij zich horen. Uiteindelijk geeft ieder teamlid zijn “oordeel” in een persoonlijke terugkoppeling door aan mij. Persoonlijk omdat dan de teamleden niet gehinderd worden door de mening van één van de andere teamleden. Op deze manier proberen wij het zelf-organiserend vermogen van ons team en het opnemen van nieuwe teamleden binnen een traditionele organisatie op een goede manier vorm te geven. En proberen we, ook na het wijzigen van het team, weer zo snel mogelijk in onze performing stadium terug te komen. Ik ben benieuwd hoe jullie dit doen.

intrinsic motivation Thomas de Graaf

Intrinsically motivating environments

Some time ago I said to someone that I want to create an environment in which people become intrinsically motivated. He replied to me “But intrinsically motivated people are already motivated themselves!”.

In the world of IT, with more ideas than successful implementations, we continue to seek for new buzzwords to help us out. Everything-as-a-service, full-stack t-shaped unicorns, high performing teams and intrinsically motivated people, who would dare to say ‘no’ to these? Although there is a truth in these buzzwords, misunderstanding them can have devastating results. Those buzzwords might distract us from what really makes the biggest impact on the productivity of teams, defining the environment in which people work.

We like to put people into ‘boxes’ to understand them better and within IT that would preferably be binary. Within complex environments such as human behaviour, that is however not applicable. Let me prove this to you. For those who see themselves as intrinsically motivated, who needs his salary to pay the monthly bills or maintain his/hers standard of living? Who is saving up for a nice new car, bathroom, kitchen or house? Or are you looking forward to buy that new gadget or piece of clothing from the next salary? For those who see themselves as extrinsically motivated, did you ever leave the office with the feeling that you accomplished something great that day even though your payment didn’t change because of it? Did you ever feel challenged on your work, because someone gave you a challenge and you resolved it? Did you ever feel appreciated at work because someone said thank you when you helped them out?

Hopefully I just proved there is a lot of grey area here and people are generally both intrinsically and extrinsically motivated. But that is not where it stops, it gets even better! Motivation is not static, we can influence it! Imagine you are a predominantly intrinsically motivated cartoon artist. You make awesome cartoons, appreciated by millions of viewers worldwide. One day a new chief editor is assigned who reviews your creations and every single time he says they are not good enough. Without elaborating why, he puts all of your work in the paper shredder right in front of you. Would you remain intrinsically motivated? What if he also decides to cut your salary or stop paying at all? And what if this cartoon artist would be a software developer instead, would this still apply?

Now the other way around, can we make a predominantly extrinsically motivated individual more intrinsically motivated? As a manager, try telling your team that you didn’t just hire them for their capabilities, but also want them to develop themselves in areas they are interested in, so they remain motivated and committed for a longer period of time. Give them the opportunity to explore new challenges, accept failure and let them learn by trying. Ask them if they are happy with their work and seek new opportunities together if the current work is not giving any satisfaction. In fact, anyone can help creating an intrinsically motivating environment. Try giving a colleague a compliment, let someone pick up a story for whom it is a challenge rather than a walk in the park. Give your colleague a compliment or thank them if they did something for you, it’s also the little things. Don’t forget to have some fun too, it might make you more intrinsically motivated as well.

Therefore, let’s stop talking about intrinsic motivated people and start talking about intrinsically motivating environments. Examples anyone?

Opsplitsen van een Scrum team

Andre Heijstek, directeur bij Valueminds:

De Scrum-guide geeft, mijns inziens terecht, aan dat een Scrum-team tussen de 3 en 9 man groot moet zijn.

Het team dat ik op dit moment begeleid groeide naar 11 man,dus het werd tijd om te splitsen. Dat deden we overigens niet omdat het moet van de Scrum-guide. Zo scrumdamentalistisch zit ons team niet in elkaar.Wel omdat we last kregen van de grootte:

  • allereerst heel praktisch, de ruimte waar we zaten als team werd gewoon te klein om er te kunnen zitten met 11 man;
  • we merkten ook dat meetings steeds langer werden doordat in een grote groep iedereen toch zijn zegje moet doen;
  • en als belangrijkste, het werd vaak onrustig. Te veel interactie tussen teamleden is niet goed. Iedereen luistert toch even met een half oor mee als twee mensen met elkaar in gesprek gaan, als er een gebruiker langs komt met vragen, een stakeholder met wensen, etc.

Na de splitsing merkte we een enorm verschil in de rust rondom het team. Zeker in het kleinere team (4 man) dat in een kleiner, separate kamer ging zitten.

We hebben goed nagedacht over hoe we het team zouden splitsen. We zagen 3 snijvlakken:

  1. development versus maintenance, met andere woorden, bouw van nieuwe features versus vernieuwbouw van bestaande features
  2. functioneel beheer versus development; het team had 5 ontwikkelaars, 2 testers, 2 functioneel beheerders, 1 scrum master/tester en een product owner. Een optie was om de functioneel beheerders en de PO in een ‘ready-team’ te zetten, naast het development team
  3. een splitsing langs technische of functionele onderdelen van ons systeem

Optie 1 was aantrekkelijk en aanvankelijk de voorkeur vanuit de stuurgroep. Het team wordt behoorlijk geremd in de gewenste velocity voornieuwbouw doordat er continu bugs en kleine praktische verbeterwensen uit de organisatie komen. Nieuwbouw krijgt daardoor niet de rust die nodig is om snelheid te maken.

Het nadeel van optie 1 is echter dat het een perverse mentaliteit oproept. Het nieuwbouw-team mag rommel afleveren omdat het maintenance-team het later wel zal oplossen. Natuurlijk zal niemand dat bewust zo aanpakken. Maar onbewust kan dit gevoel wel ontstaan. Een aanpak waarbij ‘de vervuiler betaalt’, degene die de bugs maakt ze ook moet oplossen leek ons beter.

Optie 2 had ook een paar voordelen. Het is (nog steeds) hard nodig in dit team dat er meer structuur komt in de backlog. We zitten nog in een fase die door Henrik Kniberg ‘spoon-feeding the team’ genoemd wordt, de PO kijkt maar 1 sprint vooruit. Aan de andere kant: de functioneel beheerders hebben veel domein-kennis die bij de developers veel beperkter is. Veel interactie tussen functioneel beheer en development om slimme, werkbare oplossingen te bouwen is noodzakelijk.

We hebben daarom gekozen voor optie 3. Het ene team pakt alle financiële onderdelen op van het systeem en imports van data van nieuwe klanten. Het andere team richt zich meer op documenten en workflows binnen het systeem. Ieder team heeft 1 functioneel beheerder die de PO ondersteunt in het refinen van de user stories.

Deze indeling is in feite een vertical slice. Vergelijkbaar met de manier waarop user stories geplitst moeten worden.

Volgorde van de backlog

André Heijstek, directeur van Valueminds:

‘De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder. De regel die het meest wordt gebruikt is dat de items op volgorde van waarde staan. Naar mijn mening is dat echter te beperkt. In mijn ideale situatie bepaalt een mix van de volgende factoren de volgorde van de backlog:

  • Technische afhankelijkheden. Er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.
  • Waarde. Spannende stories waar mogelijk ellende in zit moet relatief hoog op de lijst staan: fail fast is beter dan fail late.
  • Risico. De waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de Product Owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig).

Naast deze drie aspecten, komt er in de keuzes voor de komende sprint nog en aspect bij: wanneer de items waaraan in een sprint wordt gewerkt aan elkaar gerelateerd zijn, werkt dit veel prettiger. Dan krijg je zoiets als: ‘In sprint 4 doen we rapportage, in sprint 5 implementeren we het zoeken.’ Wil je dat het team meer focus krijgt en meer gaat samenwerken tijdens sprint? Stel dan een sprint goal!’

Story points aanpassen voor een nieuwe developer?

André Heijstek, directeur van Valueminds:

‘Op dit moment coach ik een team dat sinds drie sprints aan het schatten is in story points. Op basis van de afgeronde stories hebben we van de laatste sprints een story point liniaal gemaakt, zodat we een goede referentie hebben. We houden nieuwe stories tegen deze liniaal aan: Lijkt het op de andere drietjes? Dan is het ook een drie.

Een tijdje geleden kregen we er een nieuw teamlid bij. Dit was een ervaren ontwikkelaar, maar nieuw in ons team en dus niet bekend met ons business domein en met de opzet van onze code. Het is logisch dat hij er voorlopig wat langer over doet dan anderen om een story af te ronden. Maar hoe gaan we hiermee om met de schattingen? Moet je de stories die hij gaat doen meer punten geven?

NEE! Dat gaan we zeker niet doen. Dat helpt het hele mechanisme om zeep.

Daarnaast kan het ook helemaal niet, we weten namelijk vooraf niet precies wie aan welke story gaat werken. We werken met zoveel mensen als zinvol mogelijk is aan de eerste story en starten dan pas met story 2. Wie wat gaat doen wordt daardoor pas heel kort van te voren duidelijk.

Ook zo zo’n aanpassing aan een nieuwe programmeur het hele idee van story points om zeep helpen. De story points geven aan hoe groot een story is voor het hele team. Het schatten van stories blijft hetzelfde: met de story point liniaal. Als deze story lijkt op de drieën van onze liniaal dan krijgt hij drie punten.

Op het moment dat er een nieuw teamlid bij komt verandert het team, en daarmee ook de velocity. Een nieuw teamlid haalt in de meeste gevallen eerst de velocity omlaag. Hij levert zelf nog niet veel output op en met al z’n vragen houdt hij ook nog eens de ervaren teamleden van het werk. Hopelijk stijgt de velocity later wel, als hij meer zelfstandig z’n taken gaat oppakken. Hiermee is de velocity een eerlijk maat van de output van het team.’