De laatste tijd zie ik steeds meer dat Scrum wordt aangeboden door IT-partijen als dé manier om ontwikkeltrajecten uit te voeren. De flexibele (’agile’) aanpak draagt bij aan het succes.
Dit in tegenstelling tot de klassieke ‘watervalmethode’ waarbij eerst alle specificaties worden opgesteld voordat er wordt gebouwd. Dit leidt vaak tot ’scope creep’, een enorme lijst van ‘requests for change’ en – mogelijk nog erger – tijd- en budgetoverschrijdingen.
In de Automatisering Gids las ik een heldere uitleg over Scrum. De insteek van dit artikel is dat Scrum ook – in de regel door watervalmethodes gegarandeerde – ‘fixed price’ projecten aankan. Ik ben niet geheel overtuigd, maar dit artikel is zeker de moeite waard om te lezen.
Drie voorbeelden van ‘fundamentele denkfouten’ in IT-projecten die Scrum zou oplossen neem ik even integraal over.
1. Requirements moeten eerst volledig en compleet zijn vastgelegd voordat er wordt ontworpen, en er moeten eerst volledige en complete ontwerpen zijn voordat er kan worden gebouwd en getest.
Dit is een denkfout, omdat het verkrijgen van feedback nooit moet worden uitgesteld. Immers, hoe eerder er feedback is, hoe eerder het duidelijk wordt dat er fouten gemaakt zijn, zodat er eerder ingegrepen kan worden en nutteloze inspanningen worden voorkomen.
2. Volledig en gedetailleerd documenteren en opschrijven is noodzakelijk en beter dan het maken van ruwe schetsen die vervolgens worden besproken.
Dit is een denkfout, omdat het nut van documentatie is: het overdragen van concepten en modellen aan mensen. Dergelijke concepten en modellen worden veel sneller en effectiever overgedragen door erover te discussiëren en vragen te stellen. Uiteindelijk gaat het om het leerproces, niet om het document.
3. Wijzigingsverzoeken zijn een verstorende factor en succesvolle projecten moeten daarom hun scope keihard bevriezen en bewaken.
Dit is een denkfout, omdat de belangrijkste reden achter een wijzigingsverzoek is dat er voortschrijdend inzicht bestaat. Met andere woorden: het idee van een wijzigingsverzoek is dat dit het eindresultaat beter maakt. Dat negeren zou fundamenteel fout zijn. Verzoeken om verandering moeten daarom een centrale plaats krijgen in het werkproces.
Lees het Automatisering Gids-artikel
Zie ook:
