Een Agile organisatie streeft naar high-performing en self-organizing teams. Eén van de eigenschappen dat een team high-performing en self-organizing maakt, is het tonen van ownership, of eigenaarschap in goed Nederlands. Optimaal wordt een team beschouwd dat zich als groep verantwoordelijk voelt voor het tijdig leveren van het afgesproken werk bij/na het afronden van een sprint. Het team krijgt van de organisatie het mandaat om zelf besluiten te nemen om zo op efficiënte wijze de geplande werkzaamheden uit te voeren. Maar zoals met alle eigenschappen is er bij eigenaarschap ook een te bereiken optimum.
Ownership, wat is dat dan?
“Je moet ownership pakken”. Het klink zo trendy en het is makkelijk gezegd, maar in de praktijk is het best moeilijk om in te vullen. Mijn ervaring is dat vaak niet duidelijk is waar dat ownership dan betrekking op heeft. Heeft dat betrekking op de kwaliteit van het product, de kwantiteit, het proces of juist de manier van (samen)werken? Een Product Owner, samen met zijn stakeholders, wil niet voor verrassingen komen te staan en tot op zekere hoogte betrokken blijven bij de besluitvorming. Developers willen graag een mooi product af leveren, maar de vraag is hoe waardevol elke change of fix is. Het is lastig om verantwoordelijkheid te geven en te nemen.
De Product Owner blijft sturen op waarde
Het is de verantwoordelijkheid van de Product Owner om er voor te zorgen dat de development teams werken aan de stories die de meeste toegevoegde waarde en rendement opleveren. Hij moet dus continu waakzaam zijn dat developers niet blijven doorontwikkelen op het moment dat eigenlijk al aan de exit-criteria is voldaan. Daarmee wordt voorkomen dat er bijvoorbeeld nog bevindingen worden opgelost die in zeer beperkte mate waarde toevoegen. Hij moet zich er van bewust zijn dat developers en acceptanten van bijvoorbeeld een Operations afdeling vanuit hun verantwoordelijkheidsgevoel het product blijven verfraaien. Het is aan de Product Owner om de exit-criteria scherp te definiëren en het team te helpen bij het inschatten van de business impact van openstaande activiteiten.
Het Development Team blijft leveren
Het Development Team maakt continu beslissingen met betrekking tot de producten die het team maakt en de wijze waarop ze die producten maken. Dat maakt een team zelf-organiserend en effectief. De vraag is of het team in staat is om zelfstandig alle beslissingen te nemen met betrekking tot de kwaliteit van het product of de wijze waarop producten tot stand komen. Kan het team van meet af aan inschatten of het zinvol is om bepaalde use cases te ontwikkelen, tooling te optimaliseren, te werken aan de performance of bevindingen op te lossen? Ik vind dat je dat niet van een team mag eisen. Je hebt af en toe input over de waarde van bepaalde verbeteringen nodig of iemand die beslissingen kan challengen. Een developer wil zijn werk optimaal organiseren en vaak een zo fraai mogelijk product opleveren. Dat gaat veelal onopgemerkt ten koste van de waarde van de output.
De juiste mate van eigenaarschap, met betrekking tot alle rollen binnen een Agile team, is niet vanaf dag één aanwezig. Het moet zich ontwikkelen en dat vereist transparantie, afstemming en vooral acceptatie. Iedereen moet weten op welke aspecten eigenaarschap gewenst is en kaders hebben waarbinnen hij eigenaarschap kan tonen. In beginsel is het aan te raden om dat bijvoorbeeld in de vorm van duidelijke en specifieke acceptatiecriteria vast te leggen. Naar mate het team meer volwassen is, zullen de verhoudingen tussen de verschillende rollen steeds duidelijker zijn en kan de impact van besluiten veel beter worden ingeschat. Dat is ook het moment om het aantal aspecten te vergroten waarop je als organisatie eigenaarschap wil ervaren van een development team. Pas op dat moment is eigenaarschap effectief en van grote waarde.
