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.

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.

Scrum Mastery in Corona Times

As precautions against the spread of the Corona virus take effect, many of our teams have started working from home.  This is hard.  Good Scrum is much easier with a team who all work in the same location.  The Spontaneous- and non-verbal communication that is lost usually makes understanding each other a lot easier.

Here are a number of practical tips that we thought up.  Please feel free to share ideas that we didn’t come up with.

General

• Over-communicate, call every team member every day to see how they are doing, also privately.  Are there worries about Corona virus in the family, extended family etc.
• These can be tense times, people will be more stressed than usual.  As a Scrum Master you can take the stance of a trusted confidant.
• Share information from the company about how we deal with Corona virus.
• Practice expectation management with your team and with your stakeholders.  Development velocity will probably drop, team morale may suffer.  Speak about this, practice openness.
• Online meetings are more difficult that face-to-face meetings, people are more easily distracted and the meetings can be more tiring.  Ask everyone to switch on their webcam so you can see people’s engagement as in a normal meeting.
• Keep meetings short – 1 hour max!
• Be extra strict in facilitation.  Allow only 1 person to speak.  Consider that there will be lag and latency in audio and video.
• Use a headset and not laptop audio to reduce background noise.
• Working from home can give a lot of flexibility – if the children need care in the afternoon, work in the evening.  However, this may make collaboration more difficult – speak about this in your team.  Do we keep to office hours?  Collaboration in the mornings?
• We have quite good experiences with Microsoft Teams – Microsoft are even offering it for free at the moment.  Experiment with it as a Scrum Master.  Make sure you are skilled at using it during meetings.
• Make a ‘random’ channel in Teams for informal chat – we’re still people who like to babble.
• If you use JIRA: the desktop app is often faster and gives more insight than the web-app.

Per Scrum Event

Sprint Planning

• Make sure, even more than usual, that the Product Backlog is organized.  Don’t waste time on a lot of small stuff.  Prepare by already making the next sprint and drag in items that you know the PO will want anyway.  That leaves more room for discussing whether this will fit in the sprint.
• Make sure you know the velocity of the previous sprints and that you know who will be away so you can forecast the sprint well.  It is quite conceivable that velocity will be 10-20% lower than when you are co-located.
• Do part 1 of Sprint Planning (when you pull items from the Product Backlog) with the entire team.
• Do part 2 of Sprint Planning (when you design and detail items) in small groups or individuals.  That can make the event shorter and more focussed.

Daily Scrum

• It may take longer than usual, be flexible with the 15 minute timebox in the beginning.
• Perhaps have more than one Daily Scrum if that helps.
• A check-in, where everyone says how they are doing, preceding the event, can be useful.
• Even more than usual, remember that this is a meeting to inspect and adapt the plan for the day, not a ’round-robin’.  “Who worked on item 1 yesterday, who will work on it today, are there impediments preventing it from being “Done”?”.  This prevents a lot of scrolling up and down in JIRA (or other backlog tool).  Now you can start at the top and work your way down.  This stimulates swarming and picking up the most valuable items first.  Read more about this practice here.

The Sprint

• As a Scrum Master, make sure there is still informal communication between team members – check chat/slack channels – is there enough communication, is everyone participating?
• If backlog items are being swarmed, set up a seperate chat/channel for this so that they have their own place to be communicated about.
• Let the technology do its work – use Git commit messages so you can see pull requests and your test automation tool to see failing tests.

Backlog Refinement

• Keep meetings shorter.  Choose a clear, small scope and refine only that.  Prefer more, smaller meetings over fewer, larger meetings.
• Use online sketching tools, I like Miro.com.
• Planning poker is possible from within Microsoft Teams chat – just type in your estimate.

Retrospective

• Perhaps do this more often – every week instead of every sprint – again keeping it short.
• Start with a check-in “How are you?”
• Begin the retro with a retro on working from home
• Give team building more attention than you already do.
• Make sure of a good vibe, the compliment shower is a good format.  Instead of only improving a process, make the question “how can we make the best of this?”.
• Collect items beforehand, that saves data gathering during the meeting.
• As always: find 1 or 2 concrete improvements for the next sprint.

Microsoft Teams (or other collaboration tool)

