Onderstaande blog is door gastschrijver Rogier den Dulk geschreven.
Een van de twaalf van Agile principes is werken met zelf-organiserende, multi-disciplinaire development teams. Zelf-organisatie is wat mij betreft is dit één van de meest lastige principes van Agile om te realiseren. Het klinkt namelijk simpel, maar vaak wordt niet helemaal begrepen wat hier mee wordt bedoeld en zeer vaak onderschat hoe lastig het is om teams echt zelf-organiserend te maken.
Gelukkig zijn er methode om zelf-organisatie te stimuleren. In dit artikel zal ik hier één van toelichten.
Hoera, we zijn
zelf-organiserend
Zelf-organisatie betekent voor Scrum dat het (development) team zelf
verantwoordelijk is voor de werkinrichting en het resultaat dat
hieruit komt. Alles wat nodig is om het sprintdoel te bereiken wordt door het
team zelf georganiseerd, evenals problemen oplossen die in de weg staan om het
sprintdoel te bereiken.
Door onervaren buitenstaanders van het Scrumproces wordt dit ook wel eens gezien als “developers mogen doen waar ze zin in hebben”, maar dat verre van waar. Met zelf-organisatie geef je de developers de verantwoordelijkheid om te voldoen aan het commitment dat ze afgeven op het leveren van waarde. Ze zijn gebonden aan afspraken die ze maken met hun product owner en hebben tevens te maken met vele invloeden van buitenaf die bepalend zijn voor het succes.
Leiden doet volgen
Helaas kom ik vaak veel tegen dat product owners (PO) zich opstellen als de
leider van een team. Soms wordt dit ingegeven omdat de product owner zich
als een soort van opdrachtgever voelt voor het development team. In andere
gevallen komt dit voort uit een traditioneel leidinggevende, die de
rol van Product Owner op zich heeft genomen.
Het is belangrijk om te benoemen dat er geen hiërarchische relatie is tussen PO en development team; ze hebben uiteraard een aparte rol en verantwoordelijkheid, maar zijn onderdeel van hetzelfde team. Sterker nog, het behalen van een sprint doel is evengoed het resultaat van de PO (die zorgt voor waardevolle stories) en het development team, die zijn commitment waarmaakt.
De valkuil van een PO om jezelf als leider op te stellen is dat je zelf-organisatie in de wielen rijdt. Hier geldt de wetmatigheid: leiden doet volgen. Wanneer er sterk wordt gestuurd op een team, dan zal dat team zich geremd voelen om initiatief te nemen en als zelfstandige te opereren. Je veranderd dus professionals in dozenschuivers.
Zelf-organiserend is
niet vanzelfsprekend
Zelfs als er geen sterke leidende invloed uitgaat van een PO zullen
development teams het soms lastig vinden om zelf-organiserend te werken.
Gegeven door een cultuur of een hiërarchische organisatie waar ze uit
voortkomen is het geleerde gedrag opdrachten volgen. Maar ook een volle product
backlog draagt bij aan het gevoel dat er maar gewoon moet worden
“doorgewerkt” en geen ruimte voor reflectie of initiatief om werk slimmer in te
richten of processen of tools in te richten die ten goede komen van kwaliteit of
efficiency.
Om zelf-organisatie een “fighting chance” te geven kan het verstandig zijn om binnen een development team een aantal voorzieningen te treffen die kunnen helpen het gedrag te veranderen.
Implementeer Happiness
Een methode die ik zelf toepas om zelf-organisatie te stimuleren
is de implementatie van Happiness. Happiness is een met de PO afgestemd
‘budget’ (een percentage van de team velocity) dat wordt toegekend aan een
development team en zij naar eigen inzicht kunnen inzetten. Happiness
is feitelijk een mini-hackathon dat plaatsvind binnen de context van een
Sprint.
De spelregels van Happiness zijn als volgt:
- Het team in overleg met elkaar bepalen hoe dit budget wordt besteed (de uitvoering mag samen of individueel, maar er moet consensus zijn over het gebruik hiervan);
- Het team moet bij de review demonstreren/presenteren hoe het budget is besteed, waarom hiervoor gekozen is en wat de resultaten zijn.
De deliverables die uit Happiness komen lopen sterk uiteen, maar zijn altijd ten bate van het team. Uit mijn praktijk heb ik team zien komen met voorstellen van oplossingen voor vaak voorkomende verstoringen, proefopstellingen voor nieuwe tooling of technologie, de volgende stap richting continuous delivery, en ga zo maar door.
Happiness geeft vleugels
De echte opbrengst van Happiness is een shift in bewustzijn van zowel het
Development Team en de Product Owner.
Door het toepassen van Happiness leren development teams:
- ruimte te nemen voor hun eigen werkproces, door naar eigen inzicht tijd te besteden aan waar zij waarde aan hechten;
- verantwoordelijkheid te nemen over de tijd die ze besteden, door onderlinge afstemming en beslissingen te maken;
- zelf-organisatie het werk leuker maakt, door meer het voortouw te nemen in hun activiteiten.
Product Owners op hun beurt zien, dat:
- development teams kan vertrouwen te werken aan eigen zaken zonder dat de effectiviteit (sprint doel) in gevaar komt;
- de activiteiten waarvoor wordt gekozen bijdraagt aan de efficiëntie van het team en de kwaliteit van het geleverde werk;
- Op den duur de productiviteit (velocity) van het team zal stijgen.
Gun jouw team ook
Happiness
De praktijk leert dat teams die de vrijheid ervaren van het zelf
organiseren van hun werkzaamheden hen productiever maakt en bovendien veel meer
plezier krijgen in hun werk. Het team zal proactiever met de Product Owner
onderhandelen over de backlog items die voor hen relevant zijn.
Happiness is uiteindelijk slechts een hulpstuk voor zelf-organisatie. Zodra het Development Team zelf de ruimte neemt voor haar eigen belangen kan je overwegen de strikte budgettering los te laten en ze net als iedere stakeholder hun backlog items te laten verdedigen.