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?

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?

Hoe kan je het beste de stap maken van tester/ontwikkelaar naar scrum master?

Rene de Leijer, scrum master bij Valueminds:

‘Het is natuurlijk niet zo dat je na het behalen van je scrum examen meteen aan de slag kan als scrum master. Volgens mij kan je dit het beste als volgt aanpakken:

  • Zorg dat je zeker weet dat je scrum werken ‘voelt’. Het is geen kwestie van het scrum trucje toepassen, je moet zeker weten dat dit de manier van werken is waar jij achter staat. Dit gebeurt niet in 1 dag of na een paar dagen training, ik heb zelf 4 tot 6 maanden intensief met een agile coach gewerkt en dit was voor mij echt een eye opener: zo wil ik werken!
  • Vallen en opstaan is onvermijdelijk. Zoals bij alle nieuwe dingen waar je mee start, ga je in je nieuwe rol als scrum master vast en zeker fouten maken. Maar hier leer je weer van en zo kom je iedere sprint een beetje beter in je rol. Lef hebben om fouten te maken is onderdeel van het scrum werken.
  • Wanneer je start als scrum master zal je vast veel vragen hebben. Het is fijn als er een agile coach of ervaren scrum master is waar je af en toe mee kan sparren en van kan leren.
  • Houdt ons in de gaten😊: we zijn bij Valueminds bezig met het opstellen van een to-do list voor starten scrum masters, hierover horen jullie later meer!

Hoe denken jullie over dit statement? Is het combineren van de rol van teamlid en scrum master wel/niet verstandig?’