In de laatste twee blogs heb ik een inleiding gegeven op Scrum en de sterke punten van Scrum besproken. Deze blog staat stil bij de kritiek van mijzelf en anderen op Scrum.Er wordt wel eens geroepen dat Scrum zelfs toegepast is voor het bouwen van vliegtuigen. Ter introductie en vermaak een kort filmpje over hoe dat eruit zou zien: “Building a plane the Scrum way”
Scrum op zichzelf biedt niet voldoende handvaten voor projectmatige software ontwikkeling
De meeste organisaties die Scrum gebruiken, passen eigenlijk “Scrumbut” toe (“We use Scrum but… fill in any number of changes and extensions here”). Scrum is soms niet praktisch en tevens flinterdun op gebieden als ontwerp, change en release management, testen en projectmanagement. Daarom wordt op deze gebieden veelal geleend van methodes als XP, UML, ITIL en PRINCE2. Naar mijn mening mist er zoveel aan Scrum dat Scrum alleen (of Scrum plus XP) geen solide basis vormt voor projectmatige software ontwikkeling. De volgende alinea’s gaan dieper in op 3 onpraktische en missende delen van Scrum.
1) De Scrum rolverdeling is niet praktisch
De Product Owner moet volgens Scrum de bevoegdheid hebben alle beslissingen te nemen namens de opdrachtgever. In ICT projecten is dit veelal een manager die niet de tijd heeft om ook fulltime de Product Owner verantwoordelijkheden op zich te nemen. Tevens is de vraag in hoeverre een manager uit “de business” de vaardigheden heeft die horen bij de Product Owner rol (o.a. de scope nauwkeurig vastleggen, bouw volgorde bepalen). Scrum onderkent dit probleem niet en biedt ook geen handvaten hoe deze rol kan worden opgesplitst.
In Scrum is er geen projectmanager maar is het team “zelfsturend”. De Scrummaster is uitsluitend een coach en facilitator. Mijn persoonlijke ervaring is dat een team met een ervaren leider veel effectiever is dan een groep zonder leider. Op dit gebied mist Scrum naar mijn mening de project- en teamleider rollen. Ik denk dat dit anti-management sentiment in Scrum veroorzaakt wordt door slecht projectmanagement. Zo worden HBO+ werknemers nog te vaak gemicromanaged en wordt er meer gestuurd op het halen van deadlines dan op een goed resultaat. Dit pleit voor ander management, niet minder management.
Naast de Product Owner en Scrummaster rol bestaat er ook nog het Teamlid rol. Scrum maakt hierin geen onderscheid in rollen, sterker nog: alle teamleden moeten elkaars werk kunnen doen en alle rollen zijn fulltime met het project bezig. Ook deze rol is niet praktisch; de beste vaardigheden zijn veelal aanwezig bij de specialisten in plaats van in generalisten.
2) Scrum onderkent onvoldoende het belang van duidelijke requirements en een goed ontwerp
Scrum noemt “gedetailleerde documentatie” minder waardevol. Een valkuil in Scrum is dat ontwerp niet verder komt dan post-it’s en tekeningen op een whiteboard (het houden van ontwerp sprints zoals bijvoorbeeld in RUP/OpenUP is immers ook tegen de leer in). Uit onderzoek blijkt juist dat slechte specificaties de voornaamste reden zijn van projectfalen. Tevens weten we dat de kosten van software voor meer dan de helft in onderhoud zitten, en niet gedocumenteerde systemen een veelvoud in onderhoud kosten.
Scrum bevat geen ontwerpfase omdat wordt aangenomen dat ontwerpen niet begrepen worden en in 1 big bang naar de klant gaan.Dit is vandaag de dag nog maar zelden het geval, aangezien moderne ontwerp technieken als use cases en scherm prototypes door de klant heel goed te begrijpen zijn. Tevens worden ook ontwerpen tegenwoordig in meerdere iteraties opgeleverd in plaats van in 1 big bang. Klanten zijn ook meer en meer bewust van goed opdrachtgeverschap en daar valt ook zorgvuldig reviewen van ontwerpen onder.
Scrum stelt voor om ontwerp over te slaan en vanaf de eerste iteratie werkende software aan de opdrachtgever te laten zien. Dit betekent wel een duurder proces, want als de klant de werkende software niet bevalt moet de code worden aangepast. Als de klant de fout ontdekt in het ontwerp hoeft alleen het ontwerp te worden aangepast, wat een stuk sneller en goedkoper is. Tevens is het veelvuldig ombouwen van een applicatie veelal niet goed voor de code kwaliteit.
De enige ontwerp artifacts in Scrum, waarover voor de bouw wordt overlegd, zijn de User stories (op post-it’s) in de Backlog. De Backlog is een lange platte lijst van gewenste functionaliteit zonder groepering of hiërarchie. Bij veel User stories is dit al snel niet meer praktisch. Over veel gebruikte ontwerp technieken als requirements, use cases en wireframes (en het samenspel daartussen) roept Scrum niets, terwijl lang niet alle wensen in User stories te vatten zijn. User stories hebben weinig structuur waardoor veelal wordt teruggevallen op datgene waarvan ze zijn afgeleid: UML Use cases.
3) Er zijn ontbrekende schakels in het proces model van Scrum
De aantrekkelijke Scrum proces plaatjes laten niet de hele werkelijkheid zien. Met name processen in de beginfase en eindfase van het project missen. Tevens worden veel processen nergens volledig uitgewerkt (wat is het doel van het proces, wie is betrokken/verantwoordelijk, wat is de output, wat zijn de afhankelijkheden).
Enkele voorbeelden van zaken die binnen Scrum bestaan maar waarvoor het creatie en beheersproces mist:
- De “Definition of done” (wanneer is oplevering compleet)
- De (“groomed)” productbacklog, inclusief de uitwerking van de user stories en het groomen
- Testresultaten
- Estimations (wanneer, en hoe vaak worden er inschattingen gemaakt of bijgewerkt, wat gebeurd er als het team de user stories van de product owner te vaag vind?)
Naast dat er processen missen voor benoemde Scrum artifacts, zijn er ook belangrijke artifacts, plus bijbehorende processen, die missen. De belangrijkste twee zijn naar ontwerp en projectmanagement artifacts en processen. In de vorige paragraaf is het ontbreken van ontwerprocessen reeds besproken. Door het geheel ontbreken van een ontwerp en analyse fase vraag ik me af de opdrachtgever tijdig en weloverwogen keuzes kan maken over de kosten en duur van een project.
Tevens missen processen voor vaststellen, rapporteren over, en bewaken van het projectbudget en planning. Gerelateerd daaraan zijn de missende processen voor het omgaan met wijzigingen gedurende het project. De product owner kan de backlog naar wens aanpassen maar er is geen terugkoppeling over de kosten/haalbaarheid/kwaliteitsimpact van wijzigingen.
Conclusie: Not to Scrum ?
Geen enkele partij die software bouwt ontkomt eraan om zijn eigen software ontwikkelingsmethode(s) te ontwerpen en continu te verbeteren. Daarbij is het gebruikelijk dat de beste ideeën uit meerdere methodes worden gecombineerd. Scrum bevat vernieuwende invalshoeken en kan daarmee bijdragen aan een zo’n methode. Daarentegen is Scrum naar mijn mening te licht en onpraktisch om als fundament of zelfstandige methode te dienen (ook niet de combinatie van Scrum plus XP). Van de andere kant vind ik dat iedere bedrijf toch zeker 90% van de sterkte punten uit Scrum zou moeten toepassen in (een van0 zijn methode(s), zoals genoemd in de lijst uit mijn vorige blog.
Bronnen
- SCRUM Fails to get to grips with Human Psychology
- Is there a place for criticism of Scrum?
- Scrum presentatie van iSense Awareness
2
Reacties
roel lakmaker
Goed dat je dit model onder de loep neemt. Ik ben geen developer maar wel voorstander van klantgedreven ontwikkeling.
Ik zie door jouw kritiek vooral een lijn van hierarchie en controle. Doel is door kortere slagen efficienter te ontwikkelen. Kortere ontwikkeltijd en een klant krijgt wat hij wil. Volgens mij het grootste probleem in ICT is het gat tussen wat de klant uiteindelijk verwachte en krijgt.
1) Of de klant is degene met wie de ontwikkelslagen worden bepaald of een productowner die de rol van klant kan overnemen. Een product owner die deze rol niet goed op zich neemt functioneert niet. Het team zou dan de macht moeten hebben een betere klant rep te eisen. Anders valt het hele idee in het water.
2) Samen met de klant worden de meest belangrijke te realiseren functies bepaald voor de volgende iteratie. Het hele team moet snappen waar de klant in grote lijnen naar toe wil. Een bezoek bij de klant om een indruk te krijgen wat daar speelt is belangrijk. Het team beslist met elkaar wat nodig is om de functies op te leveren, maar weet ook de lange termijn doelstelling. Als geen goed basis wordt gelegd, is dat een tekortkoming in de samenwerking. De vraag is of iedereen gelijk is of dat het team toch te veel wordt geleid op basis van hierarchie. Feitelijk moeten developers de macht hebben om een goede architectuur definitie te eisen, sterker dat is hun verantwoordelijkheid. Idee van Scrum is dat het team zich verantwoordelijk gaat voelen voor het eind product en de te behalen resultaten voor de klant.
3) voor wie zijn die rapporten en verslagen dat is een goede vraag. Hier lopen twee manieren van organiseren door elkaar heen. De oude werkwijze van controleren en uiteindelijk weer sturen van mangement ipv team. Het team bepaalt zelf wat wordt geleverd, niet de manager. Het team is zelfverantwoordelijk en bepalen met elkaar wie wat gaat doen in het belang van de volgende op te leveren resultaten aan de klant (of klant rep.) Dus niet gaan doen wat iemand heel leuk vindt, of toevallig erg goed in is maar doen wat nodig is om de volgende slag te maken. En dit gaat zeker fout, daarom moet dagelijks met elkaar tekortkomingen, fouten worden besproken. Het is essentieel dat fouten zijn om van te leren en niet om de zwarte piet neer te leggen. Anders worden fouten verstopt en wordt er niet geleerd.
My 2ct
Ron
Ontwikkel-methoden moet je aan de experts / ontwikkelaars overlaten en niet aan managers, die aan de kantlijn staan te roepen, dat het veel sneller en goedkoper kan, geheel voorbijgaand aan de complexiteit, vindingrijkheid en kunst van software ontwikkelen
Vanaf de maan ziet de aarde er ook als een blauwe toverbal uit, maar 100 meter boven een stad ziet het er al een stuk ingewikkelder uit).
Pas SCRUM maar eens toe op bouwvakkers, die zouden je in je gezicht uitlachten en alles uit handen laten vallen en de boel meteen achterlaten en dat zijn niet eens de ontwerpers van het geheel.
SCRUM is respectloos en agressief en ontwikkelaars accepteren deze slavernij wegens gebrek aan zelfrespect, die mede wordt veroorzaakt door de minachtende en kleinerende houding van leidinggevenden, die denken/willen dat ontwikkelen even snel en simpel te schakelen is als american football, om zodoende weer meer bonussen op te strijken.
Plaats een reactie