Browsed by
Tag: Agile

Hyperproductieve Scrum-teams

Hyperproductieve Scrum-teams

Hyperproductieve Scrum-teamsIn de Automatisering Gids van 31 januari staat een goed artikel geschreven door Charlotte Bendermacher, Vikram Kapoor en Rini van Solingen van Prowareness over Scrum. Op de site van scrum.nl is het artikel te downloaden als pdf. Het artikel beschrijft de vier randvoorwaarden voor het realiseren van hyperproductieve Scrum-teams. Hieronder deze vier voorwaarden:

1. Maak de meeste waarde eerst

Lever in een sprint alleen die software die de hoogste waarde heeft. Daartoe schrijft Scrum een enkele ‘product owner’ voor die deze waarde kent en keuzes maakt. Hierdoor zijn teams eerder klaar en kunnen sneller met ander werk starten. Dit zal de productiviteit van veel teams al snel verdubbelen. In de praktijk zien we echter veel organisaties worstelen met deze rol van product owner. In veel gevallen is er geen product owner of deze persoon heeft veel te weinig tijd of mag geen keuzes maken. Door niet effectief op waarde te prioriteren wordt de eerste stap naar hyperproductiviteit dan niet gerealiseerd.

2. Doe alleen haalbaar werk

Aangezien Scrum-teams elke twee weken werkende software moeten opleveren, is het noodzakelijk dat ze alleen werk oppakken dat ook echt afgemaakt kan worden. Het team werkt alleen aan dat wat af kan komen en veel waarde heeft. Hierdoor wordt de productiviteit al snel twee keer zo hoog. Om dit te realiseren werken Scrum-teams met een lijst van criteria waarop staat of werk helder genoeg is. Deze lijst noemt men de ‘Definition-of-Ready’ (DoR).
In de praktijk zien we echter veel teams grote delen werk oppakken dat nog niet helder is. Veel teams werken niet met een Definition-of-Ready of houden zich er niet aan. De kans dat de software aan het eind van elke sprint ‘af’ is, wordt daardoor veel kleiner. De tweede stap om hyperproductiviteit te realiseren wordt hierdoor niet ingevuld.

3. Maak werk echt af

Zorg dat elke sprint werkende en geteste software oplevert die naar eindgebruikers toe kan. Rework wordt hierdoor voorkomen, bugs worden veel sneller gevonden en opgelost, en bijsturen wordt mogelijk. Tegelijkertijd is het een behoorlijke ingreep voor ontwikkelteams. Immers, testen mag niet worden uitgesteld maar moet binnen elke sprint worden gedaan. Dat vraagt om een andere test-mindset. Functionele testautomatisering en waar mogelijk automatische integratie zijn nodig. Om software ook echt af te maken, werken Scrum-teams met een lijst van criteria waarop staat wanneer software echt ‘af’ is. Deze lijst heet de ‘Definition-of-Done’ (DoD).
In de praktijk zien we veel teams met Scrum werken, maar niet elke sprint levert werkende en geteste software op. Er is geen Definition-of-Done of zij wordt niet nagekomen. De derde stap naar hyperproductiviteit wordt daardoor genegeerd.

4. Word steeds beter

Het idee van Scrum is om elke sprint te leren en daardoor steeds beter te worden. Stabiele teams die elke sprint beter worden, zorgen minimaal voor een productiviteitsverdubbeling. Veel organisaties vinden het echter erg lastig om teams stabiel te houden. Het frequent wisselen van mensen over teams maakt deze teams juist langzamer. Bovendien is het ‘beter worden’ voor veel teams lastig doordat de grootste belemmeringen om hyperproductief te worden vaak buiten het team liggen (testomgevingen, toegang tot gebruikers, heldere businesswaarde). Het management heeft nog onvoldoende door dat het zijn taak is om de teams te helpen deze belemmeringen weg te nemen. Daarmee wordt de vierde stap om hyperproductiviteit te realiseren geëlimineerd.