Drie 'onverwachte' factoren om een Scrum team hyperproductief te maken

De term hyperproductieve teams komt steeds vaker voor als wens vanuit een organisatie.  Het boek van Jeff Sutherland “doing twice the work in half the time” heeft daaraan bijgedragen. Want wie wil nu niet wat deze titel belooft?  Maar is het wel zo makkelijk? Men denkt dat het gaat over veel meer doen, maar het draait om andere dingen doen: twee keer zoveel nuttig werk doen in de helft van de tijd – en dus geen activiteiten, die afleiden van belangrijkere zaken.

Mede door de term hyper productieve teams is de focus van de acties om zo’n team hyper productief te maken gericht op het team zelf. Vaak is er voldoende te verbeteren aan het team zelf, maar er is meer nodig. Om echt effectief zoveel mogelijk waarde te kunnen leveren zal het team hulp moeten krijgen van de omgeving in de vorm van management, stakeholders en klanten of gebruikers.

1. Laat de rest van de organisatie aansluiten op agile werken

Op het moment dat Scrum team leden samenwerken met mensen moeten werken die niet in dat Scrum team zitten, past het Scrum team zich vaak aan de “oude” manier van werken aan om aansluiting te vinden. Dit kan zo ver gaan, dat verschillende Scrum teams onderling zelfs de “oude” manier van communicatie aanhouden en alleen binnen het team agile werken. Dit leidt alleen maar tot het opleveren van meer impediments en dus minder waarde.

Een betere oplossing is, om (langzaamaan) de organisatie om die Scrum teams mee te laten bewegen in een agile manier van werken. Het begint met snappen wat de teams doen en waarom ze op die manier werken en kan zelfs zover gaan, dat de afdelingen die nauw betrokken zijn bij de Scrum teams zelf ook agile gaan werken.

Denk hierbij aan processen als nieuwe medewerkers in het team, toegangsrechten en het aanvragen van hulpmiddelen. Door de verantwoordelijkheid bij alle medewerkers te leggen en medewerkers niet te laten wachten op rechten of applicaties om hun werk te doen, zal een team meer eigenaarschap tonen.
Het effect is, dat het Scrum team haar eigen processen kan inrichten op de meest effectieve en efficiënte manier om de meeste waarde te kunnen leveren.

2. Pas de management structuur aan

De organisatie is in de jaren gewend geraakt aan bepaalde structuren, overleggen en rapportages.

Een vaak gehoorde klacht na een transitie naar Scrum is, dat er zoveel overleggen zijn voor de medewerkers. En wat blijkt? Naast de (nieuwe) Scrum events heeft de manager van de afdeling alle overleggen in stand gehouden. Daarnaast worden rapportages verwacht van de Scrum teams. Zeker in het begin, als management de verandering nog spannend vindt.

De meeste informatie die men uit rapportages wil is beschikbaar via de Scrum events of artifacts. Denk bijvoorbeeld aan Sprint backlog, Sprint review en als je er als manager kort op wil blijven zitten kun je zelfs passief aansluiten bij Daily Scrums. Bespreek dit alles wel met je Scrum master, zodat het effect van jouw aanwezigheid niet per se tegen gaat werken.

Bedenk bij de niet-Scrum events wat je met die meetings wil bereiken. In hoeverre helpt het de Scrum teams om meer waarde te leveren?

“When a flower doesn't bloom, you fix the
environment in which it grows, not the flower.”
- Alexander Den Heijer -

 

3. Feedbackloop stopt niet binnen het team

Als men probeert de snelheid van opleveren te verhogen, denkt men over zaken als CI/CD, kleiner maken van user stories en vooral de snelheid waarmee een Scrum team een user story kan afmaken. Bij de meeste Scrum teams lukt het vrij snel om de user stories binnen een sprint te starten en af te ronden, maar dan zijn we er nog niet.

We hebben verschillende omgevingen, waarin de nieuwe functionaliteit getest moet worden (OTAP-straat bijvoorbeeld), misschien zijn er nog gebruikers acceptatie testen of zelfs een CAB, die akkoord moet geven. De vraag die je hier zou kunnen stellen: waar hebben we het voor nodig?

Als een user story binnen een sprint naar productie gebracht kan worden, kunnen echte gebruikers al gebruik maken van die nieuwe functionaliteit en feedback geven voordat de Sprint review gestart is. Deze feedback kunnen we dus al in de sprint review meenemen om betere besluiten te nemen om te bepalen, wat we in de volgende sprint gaan doen.

Nu kun je je afvragen: mooi verhaal, maar hoe gaan we om met de kwaliteit van de geleverde user story? Zowel technisch, als functioneel moet het wel goed werken, toch?
En dat klopt, maar meerdere “akkoord” momenten of “gates” werken twee belangrijke aspecten van een goed agile team tegen:

-          De feedbackloop wordt onnodig lang en daardoor duurt de aanpassing daarvan nog langer. (Het duurt minimaal één release cycle om feedback aan te passen in de applicatie en weer bij de gebruiker te krijgen, maar vaker is dat minimaal twee keer)
De waarde die geleverd kan worden neemt iets af.

-          Het team heeft minder de urgentie om eigenaarschap over de kwaliteit te hebben. Er zijn immers nog stappen na oplevering vanuit het Scrum team voordat het bij de klant komt, dus als “zij” het niet vinden, dan is dat niet onze schuld.

-          Het team is al verder gegaan met nieuwe functionaliteit en moet zich weer inlezen waar de feedback over ging. Dit kost het team ook meer tijd. Daarnaast wordt de kans groter, dat de teamsamenstelling veranderd is en dat degene, die de specifieke software gebouwd heeft weg is. De andere teamleden moeten zich nog verder inlezen in de materie

Zorg dus, dat de feedback loop nádat het Scrumteam klaar is met de user story zo kort mogelijk wordt. Hier haakt punt 2 - de management structuur - ook aan, omdat het opleverproces mee moet veranderen met het agile werken om er het beste resultaat van te hebben.

Conclusie

Kijk niet alleen naar wat het Scrum team kan veranderen om hyper productief te worden, maar kijk ook naar de omgeving om het proces van het team te verbeteren.

Wil je meer weten over hyperproductieve scrum teams? Of sparren over de mogelijkheden voor jouw organisatie? Neem dan contact met ons op via de chat of het contactformulier.

Alex Roos, DevOps consultant