meten-agile-teams-1200

Als het gaat om het inzichtelijk maken van de volwassenheid van Agile teams, zitten Agile coaches veelal tussen twee vuren ingesloten. Aan de ene kant hebben zij “de organisatie” die graag wil weten hoe hun Agile teams het doen en aan de andere kant “de Agile teams” die zelf verantwoordelijk zouden moeten zijn voor hun continue verbetering. Ook in het land van Agile coaches en consultants zijn de meningen over dit onderwerp sterk verdeeld met vurige flamewars tot gevolg. Waarom is het meten belangrijk voor Agile teams? Wat moeten de resultaten weergeven? En hoe meten we dan op effectieve wijze?

De opdracht van Agile coaches en consultants vanuit hun opdrachtgever is om de Agile volwassenheid van teams naar een hoger niveau te krijgen. Deze opdracht impliceert een aantal dingen. Enerzijds betekent dat de Agile volwassenheid iets is wat gemeten kan worden en anderzijds dat externe factoren (in dit geval de inspanning van een coach) direct invloed kunnen hebben op deze volwassenheid. De uitdaging hierin is dat een belangrijk onderdeel van Agile volwassenheid juist gaat om het feit dat teams in staat zijn zichzelf te organiseren en verbeteren.

De externe factor, in dit geval een Agile coach of consultant, heeft tot doelstelling om de teams in staat te stellen inzicht te krijgen waar zij staan én welke richting hun ontwikkeling zou kunnen gaan. Op basis van dit inzicht kunnen zij de volgende ontwikkelstappen bepalen en op teamoverschrijdende aspecten de organisatie vragen hun hierbij te ondersteunen. Hiervoor zijn transparantie vanuit het team én vertrouwen in de organisatie essentiële punten. Transparantie is nodig opdat fundamentele problemen open kunnen worden besproken. En vertrouwen voorkomt dat er ongewenste reacties worden opgeroepen.

Laten we naar een voorbeeld kijken van Scrum teams die middels de Agile Adoption Framework van Ahmed Sidky zijn gemeten. Zij scoren laag op het aspect “Planning to Deliver Software Frequently”, met name vanwege een enorme backlog aan historische features en bugs (uit de tijd dat zij nog niet Agile werkten) en een continue stroom aan bevindingen uit het productiesysteem. Op het moment dat de resultaten van deze meting bekend werden was de eerste reactie vanuit het projectmanagement om al het werk middels een WBS om te zetten in een detailplanning met als argument dat het project dan eindelijk in staat is om exact aan te geven wanneer welke functionaliteit wordt opgeleverd. Een dergelijke meting heeft dus juist een negatief effect op de Agile volwassenheid van de teams. Laten we eens kijken waarom beide partijen inzicht willen hebben in Agile volwassenheid van deze teams.

Waarom wil “de organisatie” inzicht in de Agile volwassenheid?

Vanuit Agile-land wordt vaak geroepen dat de belangrijkste redenen om de Agile volwassenheid te willen meten gaat om te bepalen welke teams goed en slecht zijn (met veelal verstrekkende gevolgen) of om te laten zien dat Agile in de organisatie simpelweg niet werkt en we terug moeten gaan op de vertrouwde traditionele projectmethodieken. Middels spreadsheet management en het vergelijken van teams wordt (voor teams ongewenste) invloed uitgeoefend wat de natuurlijke ontwikkeling van teams sterk in de weg staat (en daarmee ook de groei in Agile volwassenheid). Jammer, want ondanks dat het voorkomt, zien we dat dit zelden de reden is voor de wens vanuit de organisatie.

In het algemeen wil “de organisatie” juist hulp en ondersteuning bieden aan de teams, maar is onduidelijk waar ondersteuning nodig is of welke hulp gewenst is. Teams zijn dusdanig gesloten over hun performance dat het voor de buitenwereld nauwelijks inzichtelijk is of het goed gaat of dat er hulp gewenst is. Als dan een verzoek tot ondersteuning vanuit een team wordt gesteld, is de achterliggende reden vaak niet helder geformuleerd, waardoor het lastig wordt voor “de organisatie” om een zakelijke afweging van de investering te kunnen maken. Wat rechtvaardigt de inzet van een externe coach, kostbare tooling (meestal door de kosten van beheer) of nieuwe hardware (zoals een digitaal Scrum bord met touchscreen)? Inzichtelijk maken hoe de teams continu effectiever en efficiënter worden waarbij kwalitatief betere producten worden opgeleverd, helpt om de hiervoor noodzakelijke investeringen te blijven rechtvaardigen.

