Waarom SCRUM niet voldoende is

 
25 september 2011

Hip hipper hipst: SCRUM is hot. Geen enkele zichzelf respecterende software engineer kan momenteel  zonder hoongelach te  ontvangen beweren dat hiij nog nooit van SCRUM gehoord heeft. En het bewijs is ook geleverd: zowel in diverse onderzoeken als gewoon in de dagelijkse praktijk blijkt SCRUM als ontwikkelmethodiek veel bij te dragen ten opzichte van waterval-achtig ingerichte ontwikkelprocessen.

Toch wil ik bij deze graag benadrukken dat SCRUM geen haarlemmerolie is en zeker geen oplossing voor de problematiek  die je bijvoorbeeld tegenkomt als je een product gaat ontwikkelen. SCRUM maakt zich er makkelijk vanaf: er is één ‘product owner’ op wie we alle verantwoordelijkheid betreffende de te ontwikkelen functionaliteit kunnen afschuiven. Daar kan het dan ook grandioos misgaan in mijn optiek.

Wat als je ‘product owner’ – ook maar een mens – namelijk zelf helemaal niet zo scherp heeft wat de markt van je product verwacht? Of wat als je de technische implicaties van een bepaalde keuze in je product backlog op de langere termijn niet kuntoverzien? Een productt owner-rol kan in mijn optiek maar zeer zelden door één persoon worden ingevuld. Het is in de dynamiek van productontwikkeling namelijk zo dat je vaak met een heel (management) team verantwoordelijk bent voor het welslagen van je product in de markt, en hoe kan één  persoon dan vervolgens al deze beslissingen maken voor een (vaak vrij priijzig) SCRUM team? Als je een team met een man of 5 aan het werk hebt en die stuur je één sprint de verkeerde kant op reken dan maar eens uit wat dat kost.

Kortom: met alléén SCRUM maken we ons er te makkelijk vanaf. Commercie en business moeten nog veel meer het proces ingetrokken worden op moment dat er een product ontwikkeld wordt. Vóór je het weet krijg je toch weer te maken met een klassieke ‘featurewaterval’, zonder dat deze features ook maar enigszins gerelateerd worden aan waar ze eigenlijk voor gemaakt worden: meerwaarde bieden voor je product (waarbij minder features soms juist alleen maar meer waarde kunnen toevoegen)!

Conclusie: Ken je product, bepaal de kenmerkende factoren en het onderscheidend vermogen in een ‘business architectuur’, en relateer al je stories / features in je backlogs aan deze businessachitectuur. Nog belangrijker: richt hier dan ook een proces rondomheen in. Dat doen wij dus ook :).


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Project- & procesmanagement, Architectuur

Tags: , , , ,