In het eerste deel van onze blog lag de focus op “waarom” teams inzicht willen geven in hun Agile volwassenheid. We hebben daarbij zowel gekeken vanuit het gezichtspunt van de organisatie als het gezichtspunt van de teams zelf. En de aspecten die een goed self assessment nodig heeft om de juiste acties te stimuleren en de typische valkuilen van (self) assessments daarbij zoveel mogelijk te voorkomen. In dit vervolg gaan we, op basis van deze eerdere verkenning, in op een model dat zoveel mogelijk de genoemde aspecten in zich heeft en daarmee antwoord geeft op de vraag “hoe” teams een goed inzicht kunnen geven in hun volwassenheid.
Wat is de kern van een Agile volwassen team? In onze ogen is dat een Agile team dat zo snel mogelijk waarde levert voor de business, zonder daarbij in te leveren op kwaliteit. Daarbij neemt het regelmatig de tijd om te verbeteren op basis van ingerichte feedbackcycli. Zowel het Agile Manifestoals de Scrum Guide staan in het teken van deze drie-eenheid en Hendrik Kniberg gaat in zijn onofficiële Scrum checklist zelfs zover om te stellen dat wanneer je proces prima is wanneer je deze drie aspecten hebt gerealiseerd.
Zo snel mogelijk waarde leveren voor de business realiseert een Scrum team door elke sprint een werkend product op te leveren dat de – voor dat moment – hoogste business waarde voor de business in zich heeft. Hoewel dit de primaire verantwoordelijkheid is van de Product Owner, maken zowel Agile als Scrum principes dit ook echt mogelijk. Denk hierbij aan de nauwe samenwerking met de klant, het mogelijk maken om laat in het proces wijzigingen door te kunnen voeren (die een hogere business waarde genereren) en best practices als het inzicht geven in het langetermijndoel middels een vision board of product canvas.
Scrum teams zijn erg strikt als het gaat om de kwaliteit van het opgeleverde product. Wanneer kwaliteit ondergeschikt wordt gesteld aan de snelheid waarmee functionaliteit wordt opgeleverd zijn de gevolgen daarvan binnen enkele sprints direct duidelijk. De productiviteit van een Scrum team keldert drastisch, omdat een aanpassing in één deel van het systeem tot gevolg heeft dat elders fouten ontstaan. Het is dan ook niet voor niets dat het Agile manifesto stelt dat alle betrokkenen bij het product promoten dat een constante snelheid over lange termijn essentieel is en continu aandacht voor technische excellentie en goed ontwerp daarbij centraal staan. Het ontwikkelteam maakt hierbij veelvuldig gebruik van best practices als decoupling, simplicity, refactoring en test driven development.
Scrum is gebaseerd op de theorie van empirische procesbesturing die uit gaat dat kennis ontstaat uit ervaring en het nemen van beslissingen op basis van wat bekend is. Hiervoor inspecteren Scrum teams zichzelf op regelmatige basis en richten op verschillende niveaus feedback cycli in. Zij geven zichzelf hiermee continu inzicht hoe het gaat en wat op basis van deze feitelijke waarnemen de beste vervolgstap of verbetering is. Hoewel Scrum teams een continue snelheid over langere termijn nastreven zien we hierbij wel dat zij de werkzaamheden, de resultaten en de voorspelbaarheid steeds beter kunnen uitvoeren.
SITUATIE | EFFECTIVITEIT | EXCELLENTIE | SNELHEID |
---|---|---|---|
High performing Scrum team | Hoog | Hoog | Hoog |
In hoog tempo kwalitatieve producten maken waar niemand op zit te wachten | Laag | Hoog | Hoog |
Ruwe prototypes in productie zetten om snel aan de wens van de gebruikers te voldoen | Hoog | Laag | Hoog |
De meest perfecte producten maken waar gebruikers nog jaren op moeten wachten | Hoog | Hoog | Laag |
We weten wat de gebruikers willen, maar niet hoe we dat ooit moeten gaan leveren | Hoog | Laag | Laag |
We maken ooit “iets”, maar dat “iets” wordt wel helemaal geweldig ontwikkelt | Laag | Hoog | Laag |
Als iemand ons ooit kan vertellen wat we moeten doen, hacken we het in elkaar waar je bij staat | Laag | Laag | Hoog |
Waar zijn we mee bezig? Iemand? Hallo? … | Laag | Laag | Laag |
Samengevat zien we dat de volwassenheid van een team afhankelijk is van de mate waarin zij het continu het goede product leveren, het product ook goed leveren en zij middels feedback dit ook steeds beter weten te realiseren.
Hoe meet je de volwassenheid van een team op deze aspecten?
Hoe laat je teams nu van zichzelf bepalen waar ze staan? Een checklist op de Scrum Guide zou een indicator kunnen zijn. Heb je de drie rollen? Werk je in de vier voorgeschreven meetings? Leveren die de drie artefacten op? De praktijk laat vaak zien dat het afvinken van alleen deze zaken niet aangeeft of een team ook daadwerkelijk Agile is of Scrum volgt.
Blijkbaar zou je meer zaken op de lijst moeten zetten om een context te krijgen waarin het zinnig is om deze meetings te houden. Je kan dus naast vragen of de meetings, rollen en artefacten er zijn, vragen of ze ook gebruikt worden waarvoor ze bedoeld zijn. Je kan dus vragen of een Daily Scrum ook daadwerkelijk een meeting is van het Ontwikkelteam en niet die van een Product Owner. Ook kan je vragen of een Sprint Review inderdaad als resultaat heeft dat feedback van stakeholders verwerkt is in de Product Backlog.
Toch mis je hierbij nog steeds een stuk context. Je past namelijk de regels van Scrum toe, je weet nu ook waarom, maar je moet je ook bewust zijn of deze stappen ook daadwerkelijk voor elkaar krijgen waar ze voor bedoeld zijn. Dan krijg je ook nog aspecten die van invloed zijn op je manier van samenwerken en die misschien minder tastbaar zijn, maar wel zichtbaar zijn in typische high performing teams. Denk hierbij aan de sfeer en wederzijds respect tussen de teamleden.
Het is kennelijk dus belangrijk om zowel feitelijke waarnemingen als ook de context in de zelfevaluatie op te nemen. Dan is het nog de vraag hoe de verschillende aspecten door het Scrum team worden geïnventariseerd. Het met een team doornemen van deze aspecten geeft al richting aan een discussie over de items op de lijst en in hoeverre ze van toepassing zijn op het team. Er is dus al aandacht voor eventuele stappen die het team zou kunnen nemen om zich te verbeteren. Het faciliteren van deze discussie binnen het team is waar bijvoorbeeld de Spotify Squad Health Check erg sterk in is. Maar deze variant biedt juist weer minder inzicht in de context en de volwassenheid over teams heen.
Wij hebben gekozen om een wat uitgebreidere checklist samen te stellen die zich juist focust op het empirisch kunnen meten van verschillende aspecten op verschillende contextuele niveaus. Dus niet alleen of een rol aanwezig is of een meeting wordt gehouden, maar ook of het doel van de rol dan wel meeting wordt bereikt. En of de aspecten van een high performing team goed meetbaar zijn. Door de vragen eenvoudig meetbaar te maken en alleen met ja of nee te beantwoorden krijgt een team snel inzicht in waar het nu staat. Hieronder vind je een uitsnede van de checklist die we voor de self assessments gebruikten.
In de uitvoering gebruiken we deze checklist op een tweetal manieren. Of de checklist wordt gezamenlijk met het team doorgenomen, waardoor eventuele discussies direct worden gevoerd of wordt de checklist door de afzonderlijke Scrum team leden ingevoerd, waarna eventuele discussiepunten met het team worden doorgesproken.
Hoe presenteer je de resultaten van een team op deze aspecten?
De items op de checklist zijn in enige mate van invloed op één of meer van de eerder genoemde factoren. Het hebben van een visie zal veel invloed hebben op het feit, of we het goede product bouwen (effectief). Pair programming heeft een grote invloed het verkorten van je feedbackloops (snelheid) en ook op je technische staat (excellent). In hoeverre een bepaald item van invloed is, is een mooie discussie waard binnen het team. Als de checklist bijgewerkt is met deze waarde per item, kunnen we de huidige volwassenheid plotten op een diagram.
Dit diagram geeft de interactie tussen de drie factoren goed weer. Het laat helder zien dat volwassen teams streven naar de juiste balans tussen deze factoren. Het gaat bij het vergroten van de volwassenheid in eerste instantie niet om het maken van grote stappen, maar juist over de richting van de stappen. Kan je niet beter een betekenisvolle kleine stap in de goede richting zetten, dan een betekenisloze grote stap de verkeerde kant op?
Daarnaast worden de individuele items op de checklist losgekoppeld van de onderliggende factor. Want zoals we in onze eerste blog al hebben aangegeven willen we voorkomen dat we over gaan op micromanagement van individuele aspecten, maar juist focus willen hebben op het resultaat van deze individuele aspecten. Door deze loskoppeling zien we dan ook dat de discussie meer gaat over de vraag hoe we als team effectiever kunnen worden of juist hoe we sneller de producten kunnen gaan leveren.
De sweet spot is de plek waar de de drie factoren overlappen en ook de plek waar je als team wilt zitten. Wanneer de checklist is bijgewerkt met een waarde per item, kunnen we de huidige volwassenheid direct plotten op dit diagram. Hierbij kun je naar behoefte nog onderscheid maken tussen het effect dat verschillende items op de checklist hebben. Bijvoorbeeld door items die tot de kern van Scrum behoren een zwaarder gewicht te geven dat items die zichtbaar zijn bij high performing teams of juist meer gekenmerkt worden als best practice.
Door de omvang van de te plotten cirkel afhankelijk te maken van de mate van volwassenheid, wordt ook snel duidelijk waar het team staat in hun reis om te groeien in hun Scrum volwassenheid. Hiermee ziet het team ook de effecten van hun inspanningen wanneer ze de self assessment op een later tijdstip nogmaals uitvoeren. En zien zij zowel of hun acties hebben geleid tot een betere balans tussen de verschillende factoren en in de groei van zichzelf als Scrum team.
Meten is interessant, maar hoe nu verder?
Het plotten van de resultaten in een overzichtelijk model maakt een eventuele onbalans inzichtelijk, zowel voor het team als de organisatie. Zeker wanneer er meerdere team worden gemeten, wordt al snel duidelijk hoe een organisatie betere support kan geven aan de teams. Ligt dit op het vlak van effectiviteit, dan is het goed om te kijken hoe de visie en ideeën vanuit de business beter naar de Scrum teams kan worden vertaald. Ligt dit juist meer op het vlak van excellentie dan kan worden gekeken welke kennis, kunde en / of hulpmiddelen aan de teams geboden kan worden.
Voor de teams zelf worden de resultaten besproken tijdens de retrospectives en krijgen zij inzicht waar de geïnventariseerde verbeteracties toe moeten leiden. Het model kan daar ook ondersteuning bij bieden. Doordat we van alle items weten welke de grootste invloed hebben op de verschillende factoren geeft het model ook suggesties welke stappen het meeste resultaat hebben op het bereiken van de sweet spot. Dit hebben wij gerealiseerd door de top 3 tips weer te geven onder het diagram.
Middels deze vorm van self assessments krijgen zowel de Scrum teams als hun organisatie inzicht in de volwassenheid van de afzonderlijke Scrum teams en de uitdagingen waar deze Scrum teams voor staan. Door deze wijze van presenteren wordt het gesprek zoveel mogelijk gestuurd op de te bereiken doelen in plaats van de afzonderlijke acties. Dit biedt maximale ruimte voor de teams om zichzelf te verbeteren op een wijze die goed bij hun past.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile en lees hier meer Agile gerelateerde blogs.