Een andere reden waarom “de organisatie” inzicht wil hebben in de Agile volwassenheid van de teams in hun organisatie is om team overschrijdende uitdagingen te kunnen adresseren. Kleinere issues binnen teams zijn veelal herleidbaar tot complexere organisatorische vraagstukken, met name in die organisaties waarin Agile zich nog tot de ICT-afdeling (en daarbinnen soms alleen de development teams) beperkt. Als je over de teams heen ziet dat teams met name beperkt worden in hun effectiviteit (producten opleveren die optimale waarde hebben voor de gebruikers) dan moeten in de organisatie andere maatregelen worden genomen dan wanneer de teams met name beperkt worden in het steeds efficiënter kunnen werken (en dus meer waarde tegen dezelfde inspanning kunnen opleveren).

Om te voorkomen (of juist te stimuleren) dat inzicht in de Agile volwassenheid leidt tot het direct ingrijpen (lees: micromanagement) in de Agile teams is het van belang om het inzicht op het juiste abstractieniveau te delen met de organisatie. Dus niet afzonderlijke aspecten zoals “De backlog moet met story points zijn ingeschat!” maar abstractere concepten als “Hoe kunnen we jullie ondersteunen om effectiever te gaan werken?”. Een abstracter concept leidt tot een discussie voor mogelijke oplossingen in plaats van directieven die de teams moeten gaan opvolgen.

Waarom wil “het team” inzicht in de Agile volwassenheid?

“Ik wil helemaal niet de Agile volwassenheid meten.” Één van de logische reacties wanneer wij met Scrum Masters praten over het meten van de Agile volwassenheid. In het daarop volgende gesprek komen de eerder genoemde punten standaard voorbij marcheren. Waarom zou je als Agile team inzicht willen hebben in jouw Agile volwassenheid?

Denk aan het gezegde “Meten is weten, gissen is missen.” Of aan Taiichi Ohno, bedenker van TPS, die stelde “Where there is no standard, there can be no improvement”. Inzicht waar je staat geeft een prikkel die leidt tot continu verbetering. Vanuit de praktijk komen we regelmatig bij teams die al een aantal jaren volgens Scrum werken. Wij kijken mee met de teams, praten met de teamleden, en na enige tijd volgt altijd de vraag “En, hoe doen we het?” De Agile coach of consultant vormt daarmee de externe prikkel en geeft antwoord op juist die vraag. Inzicht waar je staat en inzicht in welke experimenten vanuit hier het onderzoeken waard zijn. Het hebben van inzicht in de Agile volwassenheid is voor veel teams daarmee een impliciete in plaats van expliciete vraag.

Een andere reden waarom Agile teams inzicht willen hebben in hun Agile volwassenheid is om andere teams te kunnen helpen op die aspecten waar zij sterk in zijn en – over het algemeen vanuit een team meer belangrijk – hulp kunnen vragen of mee kunnen kijken bij teams die op aspecten juist verder zijn. Dit lijkt een klein punt te zijn, maar binnen organisatie met vele teams is het opvallend hoe weinig teams van elkaar leren. En hoe verbaast teams zijn wanneer je een vraag krijgt over een bepaald aspect je ze meeneemt naar een team enkele kamers verder om daar een voorbeeld te zien hoe het zou moeten. Hoewel het transparant maken van elkaars sterke en minder sterke punten niet een expliciete wens is, is de behoefte aan voorbeeldige collega-teams dat veelvuldig wel.

