Tagcloud

Onderhoud en Scrum werkt niet?!

Geschreven door: gertjan oude vrielink

Ook agile softwareontwikkeling leidt uiteindelijk tot onderhoud. Het doel van incrementele agile softwareontwikkeling is om werkende software zo snel mogelijk uit te kunnen leveren aan de klant en zorgen dat deze er mee aan de slag gaat. Hiermee ontstaan tijdige feedback loops. Op een bepaald moment, wanneer de klant op de software vertrouwt om hun business te ondersteunen, gaat het team over van ontwikkeling naar onderhoud. Maar er is geen reden waarom teams hun werkwijze fundamenteel zouden moeten wijzigen eenmaal in dit stadium aanbeland.

Agile methodieken zijn ontworpen om kleine teams te helpen om te gaan met verandering, onzekerheid en het snel opleveren van software. Deze eigenschappen zijn minstens zo belangrijk in de onderhoudsfase.
Echter voor teams die zich de aanpak in de ontwikkelfase niet eigen gemaakt hebben, is er een extra uitdaging in de onderhoudsfase. Er wordt een groter beroep gedaan op reactievermogen en flexibiliteit. Niets beperkt ons om releases, zoals in de ontwikkelfase, te plannen voor een ‘pool’ van onderhoudswerk. Uiteraard laten niet alle issues zich keurig verzamelen en inplannen. En in een slecht geval blijven bugs over een langere periode opduiken. Hoe gaan we hier mee om, anders dan de oorzaken eens goed onder de loep te nemen?

De mate waarin teams slagen zich een aanpak als Scrum eigen te maken en het proces goed in te richten, draagt bij aan de nodige mythen rondom de aanpak. Dit neemt niet weg dat startende teams voor een uitdaging staan in onderhoudstrajecten, waar issues soms bijna dagelijks kunnen optreden. Het scrum team moet, ook in een onderhoudsfase, steeds aan de hoogste prio problemen werken. Het sprintplan wordt helaas voortdurend onder druk gezet (met al of niet echte!) showstoppers, met als gevolg dat taken toegevoegd worden midden in een sprint.

Een paar korte tips.

1) Zorg voor een korte sprint. Hiermee zet je de inhoud van de sprint minder onder druk.
2) Neem meer buffertijd bij het plannen van de sprint – een geëscaleerde issue zou zo maar geplande issues kunnen herroepen. Door bijvoorbeeld 20% buffertijd op te nemen, kun je showstoppers afhandelen zonder impact op het sprintplan. Als er zich geen showstoppers voordoen, gebruik je de begrootte tijd aan extra (high prio) items uit de buffer met issues.
3) Bewaak je kwaliteit en leg goede nadruk op agile testwerk voor oplevering.
4) Structureer het team zodat sommige teamleden zorgen voor 2de lijns support, terwijl de rest werkt aan de issues in de backlog.
5) Zorg voor voldoende overzicht i.p.v. het strikt werken aan een wachtrij. Kijk naar technische en operationele afhankelijkheden en naar beperkingen en risico’s.
6) Kijk naar het Scrum framework en tailor het naar onderhoudsbehoeften. Hoe zijn retrospective, daily scrum, planning, demo het beste in te richten? Scrum is geen keuzemenu, maar je moet het wel zinvol tailoren!
7) Als je met bovenstaande geen oplossing kunt vinden, kijk dan ook eens naar Scrum-ban. Het is een combinatie van Scrum en Kanban. Zie http://leansoftwareengineering.com/ksse/scrum-ban/ voor leuk artikel. De mindset en het analyseren van de bron van je problemen is echter belangrijker dan welke tools of methode je gebruikt!!

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution