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.


• 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
• Planning poker is possible from within Microsoft Teams chat – just type in your estimate.


• 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.


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.


  • 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 ( 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 wel een fijne tool.
  • planning poker kan prima in een microsoft teams chat, iedereen tikt daar gewoon haar geschatte getal in


  • 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?

Een goed begin: het einde van het begin

Dit is het vervolg op Een goed begin: het verhaal in kaart, dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

De vorige oefening eindigde met een story map. Bijzonder nuttig en prettig, maar hoe hier een begin mee te maken? Ik legde uit dat we eerst een tussenstap gingen maken, voordat we dit gingen bepalen.

Done? Or Done?

Wanneer is iets klaar?

Leuk, al die kleine brokjes werk, maar wanneer zijn deze af? Hier geeft de Definition of Done (DoD) antwoord op. Ik legde uit dat dat zij als team deze zelf mochten definiëren. Ik gaf een aantal voorbeelden:

  • Het ontwerp is aangepast
  • De code is gereviewed
  • De user story is getest
  • De documentatie is bijgewerkt
  • De Product Owner is akkoord

Ik vroeg elk teamlid de volgens hem/haar 3 belangrijkste elementen van een DoD te noteren op een post-it. Dit was binnen 5 minuten gebeurd. Daarna mocht het team dot-voten, waarbij ieder teamlid 3 stemmen kreeg. Hiermee probeerde ik De DoD – initieel – klein te houden. Bij uitzondering gaf ik ook een stemadvies mee: “Let op: de DoD werkt als een ‘kwaliteitslat’. Deze leg je jezelf op. De lat verhogen kan altijd en een start maken als team is al lastig zat. Leg de lat daarom niet te hoog voor jezelf”.

Dit werd goed begrepen en de uitslag van de stemming leverde vrij weinig discussie op. De DoD was daarmee vastgesteld.

Inschatten maar

Terug naar de story map. Nu we hadden vastgesteld wanneer een user story klaar was, konden we de stories gaan inschatten om een gevoel te krijgen bij de grootte hiervan.

Om het makkelijk te houden, hanteerde ik de volgende groottes: Small, Medium en Large. Wat dit was, wisten we alleen nog niet. Daarom vroeg ik het team om een van de kleinste stories aan te wijzen op de story map. Deze kreeg een ‘S’. Idem voor een van de grootste en een gemiddelde.

Een S, M en L geïdentificeerd

De rest was een simpele kijk-en-vergelijk met deze drie ijkpunten. Ik ging van linksboven naar rechtonder alle user stories langs en vroeg het team telkens: ‘Is deze user story small, medium of large?’. Een enkele keer heb ik vragen/discussies moeten afkappen en de vraag moeten herhalen. Na 15 minuten zwoegen waren alle user stories ingeschat.

Allemaal ingeschat

De eerste sprint

Nu hadden we genoeg informatie om te bepalen wat we zouden gaan doen in de eerste sprint. Ik gaf de eerste zet aan de Product Owner. Hij mocht stemmen welke user stories hij graag opgepakt zou zien door het team. Ik gaf hem de volgende voorwaarden mee, allemaal met het idee de eerste sprint haalbaar te houden:

  • Slechts 5 stemmen. Dit hield de stories voor de eerste sprint beperkt.
  • Alleen stemmen op user stories in de eerste rij. We hadden niet voor niets de user stories op logische volgorde gehangen.
  • Alleen stemmen op user stories met een S. Kleine user stories zijn meestal makkelijker.

De 5 keuzes van de PO

De volgende zet was aan het team. Ten opzichte van de oefening met de elevator pitch waren de rollen nu omgedraaid. De wensen van de PO waren slechts wensen. Het was nu aan het team om een aantal user stories te kiezen voor de volgende sprint.

Het was leuk om te zien wat hier gebeurde:

  • Het team nam niet het advies van de PO 1-op-1 over. Aan sommige user stories wilden ze liever nog niet beginnen. Ik scoorde opnieuw een goede balans in de verhouding PO – team.
  • Het team zorgde voor voldoende werk voor alle teamleden (het team had enkele specialisten aan boord).

De keuzes van het team (vierkant omlijnd).

Daarmee hadden we een mini-sprintplanning gedaan! Ik feliciteerde het team met het resultaat en de wijze waarop ze dit met elkaar hadden gedaan (en zag dat ze er zelf ook wel tevreden en een beetje trots op waren).

Tot slot

Het was tijd geworden om af te sluiten. Het programma was op, maar de energie ook. Ik hield de afsluiting daarom super-kort (maar krachtig!).

Als eerste keken we terug op wat we wilden leren. Met zijn allen stonden we rond het brown-paper met de post-it’s met leerpunten. Een voor een haalde iedereen zijn geleerde punten weg. Slechts een paar leerpunten bleven over. Deze waren relatief technisch/inhoudelijk van aard. We spraken uit dat we deze punten in de eerste sprints waarschijnlijk gaandeweg zouden gaan leren.

De allerlaatste oefening vond plaats in een grote kring. Ik vroeg alle teamleden terug te kijken op de afgelopen dagen en hun gedachten te delen in één woord. Ze mochten dit woord toelichten, maar dat hoefde niet. Uit de reacties kon ik merken dat iedereen de dagen bijzonder waardevol had gevonden en graag aan de slag wilde gaan.

En dit was nog maar het begin.

Dit was het laatste deel in deze serie. Zonder te overdrijven: een betere investering voor een goed project heb ik in de afgelopen 15 jaar nog niet eerder meegemaakt.

Een goed begin: het verhaal in kaart

Dit is het vervolg op Een goed begin: Wat houdt je wakker? dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

In de vorige oefening haalden we de ‘ja-maars’ uit het team en maakten we hiervan gedeelde zorgen. We konden weer verder waar we gebleven waren: ‘Ok, en hoe gaan we dat dan doen?’. Om dat te bepalen, heb ik het team – in 3 stappen – een story map in elkaar laten zetten.

Stap 1: Van grote naar middelgrote brokken werk

Ik legde het team uit dat we een story map gingen maken, om beter zicht te krijgen op onze scope voor de komende maanden. Ik legde uit dat we dit stap voor stap gingen doen, kennis van wat een story map is, was dus handig, maar niet nodig.

De ‘epics’.

Voor een snelle start, had ik alvast gekeken naar wat het team in scope had gezet voor de komende maanden. Daaruit had ik een aantal grote brokken werk geïdentificeerd. Ik vroeg het team deze grote brokken werk te verdelen in middelgrote brokken. Per grote brok werk, minimaal 2, maximaal 7 middelgrote.

Ik kreeg direct vragen of dit dan epics en features waren en hoe we die dan definieerden. Ik was blij met deze voorkennis, maar ik had geen trek in een discussie over definities. Ik gaf daarom aan dat je dit zo zou kunnen zien, maar dat dit voor nu niet van belang was.

Na enige aarzeling kwam het team op gang, maar binnen een paar minuten was het al weer gebeurd:

Nu met ‘features’

Stap 2: Van middelgrote naar kleinste brokken werk

In deze stap vroeg ik het team alle post-it’s uit de vorige oefening een plek te geven onder een middelgrote brok werk. Dit pakte het team snel op en was zo gebeurd:

Nu met ‘Stories’

Twee nieuwe inzichten:

  • Enkele kleinste brokken werk bleken nergens te ‘passen’. Het team besloot hiervoor een extra grote brok werk te definiëren, inclusief onderliggende middelgrote brokken werk.
  • Sommige middelgrote brokken werk hadden geen kleinste brokken werk. Dat werd direct door het team opgemerkt (“Wat moeten we daarmee?” – “Goed gezien, daar komen we zo aan toe.”).

Voor we verder gingen naar de volgende stap, vroeg ik ze om de kleinste brokken werk op volgorde te zetten: de brokken werk die het eerste uitgevoerd moesten worden/het kleinste waren/het meest duidelijk waren bovenaan, de brokken werk die als laatste uitgevoerd moesten worden/het grootste waren/het meest onduidelijk waren onderaan. Dit was zo gebeurd, o.a. omdat ik had aangegeven dat ‘ongeveer’ goed genoeg was.

Stap 3: Kleinste brokken werk aangescherpt

Ik legde het team uit dat we de story map nu compleet gingen maken. Ik vroeg ze ieder een eigen kolom in de story map te kiezen en voor deze kolom te gaan staan, zodanig dat er een halve cirkel rond de story map zou ontstaan. Daarna vroeg ik ze om ‘hun’ kolom kritisch te bekijken. Alles mocht: post-it’s erbij plakken, herschrijven, splitsen of zelfs verwijderen. Ik gaf ze 2 minuten per kolom en liet ze daarna ‘doordraaien’.

In het begin waren ze nog redelijk voorzichtig, maar na een paar keer doordraaien ontstond er al meer initiatief (“Mag ik deze post-it aanpassen?” – “Natuurlijk. Maar misschien kan het geen kwaad hierover even te overleggen met iemand.”). Zo ontstonden er kleine gesprekken over de scope van sommige post-it’s en hoe deze beter te definiëren.

Na ongeveer 20 minuten was dit het resultaat:

En nu helemaal compleet

Deze oefening maakte, nog sterker dan de oefening waarbij de scope voor het eerst werd bepaald, dat het team echt zélf bepaalde wat er allemaal moest gebeuren. Ik zag in deze oefening voor mijn ogen gebeuren dat het team zich het werk toe-eigende. Daarmee waren ze klaar voor de volgende stap.

Een goed begin: Wat houdt je wakker?

Dit is het vervolg op To do, or not to do? dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

In de vorige oefening koos het team de scope voor het minimal lovable product over 3 maanden. De volgende logische stap zou zijn: ‘Ok, en hoe gaan we dat dan doen?’. Maar voordat we die stap zouden gaan nemen, was er een belangrijke tussenstap te zetten. Je zou dit de ‘ja-maar’ stap kunnen noemen.

In de allereerste kennismaking waren we er al achtergekomen dat het team stikte van het Insights consciëntieuze blauw. Mensen met dit profiel zijn van nature gericht op de details, al kunnen ze daar ook verstrikt in raken. Deze mensen zijn bij uitstek geschikt voor de luis-in-de-pels rol, de mensen van de ‘ja, maar…’.

En de details, die ontbraken natuurlijk volledig in de elke oefening die we deden. Die passen simpelweg nooit op een post-it. Dat is voor de oefening natuurlijk precies de bedoeling, omdat zo de snelheid erin blijft. Daarom was het tijd voor een moment van vertraging. Tijd voor de ‘ja, maar…’.

Ik hield ze daarom het volgende voor: “Ik neem jullie mee naar een donkere toekomst. Stel je voor: we hebben met zijn allen een aantal maanden keihard gewerkt. Misschien wel een jaar lang. Maar dan wordt dit project gestopt. Dat was onvermijdelijk, want het is gruwelijk mis gegaan. De vraag is nu ‘Wat heeft er voor gezorgd dat het zo gruwelijk is misgegaan?”

Met deze oefening vroeg ik om ze ‘terug’ te laten kijken op het nu vanuit een denkbeeldige toekomst. Dat was voor niet iedereen even makkelijk. Daarom voegde ik een alternatief toe: “Vind je dit een lastige vraag, dan mag je hem ook anders benaderen: Stel dat dit project hopeloos mis zou gaan, waar zou dit dan aan liggen?”

De rest van de oefening was eenvoudig: na ongeveer 5 minuten hing er een bonte verzameling van post-it’s op de wand. Deze mochten ze groeperen, en daarna mochten ze dotvoten met zo veel stemmen als ze wilden. In de pauze naar de volgende oefening hing ik de post-it’s vervolgens van links naar rechts op volgorde van het aantal stemmen dat ze hadden gekregen.

In de dagen, wekend en zelfs maanden die volgden, was deze ‘slinger’ een goed aanknopingspunt voor een gesprek. We wezen ernaar als we een zorg in de praktijk hadden gezien, we een maatregel besproken, of juist wanneer deze zorg (gelukkig!) zich niet voordeed.

Ter afsluiting nog twee dingen die we niet hebben gedaan tijdens de oefening (en die mij goed zijn bevallen 😊).

We hebben niet over risico’s gepraat. Zodra je over risico’s gaat praten, kan het namelijk heel goed gebeuren dat het meer theoretisch wordt dan praktisch, meer over de risico’s buiten het team, dan in het team, meer over wat er mis kan gaan bij de ander, dan bij jezelf. We hebben het daarom niet over de risico’s gepraat, maar onze eigen zorgen. En aan een oprechte zorg vanuit jezelf, daar doet niemand wat aan af.

Wat we ook niet hebben gedaan, is over risico-mitigatie gepraat. Daar ga je het over hebben, als je risico’s wilt voorkomen of de effecten van de risico’s wilt verminderen. Maar daar ging deze oefening helemaal niet over. Het doel van deze oefening was om zo eerlijk en transparant mogelijk elkaars zorgen te delen. Op die manier worden het gezamenlijke zorgen. Het dealen met deze zorgen wordt dan een teamaangelegenheid en komt dan echt wel goed.

Een goed begin: To do, or not to do?

Dit is het vervolg op Een goed begin: het product dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

Okay, het team heeft duidelijk zicht gekregen op de klanten en met de elevator pitch en de product box duidelijk gemaakt wat het product gaat worden. Tijd voor de volgende stap.

Ik vertelde het team dat we de focus gingen verleggen van het uiteindelijke product over ongeveer 1,5 jaar, naar een meest basale versie hiervan (voor de liefhebbers: een minimum viable loveable product) over 3 maanden. Ik gaf aan dat zij hiervan de scope gingen bepalen.

Ik vroeg ze te putten uit de informatie die ze hadden opgedaan uit de interviews, de elevator pitch en de product boxes. En natuurlijk hun eigen ervaring & expertise. In een aantal rondes kwamen we tot deze scope.

Ronde 1: Verzamelen

Iedereen kreeg van mij de bekende gele post-its, deze keer met een velletje groene en rode stickers. Ik vroeg ze zo veel mogelijk dingen te bedenken die volgens hen wel en niet in scope zouden moeten zijn voor de komende 3 maanden.

Ik vroeg ze de post-its te voorzien van een groene of rode sticker, afhankelijk van of ze vonden dat het wel of niet in scope zou moeten zijn. Dit alles gebeurde in stilte.

Na 5 minuten hing er een wand vol met post-its, kris-kras door elkaar, zowel qua onderwerp als qua wel/niet in scope.

Ronde 2: Groeperen

Vervolgens vroeg ik het team de post-its te groeperen op onderwerp, zonder te letten op de kleur van de stickers. Dit gebeurde weer in stilte.

Ronde 3: Bepaling scope – zonder discussie.

Nu hing de wand geordend in groepen van verschillende groottes. Op een andere plek op de wand had ik 3 kolommen gemaakt die aangaven of iets in scope is, uit scope, of nog onbeslist.

Ik vroeg het team de groepen post-its te bekijken en deze te verplaatsen naar een van deze 3 kolommen. Groepen van post-its met uitsluitend groene of rode stickers mochten naar de groene of rode kolom. Groepen van post-its met zowel groene als rode stickers mochten naar ‘?’.

Dit leidde er toe dat één hele grote groep post-its alsnog werd opgesplitst in kleinere groepen. Deze kleinere groepen werden vervolgens verplaatst naar een van de drie kolommen.

Ik vond het opvallend dat maar ongeveer 10% van alle post-its in de ‘twijfel’ kolom waren beland. Blijkbaar zat het team al goed op één lijn. Ik benoemde dit en vertelde dat we het over al de (groepen) post-its in de linker en rechter kolom niet gingen hebben. Daar waren we toch al over eens!

Ronde 4: Bepaling scope – met discussie

Nu restte ons nog de ‘?’ kolom van de wand. Ik vroeg aan het team te kijken of ze hun eigen post-it(s) herkenden en zo ja: naar voren te komen en uitleg te geven over de reden voor een groene of rode sticker.

Heel bewust gaf ik hierbij geen instructie over hoe de discussie gevoerd moest worden en wie hierbij de doorslaggevende stem had. Ik wilde – zonder het te benoemen – laten zien hoe belangrijk het is om initiatief nemen en je uit te spreken.

Even gebeurde er niets, en toen stapte de PO naar voren en begon de briefjes langs te lopen. Voor mij een goed moment om te kijken of PO en team goed met elkaar overweg zouden kunnen. Gelukkig sprak iedereen zich uit en werd er in het overgrote deel van de gevallen snel consensus bereikt. Over een enkel onderwerp bleef verschil van mening. Op mijn voorstel werden die discussies geparkeerd tot een later moment waarop we meer zouden weten.

In 60 minuten heeft het team zélf de scope vastgesteld voor de komende 3 maanden. Ik zag volop het nemen van verantwoordelijkheid en eigenaarschap in actie. Door de discussies kreeg het team inzicht in elkaars expertise en bouwde het zo aan onderling vertrouwen.

Deze oefening vond ik – by far – de spannendste. Tot nu toe kon je de oefeningen nog afdoen als spielerei, dit ging om scherpe keuzes maken. Wat als het team geen keuze durft te maken? Wat als het één grote discussie zou worden? Naar mijn mening zijn discussies onvermijdelijk en zijn deze het gemakkelijkst in het begin te voeren. Gelukkig had ik de Product Owner hierin helemaal mee en pakte de oefening goed uit. Aan de andere kant: als de oefening was ‘mislukt’ had dat gelijk ook een heleboel duidelijk gemaakt.

Een goed begin: Het product

Dit is het vervolg op Een goed begin: de collectieve ambitie dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

Okay, dus het team weet waarom ze er zijn, wie de klant is en wat ze de klant willen bieden. Tijd om deze collectieve ambitie concreet te maken. Daarvoor heb ik het team twee oefeningen laten doen.

De elevator pitch

Het team kreeg de opdracht om een elevator pitch op te stellen, op basis van wat ze tot nu toe hadden geleerd. Om ze te helpen, gaf ik een voorbeeld…

… en een A3 formaat papier met daarop het formaat voor de elevator pitch (download docx, pdf) inclusief kleine toelichting:

  • Voor <klant>
  • Die <behoefte van de klant>
  • De <naam van het product>
  • Is een <soort product>
  • Dat <waarde van het product>
  • In tegenstelling tot <product(en) van de concurrent(en)>
  • Ons product <grootste verschil met product(en) concurrent(en)>

In 4 rondes kwamen we tot 1 elevator pitch (Liberating Structures fans: yep, dit is een variant van de 1-2-4-all):

Ronde 1 – Singles

Elk teamlid mocht eerst zelf aan de slag met zijn/haar elevator pitch te maken. Ik drukte ze op het hart om te focussen op kwantiteit (zo veel mogelijk onderdelen invullen), niet op kwaliteit (het zo goed mogelijk invullen). Deze ronde gebeurde in stilte. Hier kregen ze 5 minuten voor.

Ronde 2 – Duo’s

Elk teamlid mocht een ander teamlid opzoeken, de elevator pitches met elkaar delen en vervolgens komen tot één nieuwe. Hier kregen ze 7,5 minuut voor.

Ronde 3 – Kwartetten

Elk duo mocht een ander duo opzoeken, de elevator pitches opnieuw met elkaar delen en weer komen tot één nieuwe. Hier kregen ze 10 minuten voor.

Ronde 4 – Keuze PO

Dit resulteerde uiteindelijk in 3 elevator pitches van teams van 4 personen. Deze 3 hingen we op en vervolgens mochten alle teamleden gaat stemmen door middel van dot-voting: 1 stem op de elevator pitch die ze het beste vonden en 1 stem op een deel van een andere elevator pitch die ze goed vonden.

Vervolgens legde ik uit dat het resultaat van deze stemming een advies was aan de PO. Niets meer, maar ook niets minder. Ik vroeg de PO een definitieve elevator pitch te maken en misschien nog wel belangrijker: zijn keuzes uit te leggen. De PO koos er vervolgens eentje uit en gebruikte schaar en plakband om een deel van een andere elevator pitch over de gekozen pitch te plakken:

Het eindresultaat

Al met al koste deze oefening tussen de 30 en 45 minuten. In die tijd heeft heel het team elkaar geholpen te begrijpen hoe het nog te ontwikkelen product moet worden om aan de wensen van de klant te voldoen. Als bonus was dit een mooie oefening in de communicatie tussen team en PO.

Vooraf was ik er een beetje bang voor dat deze oefening te lastig zou zijn voor sommige mensen, omdat dit bepaald geen dagelijkse kost voor ze is. En inderdaad, sommigen hadden meer moeite dan anderen, en kregen de elevator pitch niet helemaal ‘ingevuld’. Dat bleek alleen helemaal niet erg, want dit werd keurig in de rondes 2 en 3 met de duo’s en kwartetten opgelost.

Deze oefening viel vooral goed bij de teamleden die liever woorden hebben dan beelden, liever structuur dan creativiteit. En daarom, als tegenhanger van de elevator pitch …

4. De Product Box

Voor de volgende oefening nam ik het team mee naar een prachtige toekomst: “Iedereen heeft hard gewerkt, we zijn klaar en trots op ons product. Er is alleen nog één dingetje: we moeten het nog verkopen :). Het product komt ouderwets in de schappen te staan, of misschien wel in de etalage. Dat vraagt om een goede verpakking. Die verpakking gaan wij nu maken.”

Het team mocht zelf groepjes maken van ongeveer 4 personen. Mijn enige verzoek hierbij was op deze teams zo divers als mogelijk te maken. Expres gaf ik niet aan wat ik precies bedoelde met divers. Hiermee wilde ik zelforganisatie stimuleren en werken aan teambuilding, juist tussen teamleden die elkaar nog minder goed kenden. Dit ging erg makkelijk.

Aan de product box stelde ik de volgende eisen:

  • Moet de 3 belangrijkste redenen bevatten waarom klanten het product zouden moeten kopen
  • Moet een one-liner hebben, hoe cheasier hoe beter
  • Moet minimaal 1 plaatje of tekening hebben

Van te voren had ik de Action geplunderd en allerlei eenvoudige knutselmaterialen meegenomen: potloden, stiften, gekleurd papier, lijm, scharen en gekleurde linten. Ook had ik links en rechts wat kranten en tijdschriften verzameld. En natuurlijk had ik een aantal dozen van verschillende formaten meegenomen.

Nadat elk groepje klaar was, mochten ze hun eigen product box presenteren. Bij de presentatie viel het op dat het uiterlijk van de dozen zeer verschilden, maar dat de producten die ‘er in zaten’ juist erg overeen kwamen. Deze overeenkomsten werd ook door het team opgemerkt.

