10 ToC-redenen om Scrum te omarmen

 

 

Waar het gepast kan worden ingezet elimineert Scrum grotendeels de behoefte aan de sturingsmethodiek zoals die in ToC-projectmanagement worden gehanteert. Toch wordt Scrum door ToC-consultants omarmd..

In mijn artikel over Reliable Scrum heb ik al aangegeven zeer positief te staan tegenover de scrumaanpak en heb ik beloofd in een ander artikel op de redenen daarvan terug te komen. Het is tijd deze belofte in te lossen. Ik zou geen ToC-adept zijn wanneer mijn redenen niet afkomstig zijn uit de ToC body of knowledge. Ik geef u 10 ToC-redenen om Scrum te omarmen!

 

1. Elimineren van lokale optima

Vanuit de behoefte om het softwareontwikkelproces beter te kunnen beheersen werd het op een kunstmatige manier in een aantal opeenvolgende stappen verdeeld. Denk in dit verband bijvoorbeeld aan globaal ontwerp, detailontwerp, coderen, testen, accepteren, implementeren. Er ontstonden daardoor verschillende specialismen die elk hun eigen lokale optimum gingen nastreven. De ontwerper streefde naar een zo goed mogelijk ontwerp, de ontwikkelaar wilde foutloos coderen en de tester een zo volledig mogelijke test uitvoeren. Het nastreven van het eigen (lokale) optimum veroorzaakte onder meer navolgende problemen:

    • Noodzaak tot inhoudelijke afstemming tussen de stappen onderling
    • Pieken en dalen in de vraag naar capaciteit
    • Belemmert inspelen op voortschrijdend inzicht
    • Veel management aandacht nodig om de problemen op te lossen

Scrum is een drastische vereenvoudiging van het software ontwikkelproces. Door het proces te reduceren tot één stap ligt de focus zoals ToC het nastreeft op het globale doel; het leveren van software die voldoet aan de definition of done.

2. De throughput wordt verhoogd

De waterval benadering van het software ontwikkelproces leidde tot lange doorlooptijden en veel onderhanden werk. Vanuit de ToC is bekend dat het terugbrengen van het onderhanden werk direct leidt tot verhoging van de throughput. Dat komt doordat er meer focus is op het afronden van het resterende onder handen werk.

Scrum verdeelt het werk in veel kleinere brokjes en reduceert de vrijgave van werk tot het aantal user stories dat binnen één sprint kan worden gerealiseerd. Het onderhanden werk wordt hierdoor geminimaliseerd en na iedere sprint wordt de toegevoegde waarde opgeleverd om in gebruik genomen te worden. De organisatie heeft hierdoor eerder de mogelijkheid om de gerealiseerde software in gebruik te nemen en zodoende waarde te genereren.

3. Altijd focus op hoogste prioriteit

Uit ToC projectmanagement is bekend dat het van belang is de projecten op volgorde van prioriteit te plannen. Ook binnen Scrum wordt dit onderkend. Al is het mechanisme anders en gaat het zoals in het vorige punt vermeld om veel kleinere brokjes werk in de vorm van user stories. De Scrum-productowner is ervoor verantwoordelijk eenduidig de prioriteiten van de user stories op de productbacklog aan te geven. Dit is de volgorde waarop de user stories in de sprintbacklog worden opgenomen en zelfs binnen de sprint worden de user stories in beginsel op volgorde van prioriteit compleet afgewerkt. Hierdoor is er altijd focus op de prioriteit zoals de productowner die heeft aangegeven.

4. De constraint lost zichzelf op

Binnen het sprintteam worden de leden geacht zoveel mogelijk elkaars taken te kunnen overnemen. Indien zich in de kennis en kunde onder de sprintteamleden in aanvang een bottleneck aanwezig is, dan zal deze bottleneck zichzelf in de loop der tijd oplossen doordat de andere teamleden leren dezelfde taak over te nemen. Hierdoor ontstaat een harmonieus team waarbinnen de capaciteit geoptimaliseerd is.

5. Elimineren van gedagseffecten die leiden tot verspilling

Door de sprintpoker en doordat ervaringscijfers worden opgebouwd ten aanzien van de velocity van het sprintteam wordt de inschatting van de hoeveelheid storypoints die in een sprint kunnen worden gerealiseerd gaandeweg steeds betrouwbaarder. Daarenboven zijn er als gevolg van een heldere definition of done en de hoge transparantie (visibility) van het proces geen verleidingen om tijd te verspillen aan de gedragseffecten zoals Goldratt die identificeert (Student Syndrome, Parkinson, Goldplating). In plaats daarvan is er afhankelijk van de geboekte voortgang tegen het einde van de sprint altijd de mogelijkheid een story terug te plaatsen op de productbacklog of een extra story op te pakken. In alle gevallen wordt tot het einde van de sprint doorgewerkt.

 

