Wat is het "Squad Health Check Model" van Spotify?
Veel organisaties experimenteren met verschillende mogelijkheden om te kunnen beoordelen en visualiseren waar hun teams staan. Normaal gesproken gebeurt dit met behulp van zogenaamde Maturity Models, oftewel volwassenheidsmodellen, die een doorontwikkeling door verschillende niveaus weergeven.
De bedoelingen achter dit soort modellen zijn over het algemeen positief – bijvoorbeeld wanneer managers, leidinggevenden of coaches in grotere organisaties een beter gevoel willen krijgen voor waar hun focus zou moeten liggen als het gaat om verbeteringen en problemen, of wanneer ze hun teams willen helpen om meer zelfreflectie te ontwikkelen, zodat ook zij zich beter kunnen richten op hun eigen verbeterpunten.
Wij noemen het echter liever een „Health Check Model" (gezondscheidscheckmodel) in plaats van een „Maturity Model", omdat dat laatste…tja…een beetje betuttelend klinkt. Bovendien bevatten de meeste van onze modellen geen doorontwikkeling over verschillende niveaus. De primaire doelgroep is daarnaast het team zelf en niet het management.
Het verbeteren van de organisatie lijkt vaak op een raadspel (hoe weet je wat er verbeterd moet worden? En hoe weet je of iets daadwerkelijk verbeterd is?). Een systemische aanpak met een duidelijke visualisatie kan dit raadspel tot een minimum beperken.
Ok, maar werken zulke modellen ook echt?
Het hangt ervan af. In sommige gevallen kunnen deze modellen echt nuttig zijn. Soms is het eerder "meh" – mensen doen hun plicht en nemen deel aan workshops, enquêtes e.d., maar de data die daaruit voortkomen worden genegeerd.
Maar wees voorzichtig. We hebben al gezien hoe dit soort modellen bij sommige bedrijven echte monsters werden; een systemisch instrument van onderdrukking dat zorgt voor suboptimalisatie en angst. De managers gebruiken het volwassenheidsmodel om teams te beoordelen en tegen elkaar op te zetten, en de teams verbergen hun problemen om er goed uit te zien. En dat is helemaal niet goed!
Hoewel de potentiële schade waarschijnlijker is dan het potentiële voordeel, IS ER een potentieel voordeel en er zijn manieren om een ramp te voorkomen.
Bij Spotify heb ik een paar jaar hiermee geëxperimenteerd en manieren gevonden die best goed werken (dus meer voor- dan nadelen hebben) – in het beste geval zijn ze "nuttig", in het slechtste geval "meh" en tot nu toe zijn ze nog nooit een "ramp" geweest. Dit Health Check Model hebben we ook bij een aantal andere bedrijven geïntroduceerd en vergelijkbare resultaten behaald, dus ik dacht dat het tijd was om er een artikel over te schrijven.
Voor wie is het Health Check Model bedoeld?
Bij het Health Check Model van een Squad (onze term voor een klein, interdisciplinair, zelforganiserend ontwikkelteam) zijn er voornamelijk twee stakeholders:
1) Het Squad zelf
Doordat de afzonderlijke indicatoren besproken worden, kunnen de leden van het Squad beter begrijpen wat voor hen werkt en wat niet. De grote verscheidenheid aan vragen helpt hen om hun blikveld te verbreden. Misschien zijn ze zich bewust van de kwaliteitsproblemen in de code, maar hebben ze niet echt nagedacht over de waarde vanuit het perspectief van de klant, of over hoe snel ze kunnen bijleren. Bovendien worden zowel de positieve als de negatieve punten zichtbaar gemaakt.
2) Mensen die het Squad ondersteunen.
Managers en coaches die buiten het team werken (of in ieder geval gedeeltelijk buiten het team werken) krijgen een overzicht van alle dingen die wel en niet werken. Daarnaast kunnen ze patronen herkennen tussen verschillende Squads. Als je tientallen teams hebt en niet met iedereen over alles kunt praten, kan zo'n samenvatting helpen om te bepalen hoe je je tijd het beste kunt besteden en met wie je waarover zou moeten praten.
Je bewust zijn van het probleem is de eerste stap naar het oplossen ervan. Dit soort visualisatie maakt het een stuk moeilijker om een probleem te negeren.
Hoe wij dat bij Spotify doen
We doen hoofdzakelijk drie dingen:
We organiseren workshops waarin de leden van een squad hun huidige situatie bespreken en beoordelen aan de hand van verschillende aspecten (bijvoorbeeld kwaliteit, plezier, waarde, enz.)
We maken een grafische samenvatting van het resultaat
We helpen de squads om zich te verbeteren
We hebben verschillende varianten. De ene noemen we simpelweg "Squad Health Check Model", andere heten bijvoorbeeld "Fluent@Agile-Spel" of "Quarterly Reflection". Het "Health Check Model" is een verbeterde versie van het driemaandelijkse "Autonomous Squads"-onderzoek, dat in 2012 werd genoemd in het artikel Scaling Agile @ Spotify.
Hier is een echt voorbeeld van het Health Check Model van een "Tribe":
Hier is weergegeven hoe 7 verschillende Squads hun eigen situatie inschatten. De kleuren laten zien hoe het er momenteel voor staat (groen=goed, geel=enkele problemen, rood=zeer slecht). De pijlen geven de trend aan (wordt het beter of slechter?).
Als je het diagram een paar minuten goed bekijkt, zullen je een aantal interessante dingen opvallen:
In de kolommen kun je de belangrijkste verschillen tussen de verschillende Squads herkennen. Squad 4 is met zo'n beetje alles tevreden. Squad 2 heeft veel problemen, maar er is een positieve trend bij bijna alle punten.
In de rijen kun je systemische patronen herkennen. Elk Squad heeft plezier in het werk (en de trend gaat zelfs nog verder omhoog!). Motivatie lijkt dus geen probleem te zijn. Maar het releaseproces zorgt voor problemen en de codebase ziet er ook niet al te best uit. Na verloop van tijd zal dat zeker ook de werkplezier-factor beïnvloeden.
In het totaalbeeld kun je zien dat bijna alle pijlen omhoog wijzen – in het hele diagram zijn er slechts 2 pijlen naar beneden. Dat betekent dat het verbeterproces (het allerbelangrijkste proces) blijkbaar werkt.
Dit is natuurlijk slechts een benadering van de werkelijkheid ("Alle modellen zijn fout, maar sommige zijn nuttig." – George Box). Daarom is het een goed idee om alles nog eens te controleren voordat je concrete maatregelen neemt.
Gaat het bij Squad 4 echt zo goed of zijn ze gewoon optimistisch en zien ze hun problemen niet? De meeste Squads denken dat ze waarde leveren aan hun klanten – maar hoe weten ze dat? Is die uitspraak gebaseerd op wensdenken of op echte klantfeedback?
Squad 4 uit ons voorbeeld werd in werkelijkheid pas een week voordat de Health Check werd uitgevoerd samengesteld. Ze zaten daardoor absoluut nog in de oriëntatiefase (ook wel Forming-fase of Honeymoon-fase genoemd). Om die reden hadden zowel Squad 2 als Squad 4 veel ondersteuning nodig.
De eenvoudige uitlevering was hier een groot probleem. Daarom werd er meer gefocust op zaken als Continuous Delivery (continue uitlevering) en al snel was er een duidelijke verbetering zichtbaar.
Houd er alsjeblieft rekening mee dat dit een zelfbeoordelingsmodel is, dat gebaseerd is op de eerlijkheid en de subjectieve mening van de Squad-leden. Het werkt dus alleen in een omgeving van vertrouwen, waarin mensen er zeker van kunnen zijn dat hun managers en collega's in hun belang handelen. De gegevens verzamelen is vrij eenvoudig – het gaat er dus vooral om dat er geen concrete redenen zouden moeten zijn om dit niet te doen.
Gelukkig heerst er bij Spotify zo'n vertrouwensvolle omgeving en zijn de managers en coaches er zeer op gericht om duidelijk te maken dat dit een tool is ter ondersteuning en niet ter beoordeling van de Squads.
Hoe we de gegevens verzamelen
We hebben de ervaring dat online surveys voor dit soort doeleinden totale onzin zijn. Dat komt vooral doordat ze geen gesprek mogelijk maken, en dat is nu eenmaal het meest waardevolle eraan. Terwijl de squad-leden met elkaar praten, doe je nieuwe inzichten op, en de coach ontdekt hoe hij de squads effectief verder kan helpen. De data alleen laten je slechts een klein deel van het totaalplaatje zien, wat misleidend kan zijn.
Daarom organiseren wij (meestal agile coaches) workshops met de squads en stimuleren we een direct gesprek over de verschillende indicatoren van het "Health Check Model". Één tot twee uur is daarvoor meestal voldoende.
Voor de facilitatie gebruiken we een set zogenaamde "Awesome Cards". Elke kaart staat voor een van de indicatoren en bevat zowel een "Example of Awesome" (voorbeeld van iets geweldigs) als een "Example of Crappy" (voorbeeld van iets dat slecht loopt).
Een set bestaat normaal gesproken uit ongeveer 10 kaarten. Hier een voorbeeld van een compleet set:
Bij elke vraag wordt aan de Squads gevraagd of ze zichzelf eerder bij "Awesome" of "Crappy" zien. Om het makkelijker te maken om het eens te worden over een kleur voor de indicatoren en de bijbehorende trend (stabiel, opwaartse/neerwaartse trend), gebruiken we heel basale workshopmethoden zoals Dot Voting.
Hier zijn de kaarten als PDF-download
We houden het met drie niveaus vrij simpel (groen/geel/rood). De exacte definitie van de kleurcodering kan variëren, maar is gebaseerd op de volgende uitspraken:
Groen betekent niet per se dat alles perfect is. Het betekent alleen dat het Squad tevreden is en op dit moment geen grote behoefte aan verbeteringen ziet.
Geel betekent dat er enkele problemen zijn die opgelost moeten worden, maar dat het geen ramp is.
Rood betekent dat er echt iets misgaat en dat er verbeteringen nodig zijn.
Ja, dit zijn subjectieve gegevens. In theorie staat het elk squad vrij om ook objectieve gegevens (cyclustijd, aantal defects, velocity enz.) mee te nemen. Dat doen echter maar heel weinig squads. Dat komt doordat squads ook objectieve gegevens moeten interpreteren en moeten beslissen of die betekenen dat je een probleem hebt of niet. Uiteindelijk is daarom alles sowieso subjectief. Als iets als een probleem voelt, dan is het ook een probleem.
Soms combineren we dit met retrospectives, bijvoorbeeld door een kaart te kiezen en daar vervolgens verbeteracties voor te bedenken.
Welke vragen moet je stellen?
Als je de bovengenoemde voorbeelden bekijkt, zul je merken dat de vragen niet altijd dezelfde zijn. Dit is een goede leidraad:
De vragen moeten een breed spectrum aan verschillende perspectieven dekken.
Deze vragen zijn slechts een startpunt, een voorbeeldige voorselectie. De Squads mogen zelf beslissen of ze vragen willen verwijderen, toevoegen of aanpassen als ze denken dat dit zinvol is.
Probeer het aantal vragen te beperken tot ca. 10 vragen. Bij meer vragen kan er al snel overlap ontstaan, waardoor deze verwijderd kunnen worden.
Let op dat de vragen betrekking hebben op de omgeving waarin een Squad werkt, en niet op harde data (zoals bijvoorbeeld de Velocity). Daardoor wordt het geheel minder bedreigend en wordt nog eens benadrukt dat het gaat om ondersteuning en verbetering – en niet om beoordeling.
Onze aanname (of die nu klopt of niet) is dat een Squad een intrinsieke motivatie heeft om succesvol te zijn en onder de gegeven omstandigheden de best mogelijke prestatie te leveren.
Hoe vaak meten we de gezondheid van de Squads?
Zoals gezegd hebben we verschillende modellen waar we op terugvallen, dus dat verschilt echt per situatie. We hebben nog geen specifiek "perfect tijdsinterval" gevonden voor dit soort dingen (en dat zullen we waarschijnlijk ook nooit vinden).
Per kwartaal lijkt echter een goed uitgangspunt te zijn. Maandelijks is waarschijnlijk iets te vaak (mensen gaan het dan al snel als lastig ervaren en de gegevens veranderen niet snel genoeg). Twee keer per jaar lijkt te weinig te zijn (er kan in een half jaar gewoon te veel gebeuren). Maar zoals gezegd, dat verschilt altijd per situatie.
Conclusie – Waar je aan moet denken als je dit wilt uitproberen
Zo'n model KAN helpen om verbeteringen te stimuleren. Maar het kan ook een volledige bedrijfscultuur op z'n kop zetten als je het niet goed aanpakt! Ga daarom altijd met de nodige voorzichtigheid te werk.
Hier zijn een aantal richtlijnen die de kans op succes vergroten:
Wees duidelijk over de motieven voor het invoeren van het model. Het moet altijd gaan om verbetering, niet om beoordeling.
Verzamel de gegevens voornamelijk door persoonlijke communicatie en niet door online enquêtes. Dit proces moet interessant zijn en leuk.
Betrek de teams bij het toepassen van het model en laat hen aanpassingen maken op basis van hun behoeften.
De acceptatie van het team is belangrijker dan de consistentie van de gegevens. Als Team A een iets andere set vragen kiest dan Team B, is dat oké (ook al wordt de samenvatting daardoor wat onoverzichtelijker).
Zorg ervoor dat er geen prikkel is om te sjoemelen. Er mogen geen redenen zijn voor een team om zich beter voor te doen dan ze werkelijk zijn.
Zoek een eenvoudige manier om de gegevens te visualiseren. Hoe duidelijker en intuïtiever de visualisatie is, hoe groter de kans dat deze ook daadwerkelijk wordt gebruikt.
Probeer de teams niet met elkaar te vergelijken. Als Team A de punten voornamelijk groen beoordeelt en Team B grotendeels rood, betekent dat niet automatisch dat Team A "beter" is. Het kan net zo goed betekenen dat Team A een eenvoudigere context heeft, optimistischer is, of dat Team B eerlijker is over moeilijkheden. Wat de reden ook is, het betekent simpelweg dat Team B wat meer ondersteuning nodig heeft. De houding van de manager moet zijn: "Hoe kan ik helpen?" en niet "Waarom zijn jullie zoveel slechter dan de anderen?".
Doe een follow-up. Stel vragen zoals: "Helpt dit model jullie?", "Als we geen Health Checks meer zouden doen, zouden jullie ze dan missen?" of "Hoe kunnen we dit model nog nuttiger maken?". Het model (en de manier waarop je het toepast) moet continu verbeterd worden.