Het eindresultaat

Ik zag dat de teamleden ouderwets knutselen alsof ze weer op de basisschool zaten. Tijdens het geknutsel werd er gelachen, verder kennis gemaakt en serieus nagedacht over waarom dit product het beste product ooit zou worden. Dit keer waren het de visueel creatief ingestelde mensen die helemaal los konden gaan.

Van te voren was ik er een beetje bang voor dat deze oefening als ‘te kinderachtig’ zou worden opgevat door een aantal mensen. En inderdaad, niet iedereen kon goed met de oefening uit de voeten. Dat bleek alleen helemaal niet zo erg, want in elk groepje zat minimaal één enthousiaste knutselaar die aanstekelijk werkte op de rest.

Een goed begin: De collectieve ambitie

Dit is het vervolg op Een goed begin: plezierig ongemakkelijk dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

Okay, dus iedereen in het team kent elkaar inmiddels (een beetje) en voelt zich (licht) met elkaar verbonden. Mooi. Tijd voor de volgende stap.

Waarom zijn we eigenlijk bij elkaar?

Een echt goed product maken, kan alleen als je weet waarom je het product aan het maken bent. Dit onderdeel gaf het team de broodnodige context, zeker voor de teamleden die nog weinig bekend waren met het domein.


Ik heb de manager van de PO gevraagd of hij kort aan het team wilde uitleggen waarom we eigenlijk bij elkaar waren gezet. Hij verraste ons met een enthousiast verhaal over de ontwikkelingen tot nu toe, zijn visie op het nieuwe product, hoe blij klanten hiermee zouden zijn en zijn vertrouwen in dit team. Door vragen vanuit het team ontstond een mooi gesprek.

