Vergroot je transparantie (2)

Dit is mijn tweede blog over het belang van transparantie. In mijn vorige sprak ik over een voor mij nieuw fenomeen: de scope governance board.

Transparantie is cruciaal voor het succes van organisaties en groepen die Agile omarmen. In Scrum hebben we ook de Scrum gebeurtenissen die helpen bij transparantie, waaronder de Daily Standup, Sprint Planning, Sprint Review en Retrospective-vergaderingen. Deze events geven Developers, Product Owner en andere stakeholders de kans om problemen aan de te bespreken en eerlijk en open te zijn. De events geven het Scrum team ook de kans om zich aan te passen en te verbeteren.

Waarom is transparantie zo belangrijk in agile?

Transparantie in Agile kan niet worden overschat. In sommige organisaties is het niet eenvoudig om transparant en open te zijn. Er is veel druk om te zeggen wat het bedrijf wil horen. Maar ik geloof dat een gebrek aan transparantie op de lange termijn een Agile-team, het project, de organisatie en uiteindelijk het bedrijf schaadt.

Gebrek aan transparantie heeft in mijn ogen een negatieve impact. Anders gezegd, transparantie draagt bij aan openheid, respect en vertrouwen, niet alleen binnen teams, maar ook tussen teams. Ik geloof daar enorm in.

Vergroot transparantie in de scrum events

Er zijn verschillende stappen die een team kan nemen om de transparantie in het (Scrum) team te vergroten.

Daily scrum

In de Scrum Guide (2020) staat het volgende over de Daily en de aanwezigheid van andere rollen dan de Developers:

“De Daily Scrum is een gebeurtenis van 15 minuten voor de Developers van het Scrum Team. Om complexiteit te verminderen, wordt het elke werkdag van de Sprint op dezelfde tijd en op dezelfde plaats gehouden. Als de Product Owner of Scrum Master actief werken aan items in de Sprint Backlog nemen ze deel als Developers.”

Met andere woorden, het is een event voor de Developers en mensen die actief werken aan het Sprint Backlog. Zo kan er direct worden ingespeeld op eventuele miscommunicaties, afhankelijkheden en het delen van best practices. Komen er zaken naar boven waarop ingespeeld moet worden, dan kunnen de mensen die daarbij betrokken zijn na de Daily samen het gesprek voortzetten. Zo houd je de Daily effectief, maar hou je ook de lijntjes kort en voorkom je onnodige werkzaamheden en miscommunicaties. In het geval dat de Scrum Master en de Product Owner niet actief deelnemen aan het Backlog, is dit event dus ook niet voor hun bedoeld.

Toch heeft het voordelen om als Product Owner en Scrum Master je aan te sluiten bij de Daily. Uiteraard is het hierbij wel van belang dat deze rollen zich niet gaan bemoeien met de inhoud en het ‘hoe’ van de uitvoering van het werk. Dat blijft tenslotte het inspectie moment van developers en mensen die actief werken aan de Sprint Backlog.

Sprint planning

De Scrum Guide (2020) zegt het volgende over de Sprint Planning:
Het Scrum Team mag ook anderen uitnodigen om de Sprint Planning bij te wonen als adviseur.

Nodig mensen uit van andere afdelingen of teams die afhankelijkheden hebben met het product dat je bouwt wanneer een relevant onderwerp wordt besproken in de Planning of de refinement. Dit vergroot niet alleen je transparantie over waar jullie aan werken, leidt ook tot kortere lijntjes en betere samenwerking. De kracht is het gezamenlijk bouwen aan een gedeeld beeld van hoe de komende sprint eruit ziet.

Product- & sprint backlog

Beide Backlogs representeren een lijst met werk wat gedaan moet worden voor het te bouwen product. De Product Backlog bevat de wensen voor de toekomst. De Sprint Backlog bevat de wensen het team deze sprint gaat realiseren.

Er zijn verschillende manieren waarop je deze informatie beschikbaar kunt stellen:

Geef iedereen die belang heeft bij jullie werk kijkrechten (en vooral niet meer dan dat!) in jullie digitale Product- en Sprint Backlog.
Hang het Sprint Backlog op (of zet een scherm neer waar deze digitaal wordt getoond) in de ruimte waar jullie samenwerken. Maak de Sprint Backlog visueel zodat je team het dagelijks ziet. Het voordeel is dat iedereen binnen kan lopen om te kijken waar jullie aan werken zonder dat ze dit de developers hoeven te vragen. Uiteraard voegt dit weinig waarde toe in deze tijd waarin bijna iedereen thuiswerkt. Bedenk dus of dit op dit moment bij jullie past of dat een andere manier beter bij jullie past.
Stuur een nieuwsbrief uit! Na de planning dicht je een mailtje waarin je deelt waar het team aankomende sprint aan gaat werken. En als je dan toch aan het dichten bent, vinden de belanghebbenden het zeker ook leuk om te horen wat de resultaten van de afgelopen sprint waren en of er nog belangrijke updates uit voortkomen!

Ik hoop dat ik jullie heb kunnen inspireren je transparantie zowel in het team als daarbuiten te vergroten. En natuurlijk ben ik ook benieuwd, wat zijn jullie succesfactoren in het vergoten van transparantie?

Vergroot je transparantie

Transparantie is cruciaal voor het succes van organisaties en groepen die Agile omarmen. De Scrum gebeurtenissen die helpen bij transparantie, waaronder de Daily Standup, Sprint Planning, Sprint Review en Retrospective-vergaderingen. Deze geven de Developers en de Product Owner allemaal de kans om problemen aan de orde te stellen en eerlijk en open te zijn over zaken als de voortgang van het team. De events geven het Scrum team ook de kans om zich aan te passen en te verbeteren. De “Scope Governance Board” is wat mij betreft een extra gebeurtenis om transparantie te realiseren.

Waarom is transparantie zo belangrijk in agile?

Ik heb uit de eerste hand organisaties gezien die beweren dat ze 'openheid' willen, maar er uiteindelijk niet voor kiezen die openheid ook echt te geven. Mogelijk zitten oude overtuigingen die leiden tot angst en/of bedreiging nog te veel in de weg. Transparantie is van cruciaal belang voor het succes van softwareontwikkeling met behulp van Agile-methodologie en het is zeker de moeite waard.

Gebrek aan transparantie kan op veel zaken een negatieve impact hebben, o.a. op de samenwerking tussen klant en leverancier.

Een nieuwe manier om transparantie te vergroten: Scope gouvernance board

EEen belangrijk event die niet uit het Scrum Framework komt maar ik bij mijn vorige opdrachtgever INFO heb mogen ervaren was de Scope Governance. De opdracht was een nieuw product te bouwen voor één klant, waarin ik de rol van Scrum Master had.

Hoe werkt het en wie zitten erin?
Het Scope Governance Board kwam aan het einde van iedere sprint bij elkaar. Zij bestond uit twee vertegenwoordigers van de leverancier en twee vertegenwoordigers van de klant. In dit geval zag dat er zo uit:
Scrum Master (leverancier)
Delivery Manager (leverancier)
Product Owner (klant)
Program Manager (klant)

Welke onderwerpen bespreken we?

Update van de afgelopen sprint, waaronder sprint goal, velocity & progressie, resultaat, output van de retrospective,
Het Backlog, waaronder voortgang, resterende scope, velocity,
Scope & budget, actuele cijfers, verwachte toekomst cijfers binnen deze scope,
Update huidige sprint, spint doel, velocity, capaciteit, bijzonderheden,
Impediments, risico’s & beslissingen,
Budget report, welke uren zijn er gemaakt, wat wordt er gefactureerd & wanneer,
Actiepunten.

Voordelen van het werken met een Scope Governance Board
Mijn ervaring is dat deze meeting veel waarde toevoegde omdat deelnemers onderling verwachtingen delen. Daarmee draagt het bij aan transparantie en vertrouwen. Waarom? Iedere verwachting die anders liep konden we direct bespreken en op inspelen. Met name tegenvallers en teleurstellingen vingen de vertegenwoordigers in dit overleg onderling vooraf op. In plaats van dat je achteraf met de “billen bloot” moet en irritaties al konden ontstaan.

