Hoe kun je agile ontwikkelingen besturen?

In de kern zijn bestuurders en agile ontwikkelaars het roerend met elkaar eens. Alles draait erom alleen te leveren wat echt nodig is, zonder hinderlijke belemmeringen of fouten, op het moment dat het nodig is en met de middelen die de organisatie zich kan veroorloven. De agile ontwikkelmethode pakt die uitdaging aan vanuit de overtuiging dat mensen in teams uitstekend in staat zijn zelfstandig bij te dragen aan de creatie van de goede dingen en om de dingen goed te doen. De mensen in agile-teams zullen hun doelen bereiken als zij daartoe de gelegenheid krijgen en niet worden verleid, afgeleid of gehinderd.

Dit is niet alleen de kern van de agile ontwikkelmethode. Het is ook de basis van leiderschapsmodellen op basis van empowerment, zoals de Levers of control van Robert Simons. Leiderschap op basis van empowerment en agile ontwikkelen passen bij elkaar. Een keuze voor een agile ontwikkelaanpak sluit goed aan op de wensen van bestuurders en is dan ook snel gemaakt. Zo heeft ook de Rechtspraak gekozen voor toepassing van agile ontwikkelen.

Vier beïnvloedingen

De praktijk blijkt vervolgens toch lastig te zijn. Agile werken vraagt om actief leiderschap. Leiders moeten actief de vier beïnvloedingen gebruiken zoals Simons die benoemt: beliefs, boundaries, diagnostic measures en interactive measures. Dat vullen we echter vaak in met patronen van management die afleiden van de kern, hinderen met bureaucratie of verleiden tot acties die niet bijdragen aan creatie van de goede dingen. Ook in een omvangrijk programma als de digitalisering van de Rechtspraak ligt de valkuil van allerlei managementstructuren om meer grip te krijgen continue op de loer. Laat ik uitleggen wat gewenste en ongewenste vormen van sturing zijn rondom een agile scrum-aanpak.

De scrummethode omvat spelregels (‘boundaries’) voor agile ontwikkelen en organiseert de interactie en meetmomenten. Scrum is een ontwikkelmethode die invulling geeft aan de uitgangspunten van het Agile manifesto (‘beliefs’) (zie het kader aan het eind van dit artikel, www.agilemanifesto.org).

Het interactiepatroon bij scrum bestaat uit een ‘heartbeat’ (de sprints met een ritme in termen van bijvoorbeeld twee weken) en dailies (de scrums of stand-ups).

Verleiding

Een team begint elke sprint met een sprint planning. Op dat moment is het van belang dat doelstellingen helder zijn: welke toegevoegde waarde willen we creëren? Van de leiding verwacht het team een duidelijke communicatie van de doelen (beliefs) om vervolgens zelf een backlog te kunnen produceren en prioriteren die leidt tot realisatie van de doelen.
Tijdens de sprint moet het team zijn werk kunnen doen. Het team is geholpen indien de leiding hen ondersteunt door oneigenlijke druk en verleidingen bij het team weg te houden en door het belang van ‘goed doen’ uit te dragen.
De sprint review draait om het opleveren van waarde: kan het resultaat worden toegepast en welke waarde levert die toepassing op. Als bestuurder draag je daaraan bij door te stimuleren dat wordt opgeleverd en door ook daadwerkelijk tot toepassing van het opgeleverde resultaat over te gaan: waarom deden we het, laten we dat dan ook nu gaan doen! Vraag vervolgens de doelgroep om feedback te geven op de toepassing, om de waardering kenbaar te maken.

Waar gaat het in de praktijk fout? De fout begint met het terugvallen op gangbare managementmethodes zoals de Plan-Do-Check-Act cirkel. (oorspronkelijk door Deming geïntroduceerd als PDSA-cycle)

In plaats van het communiceren van de doelen en de te realiseren businesswaarde is de interpretatie van ‘plan’ vaak: het maken van een uitgewerkt schema van achtereenvolgens uit te voeren activiteiten en te behalen resultaten die als een opdracht kan worden verstrekt aan een opdrachtnemer. De druk om de digitalisering van de rechtspraak zo in een plan uit te werken is continue aanwezig, en ja, soms doen we een poging. Dan ontstaat er een groot strokendiagram met deadlines, go-nogo-beslismomenten en gefaseerde oplevering en uitrol van de digitale zaakbehandeling. Om vervolgens weer en opnieuw te leren dat de werkelijkheid weerbarstig is: we realiseren wel onze doelen en toegevoegde waarde, maar niet volgens het bedachte plan. Conclusie: het maken van een groot ‘managementplan’ leidt niet tot succes, het leidt zelfs af. Het is beter om doelen en waarden helder te benoemen, in samenspraak een volgorde aan te brengen, en de ‘invitation to contribute’ uit te zenden.

Werk verdelen?

De interpretatie van ‘do’ is vaak het verdelen van het werk over verschillende teams of medewerkers die ieder een deelresultaat moeten opleveren. Werk verdelen is een managementpraktijk die niet optimaal is. Ook Deming betoogde dit al in 1984: “components of the plan are online slots implemented, such as making a product”. Het is beter om een ‘online slot’ te interpreteren als een sprint die een in praktijk toepasbare waarde oplevert. De valkuil om vanuit een centraal planbureau opdrachten uit te delen blijkt – ook voor ons – nog erg verleidelijk. Toch: waar de leiding teams vraagt om zelf aan te geven hoe zij in enkele sprints steeds waarde kunnen opleveren, om dit zelf in een frequent ritme onderling af te stemmen, en om zo de doelen te realiseren zijn we succesvoller dan waar een groot werkschema wordt verdeeld en teams deelresultaten opleveren.

De sprint review dient om te leren en input te verzamelen voor volgende sprints

Deming: “Next comes the Study step, where outcomes are monitored to test the validity of the plan for signs of progress and success, or problems and areas for improvement.” Het woord ‘study’ is gewijzigd in ‘check’. En het woord check interpreteren we vrijwel vanzelfsprekend als een inspectie achteraf om te controleren of aan specificaties is voldaan. Dit is niet correct!
De essentie van de sprint review is om door demonstratie en toepassing te constateren – in praktijk! – of de beoogde waarde optreedt. Met als doel om te leren en input te verzamelen voor volgende sprints, niet met als doel om aan te tonen dat we foutloos opleveren. ‘Fout is goed’, want daar leren we van. Inspecties achteraf zijn inefficiënt en voegen (op dat moment) geen waarde toe. Inspecties creëren angst, verleiden tot het verbergen van defecten of het voldoen aan inspectieregels (sjoemelsoftware). De enige echte waarde is toepassing in de praktijk. Kwaliteit van informatiesystemen blijkt uit de feedback vanuit die toepassing.

Geen kpi’s

Het vergt leiderschap om gelegenheid te bieden voor toepassing in praktijksituaties en om van de praktijk te leren. Dan leg je de focus op de outcome van sprints. Het zijn symptomen van management door vooral te vragen om project- en testrapportages. Daarmee let je vooral op de output. Een veel gemaakte fout in de besturing van agile ontwikkelen is om als leiding de scrummethode te gaan managen aan de hand van kpi’s (prestatie-indicatoren) zoals burndownrate en velocity. Doe dat niet: je legt de focus dan op de input en throughput die een agile team zelf kan en moet managen. Toon als bestuurder wel leiderschap: deel je visie, spreek aan op het (zelf) hanteren van de spelregels, participeer in opleveringen en doe geen concessies aan het belang van frequente interacties. En vooral, geef de teamleden vertrouwen!

Ook het overslaan van evaluatiemomenten, de ‘Act’-stap of de retrospective, ligt op de loer als de tijdsdruk oploopt. Dit is niet terecht. Als bestuurder ben je juist in de ‘Act’-stap aan zet. Niet één keer aan het begin van het project door een groot plan af te kondigen en aan het eind door een lint door te knippen of de stekker eruit te trekken, maar bij herhaling. Neem de situatie na elke oplevering van een sprint in ogenschouw en leer. Stel doelen bij als dat nodig is, communiceer dit voor de volgende sprint. Het mislukken van projecten is alleen te voorkomen door steeds te leren, bij te stellen en geen achterstanden te laten ontstaan.

Samenvattend

Samenvattend is het advies aan bestuurders om leiderschap te tonen aansluitend bij de heartbeat van agile ontwikkelprocessen.

• Tijdens de sprint-planning: zorg voor focus en interactie. Communiceer waarden en missie zodanig dat je teams uitnodigt tot het leveren van bijdragen die waarde toevoegen. Laat teams niet in onzekerheid verkeren over doelen: (Belief systems)
• Tijdens de sprints: zorg voor discipline op de werkvloer om goed werk op te leveren en om fouten snel te vinden en te herstellen. Wees duidelijk over de spelregels die gelden, zodanig dat je teams motiveert om gedisciplineerd en vakkundig te werk te gaan en die teams helpt om druk en verleidingen te weerstaan: (Boundary systems)
• Tijdens sprint reviews: zorg voor een ritme van frequente opleveringen. Organiseer duidelijke meetmomenten die teams aansporen om op te leveren en om de geleverde waarde te oogsten bij de doelgroep waarmee een gebrek aan focus is te voorkomen en geen grote vertragingen kunnen ontstaan. (Diagnostic measures)
• Tijdens retrospectives: stimuleer een open en lerende dialoog binnen teams, tussen teams en tussen teams en bestuur, zodanig dat een ieder wordt uitgedaagd om creatief en innovatief te zijn en zodat geen creatief vermogen verloren gaat door een gebrek aan gelegenheid of door angst voor risico’s. Wees zelf helder over de beschikbare middelen en voorkom besteding aan vermijdbare activiteiten (project obesitas). (Interactive measures)

Meer lezen:
• Levers of control
• Agile in the core

Agile manifesto in relatie tot levers of control

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we

Mensen en hun onderlinge interactie boven processen en hulpmiddelen (interactive)
Werkende software boven allesomvattende documentatie (diagnostic)
Samenwerking met de klant boven contractonderhandelingen (boundary)
Inspelen op verandering boven het volgen van een plan (belief)

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld,hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.

Twaalf principes van Agile software ontwikkelen:

• Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software. (belief)
• Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant. (belief)
• Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden. (diagnostic)
• Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project. (belief)
• Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren. (belief)
• De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten. (interactive)
• Werkende software is de belangrijkste maat voor voortgang. (diagnostic)
• Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden. (boundary)
• Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility. (boundary)
• Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel. (boundary)
• De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams. (belief)
• Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan. (interactive)