Al met al kostte dit ons nog geen 30 minuten. In die tijd werd voor iedereen duidelijk waar het in de kern van de zaak om ging. Ik zag dat een heel aantal teamleden al een stuk verder naar voren op hun stoel zaten dan in het begin.

Voor wie zijn wij eigenlijk bij elkaar?

De uitdrukkelijke wens van de PO en zijn stakeholders was het ontwikkelen op basis van klantfeedback. We vonden het daarom erg belangrijk om het team onze klanten te laten leren kennen. Dit hebben we in twee delen gedaan.

Deel I: Luisteren naar klantonderzoek

In het eerste deel presenteerde de productmanager enkele generieke kenmerken van het product en hoe deze in het algemeen wordt gebruikt. Ook kwamen er 3 persona’s voorbij. Dit leverde enkele vragen op bij het team, maar niet veel.

Dit onderdeel duurde zo’n 20 minuten en zorgde ervoor dat het team een eerste begrip kreeg van behoeften en wensen van de verschillende klantgroepen en de verschillen in deze groepen.

Deel II: Zelf op klantonderzoek

In het tweede deel zoomden we in op één van de klantgroepen en interviewden we hiervan een aantal klanten telefonisch. Het team kreeg de opdracht om tijdens het interview op zoek te gaan naar antwoorden op de volgende vragen*:

  • Wat heeft de klant nodig?
  • Wat bieden wij de klant nu al?
  • Wat kunnen we de klant nog beter/meer bieden?