Klant aan het woord: Gemeente Den Bosch

Voor welke opdracht hebben jullie Lagant ingehuurd?

Eind 2019 hadden we samen met Lagant een mooie serie opmaat gemaakte ‘workshops faciliteren’ opgezet voor een interne pool risico-adviseurs binnen onze organisatie. Het doel hiervan was de risico-adviseurs als ervaren facilitators van risicosessies extra handvatten te bieden door het vooral zelf te doen. Deze ‘learning-by-doing insteek’ sluit mooi aan op de ziens- en werkwijze van Lagant op dergelijke ontwikkelingsvraagstukken.

En toen liep het ineens allemaal anders.. Welke uitdagingen zijn jullie onderweg tegen gekomen?

Vanwege de coronacrisis kon het initiële plan van fysieke workshops ineens niet meer doorgaan en kwam er een uitdaging bij hoe te handelen als facilitator in een online setting. Lagant dacht meteen met ons mee en kwam samen met ons tot een mooi online aanbod.

Hoe heeft deze aanpassing uitgepakt?

Door omstandigheden waren we dus genoodzaakt af te wijken van de initiële opdracht, maar we hebben een mooie passende reeks online workshops gehouden die goed zijn ontvangen door de risico-adviseurs. Dankzij de betrouwbare, flexibele en meedenkende houding van Lagant als partner waren wij instaat toch te voorzien in de leerbehoefte van de risico-adviseurs.

Is er verder nog iets wat je wilt delen over de samenwerking met Lagant?

Ik ben zeer tevreden over de houding van de Verandergidsen van Lagant en kan iedereen aanraden Lagant te benaderen met betrekking tot hun kennis en ervaringen op vlak van online faciliteren.

Met veel plezier hebben wij deze serie workshops voor de Gemeente Den Bosch op maat georganiseerd. Ben jij benieuwd wat Lagant voor jouw organisatie kan betekenen met betrekking tot (in-company) trainingen, (online) faciliteren en/of opmaat ontworpen workshops? Wacht dan niet langer & neem dan contact met ons op!

Herken de verschillende DISC persoonlijkheidsstijlen in een video call

In dit blog kijken we naar de persoonlijkheidsstijlen uit DISC. Als je je communicatie op deze stijlen aanpast, verloopt een call veel soepeler en effectiever. Laten we een kijkje nemen hoe je deze stijlen ook virtueel snel herkent. We gebruiken hiervoor de beeldspraak uit het boek Hoogvliegers van Rosenberg en Silvert.

De adelaar staat voor D - Dominant

De adelaar is een leider. Als hij thuis moeten werken, heeft hij de neiging om zich nog meer in hun werk te storten. Hij wil vooruit en stuurt plannen uit om het team, de organisatie, Nederland en de wereld de crisis door te helpen. In een video call komt hij met een compacte agenda, begint snel te praten, vaak zonder te beseffen dat de andere mensen ook het woord willen of dat zijn camera nog uit staat. Een adelaar probeert de call zo kort mogelijk te houden, zodat iedereen weer snel aan het werk kan. Vraag een adelaar vooraf om bij discussies zijn mening als laatste te geven. Het doel van de meeting is immers ieders expertise mee te wegen en tot een gedragen aanpak te komen.

De papegaai staat voor I – Interactief

De Papegaai verzamelt mensen om zich heen. Dit hebben ze nodig om een goed gevoel over zichzelf te houden. Ze hebben waarschijnlijk de meeting geïnitieerd of als eerste toegezegd. Ze vertellen aan de eerste aanwezigen enthousiast hun mooie nieuwe ideeën, ook al zijn de ideeën uit de vorige call nog niet half omgezet. Benut de kracht van de papegaai om het doel van de meeting voor iedereen begrijpelijk uit te leggen en met enthousiasmerende werkvormen hiervoor te komen.

De duif staat voor S – Stabiel

