Reliable Projects

Hoezeer ik het ook omarm, hier zijn 10 redenen om bedachtzaam te zijn met Scrum.
Aangezien ik er nu eenmaal groot voorstander van ben dat met gezond verstand wordt nagedacht over de  werkwijze die het beste past bij de uit te voeren taken, hoop ik door het schrijven van dit artikel met 10 redenen om bedachtzaam te zijn met Scrum een bijdrage te kunnen leveren aan het inzicht op dit gebied.

In een eerder artikel gaf ik 10 ToC-redenen om Scrum te omarmen. Deze keer heb ik ervoor gekozen niet vast te houden aan ToC-specifieke redenen. De lezer die ermee bekend is zal in de onderstaande 10 redenen om bedachtzaam te zijn met Scrum slechts hier en daar elementen uit ToC en ToC-projectmanagement herkennen.

1. Interactie met uiteenlopende stakeholders 

Een van de principes in het Agile Manifesto is dat de ontwikkelaars dagelijks nauw samenwerken met de mensen die de business kennen. Hoewel in Scrum de product owner verantwoordelijk is voor het prioriteren van de user stories op de product backlog, eventueel gevraagd kan worden een user story toe te lichten en een accepterende rol speelt in de sprint demo, is zijn rol voor het overige vrijwel niet uitgewerkt. Het kan om allerlei redenen uitermate belangrijk zijn om de steun van uiteenlopende stakeholders voor het project te borgen. Het verdient dan ook aanbeveling op dit punt aanvullende maatregelen te nemen.

2. Behoefte aan sturing op functionaliteit

De behoefte om agile te zijn neemt toe naarmate er meer onzekerheden zijn. Dat kan zijn vanuit het businessperspectief of vanuit de softwareontwikkeling bijvoorbeeld op het vlak van technologie en/of functionaliteit. Juist bij toenemende onzekerheid neemt ook het belang toe om de business te betrekken in de besluiten die gaandeweg genomen moeten worden om de scope afgestemd te houden op de business goals. Er zijn voorbeelden van functionele sprintteams en workshops die beogen de product backlog te vullen en te prioriteren. Een uitstekende aanpak die eigenlijk nooit zou mogen ontbreken.

3. Behoefte aan sturing op business goals

Er kan sprake zijn van een wettelijke maatregel als gevolg waarvan er een deadline geldt voor een project. Los daarvan is het voor elke organisatie noodzakelijk te kunnen sturen op het behalen van business goals. Dat geldt ook wanneer softwareontwikkeling een belangrijk onderdeel is van de activiteiten die daartoe worden ondernomen. Dan is het zaak om, hoe onzeker soms ook, te trachten een zo compleet mogelijk beeld te krijgen van de totale doorlooptijd die nodig is om de benodigde software te realiseren. Scrum biedt in dit verband voor het realiseren van de software een grafiek waarin met behulp van de velocity trendline en een work added-removed trendline een indicatie gegeven kan worden voor het afhandelen van de productbacklog. Daarvoor moet wel eerst een min of meer volledig beeld wordt verkregen van de productbacklog die moet worden afgehandeld om in het kader van een een gegeven business goal de software te realiseren. Veelal zullen er daarnaast nog andere activiteiten moeten worden uitgevoerd. Voor de complete set aan activiteiten die nodig zijn om de business goal te behalen biedt Scrum geen voorzieningen. Hoe daarmee om te gaan wordt in het artikel over Reliable Scrum uitgelegd.

4. Weining onzekerheid.

Hierboven is al aangegeven dat de behoefte om Agile te zijn toeneemt naarmate er meer onzekerheden zijn op bijvoorbeeld het vlak van technologie en/of functionaliteit. Maar wat nu te doen als er nauwelijks onzekerheid is en heel goed kan worden aangegeven wat er gemaakt moet worden en hoe dat moet. Er zijn talloze redenen aan te voeren om ook in een dergelijke situatie Scrum toe te passen. (Zie ook: 10 ToC-redenen om Scrum te omarmen) Het verdient echter wel aanbeveling eerst na te gaan of de verbeteringen die u wilt bereiken wellicht beter of gemakkelijker met andere werkvormen bereikt kunnen worden. Scrum is één van vele agile benaderingen en ook uit bijvoorbeeld het Lean gedachtegoed zijn talloze instrumenten toe te passen om de processen te verbeteren.

5. Deployment op de productieomgeving is niet na elke sprint mogelijk