Ook voorkomt periodiek inzicht krijgen in jouw Agile volwassenheid tunnelvisie. Teams zonder of een laag referentiekader vormt zich over langere tijd naar “iets” wat zij volwassen Scrum of Agile noemen. De schok is groot wanneer deze teams dan dit inzicht wel krijgen. Hoewel de redenen waarom zij bepaalde dingen doen zoals zij deze doen vaak logisch klinkt, is het effect van deze acties inmiddels tot nul gereduceerd. Als we Shuhari, één van de concepten uit de Japanse krijgskunst, gebruiken in de vergelijking dan werken deze teams op Ha en Ri – niveau terwijl ze het Shu – niveau nog niet beheersen. Samengevat, het ziet er interessant uit, maar het is niet effectief.

Wel is het belangrijk om dat het meten van de Agile teams niet leidt tot onderlinge competitie, en groei van het ene team ten koste gaat van het andere team. Dit is met name belangrijk om in de gaten te houden binnen organisaties met ofwel een afrekencultuur of een sterke individuele beloningscultuur. Inzicht in de Agile volwassenheid gaat namelijk niet over ‘punten tellen’ maar over ‘continu verbeteren’.

Wat is nodig in een meting om de gewenste eigenschappen te stimuleren en de minder gewenste eigenschappen te ontmoedigen?

In onze ogen moet een goed assessment bijdragen aan zowel inzicht voor “de organisatie” als inzicht voor “de teams”. Dus zowel de discussie binnen het team voedt over de volgende stappen in hun Agile ontwikkeling als de organisatie inzicht geeft hoe zij de teams het beste kunnen ondersteunen en de juiste hulpvragen gaan stellen in plaats van op micro niveau de teams proberen te gaan managen.

Daarnaast moet een goed assessment zowel ingevuld kunnen worden door iemand met veel Agile kennis, maar vooral ook door mensen met weinig Agile kennis en ervaring. Want wat betekent een punt als “het team heeft een goede Product Owner” voor iemand die niet goed voor ogen heeft wat een goede Product Owner dan is. Het is dus essentieel dat meer om feitelijke constateringen wordt gevraagd, bijv. de resultaten die een goede Product Owner oplevert, dan om de aanname dat mensen weten wat een goede Product Owner is.

Spotify heeft overigens als onderdeel van zijn squad health check model een aardig overzicht opgenomen van richtlijnen die bijdragen aan het succes van een self assessment. Zij geven aan dat het belangrijk is om duidelijk te zijn over doelstellingen van het model wanneer deze geïntroduceerd wordt. Dat het belangrijk is om de data te verzamelen middels face-to-face communicatie, waarbij de discussie net zo belangrijk is als het verzamelen van gegevens. Dat er geen incentives worden gehangen aan het niveau het model en dat er een eenvoudige wijze is om de data te visualiseren.

Ook is het belangrijk om de teams een uniforme wijze te geven waarop de Agile volwassenheid wordt getoond. Niet om het individuele karakter van elke team teniet te doen, maar om het mogelijk te maken dat ook “de organisatie” op eenvoudige wijze kan zien hoe een team ervoor staat. Dat in plaats van spreadsheet management juist Genchi Genbutsu (oftwel het “Go and See” principe) wordt gestimuleerd. En dat in het kader van transparantie niet alleen data maar juist informatie wordt getoond.

In onze zoektocht naar een goed self assessment dat juist deze punten in zich heeft kwamen we vele voorbeelden tegen van assessments die sterk waren op één vlak, maar erg matig waren op de andere vlakken. En daarmee ook niet geschikt waren voor het doel dat wij voor ogen hebben.

In onze volgende blogpost gaan we daarom in op de wijze waarop we Agile teams effectief zijn gaan meten.

 

Jurjen de Groot is een gepassioneerde senior Scrum en Agile consultant en trainer die gelooft in de eenvoud van essentie van Agile. Door zijn unieke stijl van coaching laat hij organisaties zien dat een Agile adoptie van onder in de organisatie naar boven verspreid, erg haalbaar is.

Marco de Jong is een ervaren en resultaatgerichte senior Agile & Lean consultant en trainer met een achtergrond in management, software architectuur en software development. Door zijn passie weet hij anderen te helpen het beste uit zichzelf en hun teams te halen.

 

Heeft u een vraag?

Neem contact op