agile-assessments-heaven-hell-1200

Soms neem ik op verzoek van het management assessments af onder hun agile teams. Het management wil dan graag weten hoe het er voorstaat, want er is het vermoeden dat het nog flink beter kan of moet. Dus graag een ‘nul-meting’ met een duidelijke schaal en aanbevelingen en van daaruit de verbetering inzetten. En vooral iets neutraals, gedaan door externe consultants, zodat er niet teveel politiek bij zou kunnen komen.

“I kissed a girl and i liked it”

Enige tijd geleden stond dit nummer in de download top 10 o.i.d. en ik hoor het nog regelmatig op de radio langs komen. Maar wat heel grappig is, er zijn twee varianten van dit liedje te horen. Variant één wordt gezongen door een jongen. Niks aan de hand, leuk liedje. Maar variant twee, je voelt hem al, is exact dezelfde tekst, wordt gezongen door een jonge dame! En dat is heel andere koek! Half Amerika heeft er van op zijn kop gestaan.

Het draait allemaal om wat je er mee doet

Wat ik bedoel is dat exact hetzelfde assessment in meerdere contexten iets totaal anders als resultaat kan hebben. Bijvoorbeeld:

Scenario 1 – Het management krijgt de resultaten van het assessment en vindt er wat van. Dit was dus goed of niet goed, volgens de maatstaven van de consultant. Hoe meer vakjes in het rood, hoe slechter het team. Het ene team belonen we, het andere straffen we. Want zo werkt het toch met managen? En de consultant of coach krijgt een vervolgopdracht voor de rode vakjes: doe er wat aan en zorg dat in drie maanden dat vakje groen is!

Scenario 2 – Enkel het team ontvangt de resultaten en doet daarmee wat het goed acht. Zo ontdekken ze misschien blinde vlekken (onbewust onbekwaam) of krijgen ze een bevestiging van iets dat ze eigenlijk wel wisten (bewust onbekwaam). Doe er je voordeel mee, team!

Scenario 3 – Het management én het team krijgen de resultaten en ze willen er graag met elkaar over praten. Hoe ziet het team het, hoe de manager? Hoe kan de manager het team helpen de zaken te verbeteren, met het assessment als gespreksleidraad.

Hell

Het eerste scenario is de hel voor agile teams. Ik denk dat het alleen maar averechts uitpakt. En als consultant/coach zou ik die (vervolg)opdracht niet aannemen. Ga eerst maar eens met het management in gesprek. Wel meer dan 75% kans dat je de opdracht kwijt bent, maar als je hem alsnog wel krijgt ben je de held. Er is een belangrijk kwartje gevallen, flinke winst voor deze organisatie.

Scenario twee getuigt nog niet van veel vertrouwen in elkaar, maar in ieder geval wordt het team op een volwassen, agile, manier aangesproken. Ik zeg “doen”, maar er is werk aan de winkel. Het management heeft een cruciale rol bij verbeteren en het kan zich niet afzijdig houden.

Hemel?

Scenario drie is de hemel, niet? Een assessment als ‘conversation starter’. Natuurlijk moet je als assessor ook je best doen zelf in die modus te zitten met je aanbevelingen. Dus niet “doe dit of dat” maar “bespreek eens of …, zouden jullie …”.

Kan het nog mooier? Ja het kan nog mooier, dat moet zelfs, want het ligt allemaal nog een flink tikkeltje ingewikkelder.

Shu Ha Ri

Assessments zijn bedacht door deskundigen die algemene uitspraken doen. Teams zouden ‘zo’ moeten werken, want dat hebben we heel vaak goed zien gaan of het zit in de zelf ontworpen methodiek. Je kan toch moeilijk een assessment voor elk team op maat ontwikkelen? Dan is het gedaan met het instrument en de onderliggende vergelijkbaarheid .

Maar het is juist hier dat het oppassen geblazen is. Want wie zegt dat het voor elk scrum team optimaal is elke dag maximaal vijftien minuten lang een stand-up te houden, etc. Zo bemeten we wellicht beginnende teams (Shu), maar teams die volwassener worden hebben lak aan dit soort assessments. Die zijn op het niveau Ha en Ri en lachen je vierkant uit met je default vinklijstje.

Een assessment zal dan echt de vorm van een dialoog moeten hebben. En sta er voor open dat jij als assessor ook leert van het team in plaats van enkel iets zenden andersom. Extern assessen heeft waarschijnlijk op dit HaRi niveau weinig zin. Het duurt zo lang voordat je die context snapt. Veel beter is het als teams met hun coaches en managers (ook coaches tenslotte) aan de slag gaan. Of was dat sowieso altijd al niet het beste idee?

