Agile Informatie Technologie

en hoe Scrum toe te passen

Minimaliseer risico en time-to-market met Scrum

Waar de waterval aanpak uitgaat van een vast eisenpakket van functies die gerealiseerd moeten worden gaat Scrum uit van een aantal iteraties met een vaste lengte, gedefinieerde kwaliteit en vaste kosten. Een Scrum project kan na iedere iteratie worden beëindigd waarbij de belangrijkste functionaliteit werkend is opgeleverd. Een waterval project heeft die flexibiliteit niet. Pas als de laatste fasen van integratie en test zijn doorlopen blijkt wat de kwaliteit van het resultaat is.


Bij de waterval methode ligt vooraf het eisenpakket vast. Stapsgewijs wordt dit pakket uitgewerkt van functionele en niet-functionele eisen in een technisch ontwerp, realisatie, integratie, test en inbedrijfstelling. Tijd en kosten lopen uit bij veranderde eisen en tegenvallers. Om het project niet verder uit te laten lopen wordt op de kwaliteit beknibbeld tenzij een sterke QA functie dit voorkomt. Pas bij oplevering krijgt de business te zien hoe de uitwerking van het eisenpakket in de praktijk uitpakt. Zelden is er dan nog budget voor aanpassingen.

Bij de Scrum aanpak ligt de de duur van een sprint vast en wordt met de in de definition of done gedefinieerde kwaliteit dat deel van de gewenste functionaliteit gerealiseerd dat dan de hoogste prioriteit heeft. Na iedere sprint beoordeelt de business of datgene is opgeleverd wat werd verwacht. Bijsturing is direct mogelijk. Onzeker is of er genoeg geld en tijd beschikbaar is om voldoende sprints te doen om alle wensen te vervullen. Zeker is wel dat na beëindiging van het project de belangrijkste functies werken zoals verwacht.

Waterval stuurelementenScrum stuurelementen

De productiviteit met Scrum en offshoring
De toepassing van Scrum levert naast een betere risicobeheersing en de verkorte time-to-market, vrijwel direct een grotere kostenbesparing dan door offshoring kan worden bereikt. Een van de voorwaarden voor een optimaal Scrum team is dat het ontwikkelteam fysiek samenwerkt in één ruimte. Het directe contact tussen de leden van het multidisciplinaire ontwikkelteam en het regelmatige overleg met de business vertegenwoordigers is de reden van de productiviteitsverbetering.

Bij gebrek aan gekwalificeerde krachten kan het toch nodig zijn om van offshoring of nearshoring gebruik te maken. Mits goed opgezet kan ook dan de hoge productiviteit behouden blijven. Zie het onderzoek dat Jeff Sutherland in samenwerking met Xebia hiernaar deed.

Scrum brengt het plezier terug
Samenwerken, onderling taken verdelen, samen gáán voor het groepsresultaat, minimaal iedere maand een oplevering al dan niet gevolgd door een feestelijke afsluiting. Dit alles zijn de voordelen van een ontwikkelteam dat zelfsturend is. Dit is wellicht de belangrijkste factor die maakt dat met Scrum zo'n hoge, soms extreem hoge, productiviteit wordt gerealiseerd. Het zijn allemaal elementen die het plezier terugbrengen bij de leden van het multidisciplinaire team.

Oppositie en bezwaren tegen Scrum
Verandering betekent weerstand binnen de staande organisatie. Voor de business betekent Scrum dat zij gedurende het project niet achterover kunnen leunen in afwachting van de oplevering. Zij zijn actief betrokken. Al snel zal blijken dat die inspanning wordt beloond in snelle bruikbare oplossingen. Kortom, de medewerking van de business is snel gewonnen.

De specialisten die deelnemen in het ontwikkelteam zullen bezwaar maken omdat van hen nu verwacht wordt mee te helpen met alle voorkomende werkzaamheden. Een ontwikkelaar zal moeten helpen testen, een analist zal aan het eind van een sprint de presentatie van het resultaat voorbereiden etc. Mijn ervaring is dat na een viertal maanden ook de laatste tegenstander om is.

De grootste weerstand is te verwachten van functionarissen die een loketfunctie hebben. Als in de definition of done is opgenomen dat een aantal procedures met betrekking tot standaarden en kwaliteit worden gehandhaafd krijgen deze mensen het zwaar. Scrum staat niet toe dat een verzoek tot een beoordeling in een in-bakje verdwijnt en maar afgewacht moet worden wanneer het wordt opgepakt. Vóór de presentatie van het eindresultaat van de sprint zal het antwoord besproken en verwerkt moeten zijn. De druk om kort cyclisch te presteren is hoog. Ook zal vanuit het Scrum team druk worden uitgeoefend deze legacy procedures af te schaffen en binnen het team te beleggen.

Een veel gehoord bezwaar is dat Scrum begint met het opleveren van functionaliteit zonder eerst goed over de architectuur te hebben nagedacht. Ik dit artikel wordt dit bezwaar weerlegt. Met Scrum kan wel degelijk aandacht aan de architectuur worden besteed mits het team de product owner van de noodzaak weet te overtuigen.

Naadloze overgang van nieuwbouw naar beheer
Scrum wordt meestal geassocieerd met nieuwbouw of aanbouw van nieuwe functionaliteit. Toch vormt het beheer van bestaande applicaties de grootste kostenpost van de IT organisatie. Met een afgeslankt ontwikkelteam en een eventueel een switch naar een product owner uit de beheerorganisatie kan zonder overdracht het beheer worden vormgegeven.

Mede door het zelfsturende ontwikkelteam heeft Scrum al gauw een vier* maal hogere productiviteit, gemeten naar opgeleverde productierijpe software, dan een team dat met het waterval proces werkt. Dat leidt tot een nieuw probleem. De backlog kan niet op tijd worden aangevuld en uitgewerkt. De business wordt overvraagd en kan niet zo snel met nieuwe requirements komen.

(*) uit eigen ervaring

© 2006-2017 | Created by Erik Verheul