Agile productiviteit


Agile kan een enorme boost geven in de productiviteit. Hyper-productieve teams halen wel 400% hogere productiviteit dan een gemiddeld watervalteam, terwijl bij die teams vaak ook nog eens de kwaliteit, klanttevredenheid en beleving van de ontwikkelaars veel hoger is. Althans, dat beweert Jeff Sutherland, auteur van de Scrum Guide. Nu klinkt dat wel erg mooi, maar als ik dat lees Hyper-productieve teams halen wel 400% hogere productiviteit dan een gemiddeld watervalteam, terwijl bij die teams vaak ook nog eens de kwaliteit, klanttevredenheid en beleving van de ontwikkelaars veel hoger is. komen er direct twee vragen bij me op:

  1. Hoe heeft hij dat gemeten?
  2. Waarom lukt dat in de praktijk vaak niet?

Meten van productiviteit

Op de eerste vraag wil ik niet te lang ingaan. Want waarschijnlijk roepen de antwoorden alleen maar meer vragen op. Vaak worden bij dergelijke productiviteitsmetingen ook appels met peren vergeleken.

Bij waterval worden schattingen vaak in functiepunten, locs (lines of code), uren en aantal requirements gemaakt. En in mindere mate wordt de voortgang daarin ook gemeten. Terwijl in agile grootheden als storypoints, business value en velocity worden gebruikt. Ook worden critical resources gemonitord, zoals de systeemperformance of geheugengebruik. Hier en daar worden minder tastbare zaken gemeten als klanttevredenheid, happiness, vertrouwen of leervermogen. Of indicatoren die te maken hebben met technical debt, zoals bugs, testcoverage, reviews, time to market of SQALE rating.

Aangezien de algehele productiviteit een resultante is van allerlei parameters, is het lastig om de productiviteit te vergelijken met andere teams of zelfs ten opzichte van het verleden. Toch is het voor de governance van met name grotere projecten en organisaties wenselijk om met een paar KPI's te kunnen zien wat de status is.

Belemmeringen in de praktijk

De tweede vraag is natuurlijk veel boeiender. Door onze energie te stoppen in zaken die binnen onze invloedssfeer liggen, kunnen we er in ieder geval naar streven om het maximale rendement uit onze teams te halen.

Bij veel organisaties waar ik kom is er wel een beeld dat werken met Scrum veel beter is dan traditionele methodes. Dat beeld is vooral van toepassing bij de mensen die echt in Scrum teams werken of er nauw mee samenwerken. Mensen die er iets verder vanaf staan zien dat anders. Vaak zijn dat mensen uit de business (de echte gebruikers), traditionele beheerders en higher level managers. Die zien voornamelijk mensen die veel overleggen met veel te veel mensen, met het idee dat ze alle vrijheid hebben om op te leveren wat ze willen. Ook hangen de muren vol met post-it's. Wellicht vinden ze het lastig dat ze al in een vroeg stadium bij het project worden betrokken. De kosten van al dat overleg zijn relatief eenvoudig aan te geven, maar de waarde...?

Ook komen veel verborgen gebreken veel eerder aan het licht, waardoor het ook lijkt alsof de productiviteit telkens afneemt. Denk daarbij aan achterstallige documentatie, slecht onderhoudbare code, onvoldoende performance, gebrekkige testen, of niet voldoende afstemming met de stakeholders. Bij traditionele aanpakken komen die aspecten pas aan het licht aan het einde van het project.

Verhogen teamproductiviteit

De belangrijkste indicator van de productiviteit binnen Scrum is de velocity, oftewel het aantal geleverde storypoints per sprint. Veel teams houden deze waarde wel bij gedurende hun project. De eerste paar sprints vertonen nog opstart en inslinger verschijnselen; de velocity schiet alle kanten op. Maar gaandeweg wordt een steeds stabielere referentie gevonden voor de waarde van een storypoint.

Vaak wordt begonnen met de afspraak dat een story point overeen komt met een ideale mandag, een dag waarop iemand ongestoord door kan werken. (In de praktijk lukt dat nooit, waardoor zo'n ideale mandag meer kost dan 1 werkdag.) Variaties van 1,2 tot 8 werkdagen kom ik regelmatig tegen. Toch is dit een redelijke indicator op de productiviteit te vergelijken, aangezien het getal niet afhankelijk is van de teamgrootte.

Dan komt de proof of the pudding. Vaak blijft de velocity stabiel, of daalt zelfs. Verklaringen daarvoor kunnen zijn dat het systeem groter en complexer wordt en dus meer onderhoud met zich meebrengt. Dat het nut van goede planningsessies en retrospectives niet wordt gezien. Dat reviews meer powerpoints blijken te zijn dan echte demo's, en uiteindelijk alleen de daily scrum overblijft. Kortom, het is makkelijk om weer voor een groot deel terug te vallen op de traditionele manier van werken.

Door de methode toe te passen zoals bedoeld, blijken enorme verbeteringen van de productiviteit mogelijk. Mijn ervaring is dat het vaak de kleine dingen zijn die grote impact hebben. Bijvoorbeeld het goed inrichten van het Scrum board, dagelijks bijwerken van status van de taak waar je mee bezig bent, snel verwijderen van impediments. De kennis zit in het team, het is alleen de kunst om het eruit te halen. Daarvoor zijn andere skills nodig die niet van nature in het team aanwezig zijn, maar met een beetje hulp wel vrijgemaakt kunnen worden.


Voor managers is het belangrijk om dat proces niet te veel te forceren. Als je resultaten afdwingt zonder dat er vertrouwen in het team is (zie bijgaande piramide), dan is het gevolg dat de velocity wel omhoog gaat, maar alleen omdat de schattingen dan omhoog gaan en niet de productiviteit.


Door de juiste stappen in het proces te nemen lukt het meestal om binnen 2 tot 4 sprints al productiviteitsverbeteringen te krijgen van 50 tot 300%.



Verhogen van de productiviteit van de organisatie?

Agile en Scrum is vooral geschikt voor 'kleinere, autonome' projecten. Maar echt succesvol is het pas als het geïntegreerd is in de organisatie. Als de 'spelregels' goed binnen de teams worden gespeeld, is een volgende stap het organisatie niveau. Aangezien veel organisaties met die uitdaging kampen, zijn er diverse initiatieven ontstaan, zoals SAFe (Scaled Agile Framework) , DevOps, diverse AMM's (Agile Maturity Model), ScrumBan, DAD (Disciplined Agile Delivery), Agile Transformations of Agile Architecting om hier handen en voeten aan te geven. Ook komen 'oude' technieken weer terug, zoals Lean en CMMI die agile zijn gaan omarmen.

Wel is het zo dat ieder team en iedere organisatie uniek is, dus is er ook geen heilige graal die altijd de beste is. De kunst is om maximaal gebruik te maken van frameworks in combinatie met de eigenschappen en doelstellingen van de organisatie.

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • Het einde van de projectmanager

    Een organisatie was al jaren bezig met een project om een oud systeem te vervangen door een nieuw systeem dat future proof moet zijn. Met meer dan 50 man werd er hard gewerkt. In de loop der tijd zijn er veel projectleden gewisseld, waaronder ook meerdere keren de projectmanager.

    Lees verder
  • Planning poker instructievideo

    Karel van de Meent geeft in de onderstaande video in vijf minuten een beknopte uitleg over de techniek van planning poker. Ook geeft hij enkele tips uit de praktijk.

    Lees verder