Een van de principes uit het Agile Manifesto stelt als enige maatstaf van vooruitgang de hoeveelheid werkende software ingezet in een productieomgeving. Scrum meet de voortgang van sprints met behulp van Sprint Backlog grafiek waarop de voortgang zichtbaar is aan de hand van de taken die door de ontwikkelaars zijn afgewerkt. Dat zijn niet door de klant geaccepteerde features zoals het algemeen aanvaarde agile principe bedoeld. Ok, tot zover is dit natuurlijk academisch; het is al heel mooi als de business aan het einde van de sprint over de nieuwe features kan beschikken! Dat is in de praktijk echter vaak niet mogelijk. Bijvoorbeeld omdat er na een sprint een incomplete set features wordt opgeleverd of de inspanning voor de ketenintegratietest en de deployment op de productieomgeving erg groot zijn. Kennelijk zijn dit nu dus de bottleneck’s in het softwareontwikkelproces. In plaats van meerdere sprints uit te voeren voordat de oplevering kan plaatsvinden wordt aangeraden eerst na te gaan of deze bottlenecks kunnen worden weggenomen. Anders gebruiken we weliswaar een agile achtige werkvorm voor het realiseren van de software, maar het proces van softwareontwikkeling als geheel is pas agile wanneer het de business helpt dat te zijn.

6. Managen schaarse resources

Ere wie ere toekomt; ik kan dit punt niet beter uitleggen dan Albert Ponsteen doet op zijn blog over multiprojectmanagement: “Scrum is not a multi-project solution. It is a multiple-single project solution, using dedicated teams. By doing this, scrum kills the number 1 disturbance in a multi project environment: the non-availability of resources. This is why it so successful and beloved by engineers and project managers. Projects can be delivered in no time. But speed is not for free! The price for speed is efficiency. Dedicated project teams are extremely expensive! To get more out of your company, scarce resources must be shared! The scrum-of-scrum meeting should be supported with an excellent view of the resource status of the different skills. It should be obvious to the ambassadors, scrum masters and the resources themselves where to allocate their scarce capacity on the spot.”

7. Focus nodig

Als we tijdens het werken veelvuldig van taak moeten wisselen moet ons brein de context van de onder handen taken onthouden. Mensen zijn daar niet goed in; het menselijke brein is slechts zeer beperkt in staat om te multitasken. Als de taken eenvoudig van aard zijn is dat niet zo schadelijk, maar naarmate de complexiteit toeneemt hebben we meer en meer behoefte om ons te kunnen concentreren. Binnen een Scrum team helpen de teamleden elkaar en vindt veelvuldig interactie plaats. Het is met andere woorden een multitasking omgeving. Voor relatief eenvoudige softwareontwikkeling gaat dat prima, maar naarmate de complexiteit toeneemt zullen er afspraken binnen het team moeten worden gemaakt om erin te voorzien dat de teamleden zich kunnen concentreren en het is zelfs de vraag of bijvoorbeeld de bouw van complexe reken- en verwerkingsprogramma’s zich er überhaupt voor leent om binnen een scrum context te worden uitgevoerd.

8. Kwaliteitsborging / Testen

Scrum is voortgekomen vanuit het perspectief van de softwareontwikkelaar en besteed waarschijnlijk daardoor weinig aandacht aan specifieke activiteiten die nodig zijn om de kwaliteit van de software te waarborgen. Door de aard van het testwerk is dit (met uitzondering van de ketenintegratietest) prima te verenigen met activiteiten die in sprints worden uitgevoerd. Aandacht voor de kwaliteitsborging zal de succeskans voor de invoering van Scrum aanzienlijk vergroten. Een prima handreiking daartoe biedt bijvoorbeeld het boekje TMap NEXT in Scrum. Het geeft een mooie mapping van de TMap testactiviteiten in het Scrum framework. Waar het boekje helaas niet op ingaat is hoe het een en ander zich concreet vertaald in de testen die dan feitelijk uitgevoerd worden. Een professioneel tester weet daar in de praktijk naar verwachting wel raad mee en er zal hierover ongetwijfeld ook literatuur beschikbaar zijn en/of verschijnen.

9. Leverancier in het project

Hoe te handelen wanneer vanuit de gebruikersorganisatie het bouwen van de programmatuur is uitbesteed aan een softwareleverancier? Deze gebruikersorganisaties zijn waarschijnlijk gewend op basis van een goed doordacht pakket van functionele specificaties een workpackage aan de softwareleverancier uit te besteden en bij de oplevering uitgebreide acceptatietesten uit te voeren. Dit is een belangrijke barrière voor het invoeren van Scrum. Is de relatie met de leverancier zodanig om te vormen dat de organisatie werk kan uitgeven aan de hand van een veranderlijke productbacklog en dat de kwaliteitsborging zo geïntegreerd plaatsvindt als in het vorige punt bedoeld?

10. Cultuur

In het artikel met 10 ToC-redenen om Scrum te omarmen zijn er 5 waarin aan de hand van de Engines of Harmony de positieve impact van Scrum op de groepsmentaliteit wordt aangegeven. Daarentegen wordt in de literatuur her en der erop gewezen dat  de omvang van de cultuurverandering die nodig is om agile te implementeren een risico vormt voor het slagen ervan. Zo worden bijvoorbeeld als kritieke succesfactor voor het slagen van agile implementaties aangewezen: Het feit dat de cultuur van de organisatie open moet staan voor discussie en onderhandeling, dat mensen vertrouwd moeten worden, dat de organisatie de beslissingen moet accepteren die de business vertegenwoordiger neemt.. Het is dus wel degelijk zaak er goed over na te denken of uw organisatie wel toe is aan Scrum.

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