De duif houdt van stabiliteit in zijn werkomgeving en het mensen naar de zin maken. Daarom kunnen zij nog wel eens wat langer de tijd nodig hebben om te wennen aan thuiswerken. Een dagelijkse check-in helpt de duif om contact te houden met zijn teamgenoten en zorgt voor het besef dat het team er nog steeds voor hen is. Omdat de duif graag de goede vrede bewaart, wil hij zijn mening nog wel eens erg voorzichtig brengen. Zorg ervoor dat deze mening door iedereen gehoord wordt en voldoende aandacht krijgt. De duif weet namelijk precies wie je in de organisatie nodig hebt om dingen voor elkaar te krijgen.

De uil staat voor C – Consciëntieus

Voor de uil heeft nu de tijd van zijn leven, mits hij thuis een rustige ruimte voor zichzelf heeft en hij overal bij kan. De uil wekt taakgericht, liefst met een duidelijke takenlijst en met zo min mogelijk verstoringen. De uil raakt geïrriteerd als mensen zich niet aan afspraken of regels houden. Door zijn gedetailleerdheid en oog voor detail heeft de uil in een call meer tijd nodig dan de adelaar of de papegaai om zich een mening te vormen. Informeer hem vooraf over zaken waarbij zijn inzicht van belang is, zodat hij zich al in de zaak kan verdiepen.

Wil je meer weten over de DISC persoonlijkheidsstijlen? Het is één van de vele onderwerpen die aanbod komt in onze Teamcoach Expierince opleiding!

Hoe bouw je als Product Owner goed presterende Scrum Teams?

1. Begrijp de pijn en behoeften van je klant

Upgrade de gebruiker, niet je product. Bouw geen betere camera’s – bouw betere fotografen. – Kathy Sierra

Je (toekomstige) klanten komen niet bij jou voor je product. Ze willen iets dat hun eigen leven zal verbeteren – de vooruitgang die het biedt. Je moet je concentreren op het begrijpen van de pijnen, verlangens, ambities en problemen van je klant als jij een geweldig product wilt bouwen dat waarde levert.

Om je te verplaatsen in de klant en zijn of haar pijn en behoeften is de empathy map een mooie tool. Wij hebben hiervoor een template beschikbaar die je direct kan toepassen. Deze vind je onderaan dit blog.

2. Maak van het leveren van waarde een teaminspanning

Het leveren van een waardevol product is teamwork! Als Product Owner moet je ervoor zorgen dat het hele Scrum team begrijpt hoe we waarde leveren aan onze klanten en het bedrijf. Dit doe je door het Scrum team actief bij discussies te betrekken om te beslissen wat het juiste is om te bouwen om de beste resultaten te bereiken.

Je krijgt terug wat je geeft. Betrek je team bij je beslissingen en zij zullen zich betrokken voelen waarmee de inzet omhoog zal gaan. Doe je dit niet dan creëer je afstand en zal het team ook minder geven om de uitkomst.

3. Creëer een omgeving waarin het veilig is om fouten te maken

“Als falen geen optie is, dan is succes dat ook niet.” – Seth Godin

Bij elke sprint bestaat de kans dat je team faalt. De manier waarop je het team behandelt in tijden van mislukking is essentieel voor succes. Falen zou in orde moeten zijn, op voorwaarde dat we hier iets van leren om ons te helpen slagen in de toekomst.

De vijf disfuncties van een teammodel van Patrick Lencioni laten zien waarom psychologische veiligheid essentieel is voor het creëren van een goed presterend team. Psychologische veiligheid ontstaat wanneer teamleden zich veilig voelen om risico’s te nemen en zich kwetsbaar op durven stellen.

De 5 disfuncties van een teammodel worden ondersteund door onderzoek van project Aristoteles bij Google. Zij ontdekten dat psychologische veiligheid belangrijker is dan het hebben van een team van supersterren.

Om Scrum te laten werken, is psychologische veiligheid essentieel. Een procesraamwerk kan alleen leiden tot een beter werkproces als er een basis is van psychologische veiligheid die experimenteren en falen mogelijk maakt.

4. Richt je inspanningen op het doen van de juiste dingen

“Eenvoudig kan moeilijker zijn dan complex: je moet hard werken om je denken helder te krijgen om het eenvoudig te maken. Maar uiteindelijk is het het waard, want als je daar eenmaal bent, kun je bergen verzetten. ” – Steve Jobs

Ik zou zeggen dat de belangrijkste taak van een Product Owner het creëren van focus is. Je moet elimineren wat er niet toe doet, zodat wat er wél toe doet opvalt. Anders verminderen de dingen die er niet toe doen de waarde van jouw product.

Scrum helpt Product Owners op een natuurlijke wijze zich te focussen, door elke Sprint een duidelijk Sprintdoel te eisen.

Werken met Sprintdoelen is niet genoeg. Er moet een overkoepelende productvisie en productstrategie aanwezig zijn om de samenhang tussen de verschillende sprintdoelen te waarborgen.

5. Begin met onderzoek voordat je begint met leveren

De meeste bedrijven zitten nog altijd vast in de fabrieksmodus en staan te juichen wanneer teams nieuwe functies uitbrengen. Weersta de verleiding om iedere keer een nieuwe functie te gaan bouwen wanneer iemand hierom vraagt. Onderzoek eerst en bouw later. Geef prioriteit aan onderzoeken en leren, zodat je begrijpt wat het belang is van die functie en wat er eigenlijk nodig is om die functie tot een succes te maken.

Voer experimenten uit en verzamel bewijsmateriaal, zodat je zoveel mogelijk weet over wat de klant nodig heeft voordat je een functie gaat bouwen. Streef naar minder maar beter. Soms is het logisch om tegelijkertijd te bouwen en te leren. Maak eerst een bewuste beslissing als de beste manier is om de kans op het juiste bouwen te vergroten.

Als een functie eenmaal in je product is opgenomen, hoe waarschijnlijk is het dan dat deze wordt verwijderd? Als de functie er eenmaal inzit heeft deze vrijwel altijd onderhoud nodig. Daarom doe je er goed aan bewust te kiezen bij het bouwen van nieuwe functies. Begin met het maken van een hypothese en evalueer onderweg of je hebt bereikt wat je wilde bereiken.

6. Hou je Product Backlog kort

Ga bewust om met de items die je op je Product Backlog plaats. Je wilt voorkomen dat je je Product Backlog vervuilt met ideeën of dingen die je waarschijnlijk niet zult oppikken. Behandel je Product Backlog als melk: heb net genoeg voor de nabije toekomst, maar niet meer. Anders wordt je Product Backlog oud en zal het moeite kosten om weer vers te maken.

7. Wees lui met het schrijven van Product Backlog Items

Veel Product Owners besteden veel tijd aan het schrijven van Product Backlog Items. Mijn tip: doe dit niet! Het is een grote tijdverspilling en het is niet de manier om waarde toe te voegen aan het Scrum team. Een uitgebreid beschreven product Baclog Items helpt om de functie goed te bouwen, maar niet de juiste functie te bouwen. Op basis van mijn persoonlijke ervaring mag een Product Owner slechts 20% van zijn tijd besteden aan levering, 80% aan ontdekking en validatie.

Richt je op het begrijpen van het probleem dat je probeert op te lossen en geef deze informatie door aan het ontwikkelingsteam. Maak vervolgens samen de Product Backlog Items. Op deze manier is het een werkend product van het hele Scrum team, in plaats van alleen jou. Door hier samen aan te werken zal iedereen hetzelfde begrijpen en onthouden wat er moet gebeuren om het product te verbeteren.

Uiteindelijk doet het er niet toe wat er in het Product Backlog Item is opgeschreven: Dat het Ontwikkelingsteam het begrijpt, is het belangrijkste.

8. Verwijder ongebruikte en niet-waarde toevoegende functies

Elke functie moet waarde toevoegen aan je product en de contributie betalen. Functies die niet hun eigen gewicht trekken, verminderen de waarde van je product. Ongebruikte functies zijn als parasieten die geld verbranden om in leven te blijven: infrastructuurkosten, kosten als gevolg van productieproblemen en onderhoudskosten om ze aan nieuwere versies te laten werken. Je kunt niet snel inspelen op veranderingen wanneer al deze parasieten je vertragen.