Is alles gezegd over assessments als we ook Shuhari in ogenschouw nemen? Nee, want we kunnen nog steeds volledig de mist ingaan.

Scrummend de afgrond in

Ik maak het vaak mee: organisaties waar de teams near-perfect met Kanban of Scrum bezig zijn en dat iedereen dan denkt ‘dat het goed is’. Het doet mij denken aan lemmingen, die heel hard kunnen rennen, maar wel richting de afgrond. Je denkt misschien dat dat onzin is, omdat de Product Owner in haar wijsheid de stakeholders raadpleegt en de goede koers uitzet voor het team met de lemmingen.

Helaas. In grote organisaties staat een enkele Product Owner vaak machteloos. Hier is systeem denken nodig. Een team heeft geen visie (nou ja, vooruit, een micro visie), een organisatie hopelijk wel. Een organisatie wil ergens zijn in een aantal jaar en investeert daarin. Een team niet.

Dat gaat niet zomaar goed, dat team of die PO is niet zomaar ‘aligned’. Het gevolg: teams die alle kanten opgaan, langs elkaar heen werken of zelfs tegen elkaar strijden of tegen elkaar in werken, ongesynchroniseerd zijn, hun producten niet kunnen integreren tot een goed geheel, grotendeels zonder rationale of business case werken. Van een beetje betaalbare Enterprise Architectuur is geen sprake, het (ontwikkel)landschap ’verrommeld’. Zeg maar zoals een krottenwijk zich doorgaans ontwikkeld: zonder richting en structuur de ellende tegemoet.

Scaled Agile Maturity Model

Een methode als SAFe heeft dat heel goed begrepen. Een aantal van die systeem-denk-elementen komen hierin duidelijk terug. Teams groeperen zich rond waarde ketens, teams ‘moeten’ nu en dan synchroniseren. Managementrollen bewaken dat teams niet verworden tot zichzelf in stand houden ego’s maar nuttig blijven voor de missie. Enterprise Architectuur zorgt voor het ontwikkelen en gebruik maken van gemeenschappelijk infrastructuur en voorzieningen met gedeelde specialisten.

Een assessment dat zich richt op enkel het hard lopen van lemmingen in een team kan dus volledig de plank misslaan. Dit maakt een assessment dat wel rekening houdt met het systeem een stuk complexer. Dan moeten we heel wat vragen. Een voorbeeld van een assessment dat dit wel doet is het Scaled Agile Maturity Model dat grotendeels ontwikkeld door mijn huidige gewaardeerde collega Brian Teunissen. Dit model gebruik ik ook, met inachtneming van alle hier genoemde kanttekeningen.

Pindakaas

Dus ga je nou assessen voor die manager of niet? Het ligt complex. Misschien heeft het weinig zin, maar wat in ieder geval zin heeft is het meten van resultaat. Wat komt er uit de schoorsteen of wat voor metafoor we ook gebruiken? Een klant van mij noemde dat ooit ‘pindakaas’.

Voor teams is dat in de eerste plaats: frequent opleveren van werkende software van waarde, geaccepteerd door de beoogde klant in minimaal een realistische staging-omgeving.

En voor het systeem zijn er aanvullende metingen. SAFe geeft ook ruime invulling aan deze ‘metrics’, die met weinig moeite maar wel zo objectief mogelijk kunnen worden gemeten. Zeker de moeite waard om van dit soort metrics in te voeren want wat vind je nou echt belangrijker: rode of groene vakjes en aanbevelingen uit een assessment, of gewoon zien dat jouw systeem draait als een tierelier of dat de klad er in zit of komt?

Gemba

Ten slotte roep ik nog: Gemba. Want waarom moet die manager jou er eigenlijk bij halen? Zou hij niet zelf die werkvloer op moeten gaan? Had zij het niet allang moeten weten? Mijn advies: bespreek eens met het management wat hun tegenhoudt. Wat zien ze eigenlijk als meerwaarde in jou? Moeten zij niet aan de bak en ben jij hooguit hun coach?

Conclusie

Ik vind een assessment geen onzin, zeker niet in een Shu-situatie, maar zoals aangegeven moet het een zorgvuldige conversation starter zijn. Dus je moet met het team, coaches en het management snappen wat je aan het doen bent en hoe je er mee omgaat. Klanten die niet de ruimte geven voor die discussie kun je mijn inziens beter links laten liggen.

 

Erik Borgers combineert zijn jarenlange ervaring in architectuur en agile om deze twee paradigma’s elkaar te laten versterken. Erik publiceert hierover en spreekt hierover op nationale en internationale congressen.

Heeft u een vraag?

Neem contact op