• If used properly, this can be your single mode of communication replacing email, Outlook meetings, Whatsapp etc.
• Teams integrates well with external applications like Git or your test tool reporting in separate channels.
• You can invite people in a channel for a meeting, automatically adding it to the team calendar.  This saves you having to invite people separately one-by-one.

Good luck! Any more ideas?

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.

BONUS tip

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.

 

Scrum mastery in corona-tijden

Als gevolg van de corona maatregelen zullen de meeste van onze teams thuis gaan werken. Dat is lastig. Met een heel team op dezelfde werkplek zitten maakt goed scrummen veel gemakkelijker. Er is veel spontane communicatie, we zien elkaar’s non-verbale communicatie, en dat raken we nu kwijt. Dat betekent dat de rol van de scrum master nog veel belangrijker wordt dan deze al was.
Hierbij een aantal praktische tips die wij met elkaar verzonnen. Ik hoor van jullie wel of er nog meer ideeën zijn.

Algemeen

  • communiceer heel erg veel, bel ieder teamlid elke dag even persoonlijk op om te horen hoe het gaat, juist ook privé. Zijn er zorgen rondom corona in het gezin, bij grootouders, etc.
  • het zijn best spannende tijden, mensen zullen meer gespannen zijn dan anders, als scrum master ben je nu vooral vertrouwenspersoon
  • deel de informatie uit je bedrijf over hoe wij omgaan met Corona
  • doe aan verwachtingsmanagement naar je team en naar je stakeholders toe. De velocity zal wel wat omlaag gaan, de moraal in het team misschien ook. Bespreek dit, wees er open over
  • on-line meetings zijn lastiger dan gewone, mensen zijn sneller afgeleid en zo’n meeting is vermoeiender. Benoem dit. Vraag mensen om dingen die afleiden (nu.nl dat open staat, whatsapp, e.d.) uit te zetten tijdens de meeting. Vraag iedereen de camera aan te zetten, zodat je de betrokkenheid, net als in een gewone meeting, kan monitoren.
  • houd je meetings korter dan anders. 1 uur is echt de max!
  • faciliteer wat strakker. Er kan maar 1 persoon tegelijk aan het woord zijn. Er zit vaak wat vertraging in beeld en/of geluid, houd daar rekening mee.
  • gebruik een headset en niet het geluid van je laptop zodat er veel minder achtergrondgeruis is
    thuiswerken biedt een hoop flexibiliteit, als ’s middags de kinderen thuis zijn kan je ook ’s avonds werken. Maar voor de samenwerking is dat allemaal niet zo handig. Maak dat bespreekbaar in je team. Houden we ons aan de gewone kantoortijden? Of in ieder geval ’s ochtends?
  • wij hebben zelf wel goede ervaringen met Microsoft Teams – en Microsoft biedt het op dit moment ook gratis aan. Experimenteer er veel mee als scrum master. Zorg dat je er zo handig mee bent dat de tool een goede meeting niet (of zo min mogelijk) in de weg zit.
  • zet ook een kanaal op in Teams voor het gewone gekwebbel – we blijven gewoon mensen die af en toe een beetje persoonlijk willen ouwehoeren
  • als je Jira gebruikt: de desktop app is vaak veel sneller, en is overzichtelijker dan de web-app