Deze vragen dienden twee doelen: richting geven aan het interview en het team voorbereiden op de volgende oefening.

De productmanager trapte het interview af en het team kon op elk moment zelf ook een vraag stellen. Diverse teamleden grepen deze kans. De teamleden die dat niet deden, luisterden aandachtig.

Dit onderdeel koste in totaal 45 minuten (15 minuten per interview) met een fantastisch resultaat: het team had een goed beeld van de wensen en behoeften van echte (!!) klanten. Ook de teamleden die alleen hadden geluisterd naar het interview, waardeerden dit onderdeel van het programma enorm.

Collectieve ambitie

Een goede reden om een groot project te beginnen en echte klanten waarvoor je het doet, zijn in mijn ogen onmisbaar voor een nieuw team. Stiekem – of eigenlijk heel openlijk – krijgt het team een collectieve ambitie. En deze collectieve ambitie is nodig om het zelfsturend team langdurig en met plezier te laten vlammen!

Een goed begin: plezierig ongemakkelijk

Dit is het vervolg op Een goed begin: focus en energie dat gaat over mijn ervaringen bij het opstarten van een nieuw project.

Waar begin je een goed begin mee? ‘Start with why’, hoor ik de Simon Sinek fans al roepen. Goed idee, maar daar hadden de kersverse teamleden al wel een aardig idee bij. Een op dat moment belangrijkere vraag was ‘met wie?’. Voor de Agile Manifesto mensen onder ons: ‘Mensen en interacties’.