Verwijder deze functies daarom snel, omdat het capaciteit vrijmaakt om aan waardevollere dingen te werken en in de loop van de tijd veel geld bespaart.

Het verwijderen van ongebruikte functies is om twee redenen moeilijk:

Het is moeilijk om erachter te komen welke functies in jouw product er echt toe doen, vooral als je niet begrijpt hoe jij waarde toevoegt aan jouw klanten.

Mensen hebben er een hekel aan om dingen te verliezen, veel meer dan het verkrijgen van nieuwe dingen. Dit wordt verliesaversie genoemd. Dus zelfs als slechts een paar klanten een zeer impopulaire functie gebruiken, kunnen ze hier veel weerstand tegen tonen, omdat mensen een hekel hebben aan het verliezen van wat ze al hebben.

9. Laat het team de oplossing bedenken, maar daag ze uit!

Als Product Owner moet je je concentreren op het uitleggen van het probleem dat je wilt oplossen. Het is niet jouw taak om een technische oplossing te bedenken. Jouw taak is er voor zorgen dat de technische oplossing de meeste waarde oplevert. Daag je team uit als je denkt dat ze met een te ingewikkelde oplossing komen om er zeker van te zijn dat al die complexiteit echt nodig is. Oplossingen moeten zo eenvoudig mogelijk zijn, maar niet eenvoudiger.

10. Manage je klanten niet, betrek ze erbij

Ongelukkige stakeholders kunnen jouw baan als Product Owner het leven zuur maken. Daarom is het erg belangrijk dat je een manier vindt om ze tevreden te houden. De beste manier om dit te doen is niet door je stakeholders te managen, maar door ze erbij te betrekken. Een eenvoudige manier om je belangrijkste stakeholders te betrekken, is door ze uit te nodigen voor de volgende Sprint Review.

Hoe word ik Scrum Master?

Tip 1: Verbeter je CV

Je hebt nog geen echte Scrum Master-ervaring, maar je hebt misschien wel een aan Scrum- of Agile gerelateerde ervaring. Markeer deze op je CV of LinkedIn-profiel, zodat het er in ieder geval uitspringt. Maakte je bijvoorbeeld eerder al eens deel uit van een team dat dagelijkse Stand-ups deed? In zo’n geval zou je bijvoorbeeld kunnen beschrijven dat je Daily Scrums hebt uitgevoerd. Ook als het destijds niet officieel onder de noemer Scrum of Agile viel, helpt deze ervaring bij de invulling van je rol als Scrum Master.

Tip 2: Zoek naar vacatures bij huidige werkgever

In veel gevallen is een uitstekende volgende stap het vinden van mogelijkheden om op zijn minst kleine ervaringen met Agile/Scrum op te doen bij je huidige werkgever. Ook als Scrum misschien niet past binnen je huidige organisatie, project of team kun je kijken of je elementen kunt toepassen. Kijk bijvoorbeeld of een van de volgende acties waarde kan toevoegen in jullie werkomgeving:

Introduceer het idee om in iteraties of sprints te gaan werken.
Begin met Daily Stand-ups;
Demonstreer periodiek een werkend (deel) product aan de stakeholders (betrek je stakeholders consequent in het proces);
Start met periodieke vergaderingen met als doel manieren te vinden om de samenwerking binnen jullie team te verbeteren;
Maak het werk transparant door het gebruik van sticky-notes (kanbanbord, taakbord, verbeterbord) in jullie werkomgeving;
Rapporteer periodiek over de voortgang met behulp van burndown charts.

Tip 3: Zoek naar vacatures als vrijwilliger

Als je geen mogelijkheden kunt vinden om kleine stukjes Agile binnen je huidige werkgever te introduceren, overweeg dan om vrijwilligerswerk te doen. Dit kan een regionale, nationale of internationale non-profit organisatie zijn of zelfs al op de school van je kinderen, het jeugdteam of de kerk. Wees creatief, ook in jouw omgeving zijn er genoeg mogelijkheden om ervaring op te doen.

Tip 4: Behaal je certificaat