Per Scrum event (een beetje creatief geïnterpreteerd 😉

Sprint Planning

  • zorg, nog meer dan anders, dat je Product Backlog (in Jira of anders) helemaal op orde is. Verdoe de tijd van je team niet met allerlei klein grut. Maar de nieuwe sprint vast aan. Sleep de items die de PO graag wil hebben in deze sprint hier vast naar toe. En heb dan de discussie of dit wel past.
  • zorg dat je de gemiddelde velocity van de afgelopen sprints, en de vakantieplanning van medewerkers paraat hebt, zodat je goed de verwachte velocity voor de komende sprint kan inschatten. Ik vermoed dat deze door veel thuiswerken al snel 10-20% lager zal liggen dan wat je in een co-located team zou halen
  • de Sprint Planning 1 (waar je items van de product backlog de sprint in trekt) is iets dat je echt met het gehele team moet doen
  • Sprint Planning 2 (waar je je detailed design doet en technische taken aanmaakt) kan prima gedaan worden in kleine groepjes of door individuele teamleden. Daardoor kan je de meeting korter en meer gefocust houden

Daily Scrum (aka Daily Standup)

  • het zou kunnen dat je wat meer tijd nodig hebt dan anders, ga wat flexibeler met de 15 minuten timebox om
  • en misschien moet je 2x of 3x per dag een daily scrum doen
  • een check-in, waarin iedereen even vertelt hoe het met hem/haar gaat, voordat je de inhoud in gaat lijkt ons erg nuttig
  • het lijkt nu, nog meer dan anders, nuttig om niet een ‘rondje langs de mensen’ te maken, maar de sprintbacklog te volgen. “Wie heeft er gisteren aan item 1 gewerkt, wie werkt er vandaag aan, wat houdt ons tegen om dit vandaag of morgen naar DONE te krijgen?”. Hierdoor voorkom je dat je continu heen en weer moet scrollen in Jira (of welke sprint backlog tool je ook gebruikt). Nu kan je rustig van boven naar beneden gaan. Dat stimuleert meteen dat mensen swarmen en de belangrijkste items als eerste oppakken. Meer hierover in deze post.

Het gewone werk

  • let erop als scrum master dat er nog steeds veel informeel contact is tussen de teamleden, houd je chat/slack kanalen een beetje in de gaten, is er genoeg communicatie, doet iedereen mee?
  • als er per backlog item geswarmed wordt, zet er een apart kanaal voor op zodat de mensen die aan dat item werken een eigen plekje hebben voor communicatie
  • laat de techniek ook z’n werk doen – koppel een teams kanaal aan Git, zodat je ziet dat er pull requests worden gedaan, koppel aan je test automation framework zodat je ziet dat je tests omvallen

Backlog Refinement

  • houd zeker deze meetings wat korter. Kies een duidelijke, kleine scope, en refine alleen dat. Dus liever wat meer refinement meetings, die ieder wat korter zijn.
  • gebruik on-line tools om te schetsen, ik vind zelf miro.com wel een fijne tool.
  • planning poker kan prima in een microsoft teams chat, iedereen tikt daar gewoon haar geschatte getal in

Retrospective

  • misschien kan je deze iets vaker doen. 1 keer per week in plaats van 1 keer per sprint – en dan uiteraard per keer wat korter
  • start met een check-in, “hoe gaat het met je?”
  • begin de retro met een retro op het thuiswerken
  • geef teambuilding, samenwerking nog meer aandacht dan anders
  • zorg zeker voor een goede sfeer, de complimentendouche is nu zeker een mooie werkvorm – schuif een beetje van procesverbetering naar ‘hoe maken we er het beste van’
  • haal vooraf de punten op die men wil bespreken, dat scheelt wat tijd in de data gathering fase van de retro.
  • en zoals altijd, zorg voor 1 of 2 concrete, kleine verbeterpunten

Microsoft Teams (of een ander medium voor online samenwerken)

  • als je dit goed gebruikt en goed inricht wordt dit je enige communicatiekanaal. Mail, Outlook meetings, Whatsapp worden overbodig.
  • Teams is goed te koppelen met allerlei externe applicaties, dus de status in Git of van je Tests is in een eigen kanaal voor iedereen zichtbaar
  • Je kunt mensen in een kanaal uitnodigen voor een meeting, die staat dan meteen in de team-agenda, en je hoeft niet een voor een de mensen uit te nodigen, iedereen die in het team zit krijgt ‘m vanzelf

Succes ermee! Meer tips?

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.

retrospectives marc quirijnen

Retrospectives en ons brein

In mijn vrije tijd mag ik graag een boekje lezen. Vak gerelateerd boeit me altijd wel, maar literatuur zoals ‘De prestatiegeneratie’ en ‘De edele kunst van Not giving a f*ck’, die lekker tegen de hedendaagse consumptie en prestatie maatschappij aan trappen , spreekt me ook enorm aan. De  must haves van Yuvah Noah Harrari hebben inmiddels ook plaats genomen in mijn boekenkast. Naar aanleiding van zijn boek ‘Homo Deus’, ben ik begonnen aan ‘Ons feilbare denken’ van nobelprijs winnaar Daniel Kahleman. Hier en daar pittige kost, maar ook erg speels door de herkenbaarheid en vele praktische experimenten die voorbij komen.

Tijdens het lezen van dit boek, moest ik geregeld denken aan de wijze hoe retro’s, planning poker en dote voting georganiseerd worden. Waarom ik daar aan dacht? In het boek wordt beschreven dat ons brein verdeeld is in twee systemen, systeem 1 en systeem 2. De meeste beslissingen die je maakt, vinden plaats in systeem 1 en vinden onbewust plaats, zeg maar op de automatische piloot dan wel intuïtie. Dit gaat erg snel en kost ons geen moeite en energie. Voor complexere zaken maken we gebruik van systeem 2 wat bewust plaats vind en meer energie kost. Ergo, autorijden op een lege autoweg, systeem 1. Autorijden in een drukke stad die je niet kent, systeem 2. De som 1 + 1 oplossen, systeem 1. 17 * 24, systeem 2. Bepalen dat een man schilder is omdat hij in witte kleding en een kwast voorbij loopt, systeem 1. De hoogte van een straf bepalen op basis van een politieverslag en huidige strafblad, systeem 2.

Dit klinkt als een logische scheiding en zal voor iedereen wel herkenbaar zijn. Wat echter interessant is, is dat voordat systeem 2 aan het werk gaat, systeem 1 al wat voorwerk heeft gedaan. Daar komt bij dat systeem 2 van nature erg lui is en systeem 1 graag voor waarheid aan neemt, dan wel zwaar mee laat wegen in zijn beslissing. Zeker in het derde voorbeeld wat ik stelde, kan dit voor problemen leiden, waardoor irrelevante zaken, onbewust, te zwaar geen meewegen in een belangrijk besluit. Onze marketing vrienden maken al jaren dankbaar gebruik van deze systemen, waardoor je denkt een overwogen besluit te hebben genomen, maar voor de gek bent gehouden door marketingtrucs die je systeem 1 hebben misbruikt. Ook illusionist Victor Mids maakt hier graag gebruik van in zijn programma ‘Mindf*ck’. Laatste wat je moet weten, is dat systeem 1 gebruikt maakt van referentiekaders, zodat het snel beslissingen kan nemen.

Wat is nu de relatie met retro’s etc.? In dit soort rituelen, moet er eerst individueel nagedacht worden over input (en opschrijven), om vervolgens met de groep de individuele input te bespreken. Hierdoor kan iedereen eerst zijn eigen mening vormen, zonder te worden beïnvloed door collega’s. Echter zie je vaak gebeuren dat teams dit naar enige tijd los laten, omdat ‘we ondertussen wel weten dat we onze eigen mening moeten verkondigen’:

1.      Tijdens sprint planning worden stories direct met de hele groep, eventueel op basis van een story point ruler ingeschat.

2.      Tijdens de retrospective mag om de beurt een teamlid zijn punten benoemen, zonder dat deze eerst worden opgeschreven en verzameld.

3.      Na de retrospective worden om de beurt een teamlid gevraagd zijn of haar stem(men) uit te brengen op de voorgestelde actiepunten

Wat dus echter blijkt, is dat ons brein altijd beïnvloed wordt, door andere meningen. Je systeem 1 zal de meningen van anderen als referentiekader gebruiken en systeem 2 neemt dit over en laat het (te) zwaar meenemen in zijn besluit. Of je dit nu wilt of niet. De valkuil dat de grootste monden de grootste invloed hebben, ligt  hierdoor dus constant op loer.

Een experiment wat je eenvoudig kunt doen om deze theorie te testen, is door aan twee mensen afzonderlijk te vragen hoe oud ze denken Nelson Mandela is geworden.

Vraag aan proefkonijn 2 ‘Is Nelson Mandela ouder of jonger geworden dan 45 jaar, en hoe oud denk je dan?’.

Vraag aan proefkonijn 1 ‘Is Nelson Mandela ouder of jonger geworden dan 105 jaar, en hoe oud denk je dan?’.

De onrealistische leeftijd suggestie die je doet, zal onbewust als referentiepunt gebruikt worden waardoor persoon 1 een hogere schatting af zal geven, dan persoon 2. Vraag tot slot of jouw suggestie een rol heeft gespeeld in zijn antwoord. Nee joh, die was zo onrealistisch. Daar kon ik toch niks mee!

Als je weer een sprint planning of retrospective organiseert of bijwoont en je hecht echt waarde aan het verzamelen van alle individuele meningen in je team, denk dan aan dit verhaal en geef teamleden uitgebreid de tijd en ruimte om eerst zelf een mening te vormen en te etaleren. En doe dat vooral ook als je weer eens met een nieuw paar schoenen in je handen staat en denk zelf te hebben besloten dat het een goede koop is die je niet kunt laten liggen…

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?

Bila’s in een Scrum-team, to do or not to do?

Karin Flanderijn, Scrum Master

Binnen mijn 2 teams, waarbij ik als Scrum Master werk met een (deels) off-shore team, voer ik ook regelmatig bila’s met mijn teamleden. Als Scrum Master coach je natuurlijk het team als geheel maar daar ligt de nadruk op het begin van de sprint tijdens de sprint planning en aan het eind van de sprint tijdens de sprint retrospective. Tijdens deze twee rituelen zorg je tijdens de planning sessie dat het team op één lijn zit en weet wat het doel van de sprint is, dat de userstories duidelijk zijn en dat er een plan van aanpak is. Tijdens de retrospective bespreek je met het team wat er goed ging en wat er nog verbeterd kan worden en maak je hier een plan voor. Maar daarnaast heb je de tijd tijdens de sprint waarin het team gewoon lekker aan het werk is. 

Omdat een deel van mijn team(s) off-shore werken heb je niet het loopje naar het koffiezetapparaat, of het begin van de dag waarop iedereen binnenkomt en je even een praatje maakt of waarbij je tijdens de lunch ook praat over wat je tijdens het weekend hebt gedaan. Als Scrum Master werk ik niet mee aan de inhoud van de userstories waardoor de contacten met het (off-shore) team beperkt is tot de rituelen.

Zoals Lyssa Adkins aangeeft in haar boek “Coaching Agile Teams” vindt coaching plaats op twee niveau’s. Zoals ik hierboven schrijf, vindt de groepscoaching plaats aan het begin en het eind van de sprint. Maar tijdens de sprint is er ruimte voor individueel coaching.

Uit Lyssa Adkins; Coaching Agile teams.

Ik heb met ieder teamlid een moment ingepland waarbij we samen zitten en we kijken hoe het gaat binnen het team. Waarom een ingepland moment? Ik ben van mening dat we op ieder moment een moment kunnen prikken om samen te zitten. Maar omdat sommige van mijn teamleden niet op locatie zitten waardoor je niet altijd ziet dat een teamlid ergens mee zit en de meesten toch redelijk introvert zijn, blijkt dat dit “spontane” moment niet zo vaak voorkomt. Door de momenten in te plannen, nemen we ook daadwerkelijk de tijd om even met elkaar te zitten. En tijdens dit moment hebben we het over allerlei zaken. Hoe gaat het met die persoon binnen  de sprint, binnen het team. Het is het moment om samen te brainstormen over verbeteringen, die dan vaak weer tijdens de retrospective worden ingebracht. En ik vraag input over wat ik, als Scrum Master, nog meer voor het team of die persoon kan doen. Het is tweerichting verkeer. En dit moment kan ook over “privé” dingen gaan. De familie, persoonlijke doelstellingen (al dan niet het gevolg van de doelstellingen die met de teamleider zijn afgesproken), vakanties. Eén van de leukste dingen die ik heb meegemaakt is dat ik een (virtuele) rondleiding heb gekregen in het huis van één van mijn teamleden. Met deze individuele gesprekken probeer ik ook de drempel met mijn team laag te houden en te zorgen dat iedereen zich vrij voelt zich met allerlei kwesties tot mij te richten. En is er niets te bespreken, dan is de expliciete afspraak dat iedereen vrij is om deze afspraak af te zeggen.

Binnen het team hebben we alleen wel gezocht hoe we dit moment moesten noemen. Een bila klinkt toch als een overleg tussen een manager met één van zijn teamleden. Een coaching gesprek klinkt weer zo zwaar. Omdat we het informele karakter willen benadrukken en het gesprek bij het koffiezetapparaat willen “nabootsen”, hebben we er binnen mijn teams voor gekozen om dit moment “koffietijd” te noemen. Wat denken jullie, doen jullie dit soort gesprekken ook met je (off-shore) teamleden en zo ja, hoe noemen jullie dan dit moment?