In mijn team kenden sommige mensen elkaar wel, sommigen een beetje, en anderen kenden nog niemand. In mijn ervaring komt echte onderlinge interactie komt pas op gang, wanneer mensen elkaar kennen en zich bij elkaar op hun gemak voelen.

Daarom hebben we een volledige dag besteed aan het elkaar leren kennen. Iemand van buiten het team, die dit wel vaker deed, heeft ons daarbij begeleidt. Zo konden we allemaal, ook ik als Scrum Master, deelnemer zijn. Een greep uit de activiteiten:

  • Op de grond lagen een hele berg ansichtkaarten. De opdracht: kies er eentje en vertel op basis daarvan iets over jezelf. Tien keer beter dan het bekende ‘voorstelrondje’. Maakte de boel mooi los.
  • We werden in twee cirkels geplaatst, met de gezichten naar elkaar toe. Vervolgens gingen we elkaar tekenen. Iedereen deed een stuk (bijv. vorm gezicht, ogen, mond, haren, etc.) en schoof daarna een plekje door in de cirkel (lijkt erg op Collaborative Face Drawing). Licht ongemakkelijk en bijzonder vermakelijk tegelijkertijd.
  • Onze ‘kunstwerken’ werden aan de muur gehangen met daaronder de kwadranten van het DISC model. Aan ons de vraag om bij elk teamlid een sticker te plaatsen in het kwadrant waarin wij ons teamlid inschatten. Leuk om te zien hoe anderen je zien, ook al ken je elkaar eigenlijk nog nauwelijks. Gaf ook gelijk een goed ‘plaatje’ van de groep.

  • Op een groot vel stonden al onze namen. Ons werd gevraagd om op post-its op te schrijven wat we wilden leren in de rest van de week. Deze post-its plakten we naast onze namen. Hiermee sloegen we 3 vliegen in 1 klap: iedereen ging bewuster de rest van het programma in en we kregen inzicht in elkaars interesses. Aan het einde van het programma zijn we hierop teruggekomen.
  • ’s Avonds hebben we uitgebreid met elkaar gedineerd en gingen we blij en met energie naar huis, nieuwsgierig naar wat de volgende dag ons zou brengen.

Mijn ervaring: het maakt eigenlijk weinig uit wat je met elkaar doet, zolang de activiteiten maar het effect hebben dat mensen zich zodanig veilig voelen, dat ze (een stukje van) zichzelf durven laten zien en de verbinding met de ander zoeken.

Een betere investering voor een goed project heb ik nog niet meegemaakt.