Voordat ik verder ga met de punten 6 t/m 10 uit de lijst met 10 ToC-redenen om Scrum te omarmen is een korte inleidende toelichting op zijn plaats. Knelpunten (bottleneck’s) die door hun tastbare aard gekenmerkt worden zijn relatief eenvoudig te herkennen. Maar wat nu wanneer het knelpunt niet tastbaar is? Voor situaties waarin het knelpunt niet een tastbare bottleneck is heeft Eli Goldratt de ToC Thinking Processes geïntroduceerd. Deze methodiek is gebaseerd op het feit dat wanneer doelen niet gehaald worden er aannames of overtuigingen zijn die contra-productief gedrag in de hand werken. In de loop der jaren ontdekte Goldratt (Gepubliceerd door Alan Barnard, Goldratt Research) dat er een 5-tal generieke oorzaken voor knelpunten in gedragssystemen te onderscheiden zijn. Hij noemde dit de Engines of Disharmony en hun tegenhangers de Engines of Harmony. Aan dit laatste zijn de navolgende punten 6 t/m 10 uit de lijst met 10 ToC-redenen om Scrum te omarmen gerelateerd..

 

6. Engine of Harmony 1: Precies weten hoe je moet bijdragen en weten dat deze bijdrage erkend zal worden

Scrum biedt een zeer heldere set aan regels en werkafspraken. Bovendien wordt in de daily standup meeting dagelijks aandacht besteed aan hetgeen ieder teamlid de afgelopen dag gedaan heeft en wat hij de komende dag gaat oppakken. Hierdoor is voor ieder teamlid steeds zeer duidelijk hoe hij moet bijdragen en dat deze bijdrage erkend zal worden.

7. Engine of Harmony 2: Precies weten hoe anderen moeten bijdragen en weten dat hun bijdrage erkend zal worden

In Scrum wordt zoveel mogelijk gewerkt met visuele hulpmiddelen die het werkproces en wat iedereen doet zeer transparant maken. In de daily standup meeting wordt het een en ander bovendien met elkaar besproken. Hierdoor weten de teamleden ook van elkaar precies weten hoe zij moeten bijdragen en dat hun bijdrage erkend zal worden.

8. Engine of Harmony 3: Alle regels zijn in overeenstemming met de doelstellingen van de organisatie

 De heldere set aan regels en afspraken waaronder de prioritering van de produktbacklog en het streven te voldoen aan de expliciet gemaakte afspraken die gemaakt zijn over de Definition of Done maken dat het realiseren van de doelstellingen optimaal worden nagestreefd

 9. Engine of Harmony 4: Discrepanties tussen bevoegdheid en verantwoordelijkheid worden systematisch onderkend en geëlimineerd

Het Scrumteam is als geheel verantwoordelijk voor het eigen proces. De daily standup meeting waarborgt dat ieder zijn taken naar behoren kan uitvoeren. Om discrepanties tussen bevoegdheid en verantwoordelijkheid met de omgeving te elimineren wordt de scrummaster ingeschakeld. Daarnaast is er de mogelijkheid van tussentijds overleg met de productowner.

10. Engine of Harmony 5: Er is een op knelpunten gericht proces van continue proces- en cultuurverbetering

In de vorm van de Sprint-retrospective voorziet Scrum erin om na iedere sprint tijd te nemen om de gang van zaken in de afgelopen sprint te evalueren en mogelijkheden na te gaan om het proces verder te verbeteren.

 

Hoe positief dit artikel ook getuigt over Scrum, het zal de lezer die mij enigzins kent niet verbazen dat een artikel met 10 redenen om bedachtzaam te zijn over Scrum reeds in voorbereiding is. Ik ben er nu eenmaal groot voorstander van dat met gezond verstand wordt nagedacht over de werkwijze die het beste past bij de uit te voeren taken. Ik hoop door het schrijven van deze artikelen daaraan een bijdrage te kunnen leveren.

Hieronder kunt u desgewenst reageren op dit artikel. Mocht u naar aanleiding van een of meer artikelen in deze blog vragen hebben en/of rechtstreeks met mij contact willen opnemen, schroomt u dan niet een e-mail bericht te sturen naar info@reliableprojects.nl


Leave a comment


Comments RSS TrackBack 2 comments