Een cursus Scrum Master is waardevol voor het vullen van je rugzak en helpt bij het halen van je certificaat. Hoewel het niet genoeg is om alles te leren wat nodig is om een goeie Scrum Master te zijn, voorziet het je wel van een goeie dosis basiskennis en een toolkit die voldoende gevuld is om te beginnen als Scrum Master. Het verdienen van een erkend certificaat, duidt op twee dingen: een bepaald basisniveau van kennis en, nog belangrijker, een bereidheid om te leren en in jezelf te investeren. Kies daarbij voor een geloofwaardige Scrum-certificering, zoals die van scrum.org (Professional Scrum Master).

En wil je je toolkit nog een beetje verder uitbreiden? Dan is onze Professional Teamcoach Experience echt iets voor jou! Het is een opleiding die veel verder gaat dan alleen de rol van Scrum Master. In de zes opleidingsdagen verspreid over zes maanden doe je gaandeweg een enorme dosis kennis en ervaring op als teamcoach. Ook voor deze opleiding is het behalen van een certificaat een absolute aanrader en inbegrepen in de prijs.

Tip 5: Weet dat de meeste CV’s worden gescreend

Om een baan als Scrum Master te vinden, moet je ervoor zorgen dat je CV wordt gelezen. De meeste werkgevers gebruiken tegenwoordig software om CV’s te screenen. Om voorbij die filters te komen, wil je zorgen dat hun meest voor de hand liggende zoekwoorden in ieder geval in je CV zijn opgenomen. Als je bijvoorbeeld solliciteert op een “Scrum Master” – positie, moet je ervoor zorgen dat je CV de zinnen “Scrum Master” maar ook “ScrumMaster” bevat, zowel met als zonder spatie, zodat u de kansen maximaliseert om een screeningssysteem te passeren dat slechts één bevat van die woorden.

Dit lijkt onzorgvuldig, maar als het je helpt om door de screening te komen is het misschien toch de moeite waard. Nu kan ik me voorstellen dat je graag een clean CV hebt en dit soort ‘onzorgvuldigheid’ liever vermeid. In dat geval ga ik je nu heel lui maken met het volgende trucje! Door de verschillende varianten van deze term ergens op je CV te plaatsen, en de tekst dezelfde kleur als de achtergrond te geven, zijn ze niet zichtbaar op je CV maar komen ze wel door de screening van een dergelijke applicatie heen.

Tip 6: Netwerken, netwerken & nog meer netwerken

Ik kan dit niet genoeg benadrukken, netwerken is echt het aller beste wat je kunt doen als je opzoek bent naar een nieuwe functie. Reken er maar op dat er ruim wordt gereageerd op de online Scrum Master vacatures en dat de concurrentie gigantisch is. Alle bovenstaande tips helpen je erbij om jezelf zichtbaar te maken tussen de grote stapel CV’s op het bureau van de betreffende manager, maar niets is beter dan een andere ingang bij een bedrijf te vinden en je concurrentie in een adem voorbij te schieten. Deze andere route naar je nieuwe baan als Scrum Master vereist een goede dosis geluk – op het juiste moment en op de juiste plaats zijn.

Het goede nieuws is dat je dat beetje geluk ook in eigen hand hebt: Ga naar buiten! Er worden momenteel ontzettend veel (gratis) Scrum & Agile bijeenkomsten georganiseerd en die mag je vanaf vandaag niet meer aan je neus voorbij laten gaan. Ga opzoek naar je lokale Agile of Scrum bijeenkomst via platformen zoals Meetup en Eventbrite. Maar, minstens zo belangrijk, neem deel aan bijeenkomsten van andere groepen waarvan de leden kunnen werken bij het type bedrijf waar je lid van wilt worden.

Tip 7: Heb geduld

Dit is misschien wel het beste advies wat ik je kan geven: Heb geduld. De zeven bovenstaande tips zullen je zeker helpen je kansen om je Scrum Master positie te vergroten. Echter zal het verschuiven van je carrière in een nieuwe richting waarschijnlijk langer duren dan het vinden van dezelfde functie in een andere organisatie. Zorg dat je hebt gedaan wat je kunt, en wees dan ook volhardend en vertrouw in jezelf. Het kan even duren.