Nog steeds mislukken veel IT-projecten: de kwaliteit valt tegen en de kosten en doorlooptijd lopen uit de hand. Het gevolg is dat klanten ontevreden zijn en ontwikkelaars teleurgesteld. De belangrijkste oorzaken voor het mislukken van veel projecten zijn: onduidelijke en zich wijzigende gebruikerswensen, teveel complexiteit om centraal aan te sturen en te weinig dialoog tussen opdrachtgever en ontwikkelaar.
Hoe het ook anders kan, vertelt Ad Rabenort, directeur van Covalent. Covalent ontwikkelt al enkele jaren met succes software voor tunnelveiligheidsinstallaties en voor bouwkundige inspectiesystemen volgens de ‘Scrum-methode’. De succesfactoren van deze methode zijn: duidelijke visie op het eindresultaat, continue afstemming van tussentijdse resultaten met gebruikerswensen en gebruik maken van het zelforganiserend vermogen van professionals.
Projectmanagement volgens Scrum
Traditioneel wordt software ontwikkeld via een zogenaamde watervalmethode. Iedere fase, zoals definitiestudie, functioneel ontwerp, programmeren of testen, heeft zijn eigen experts. Deze experts voeren hun taak uit en dragen het resultaat over naar ander experts voor de volgende fase. De eindegebruiker is vooral betrokken in het begin bij het opstellen van de eisen en veel later, typisch na 6-12 maanden, bij het testen en de acceptatie. Vaak blijkt dan pas dat de verwachtingen van de eindgebruikers en de ontwikkelaars ver uiteen zijn gelopen.
In 1986 werd in de Harvard Business Review een onderzoek gepubliceerd over succesfactoren bij projectmatig werken. De uitkomst van dit onderzoek was dat projecten met kleine (kruislings functionele) teams historisch gezien het beste resultaat leveren. Naar aanleiding van dit onderzoek ontwikkelden Sutherland en Schwaber het Scrum-proces (Bron: wikipedia).
Bij Scrum werkt een multidisciplinair team samen om in korte perioden, ‘sprints’ genoemd, steeds een aantal stappen vooruit te komen. (Deze manier van werken is vergeleken met de scrum uit de rugby wereld, vandaar de naam.) Bij Scrum worden de experts uit de verschillende fasen dus bij elkaar in één team gezet. Het team bestaat uit maximaal 7 personen zodat alle benodigde afstemming horizontaal kan plaatsvinden. Wat tijdens een sprint wordt gerealiseerd, wordt bepaald door de ‘product owner’. Deze persoon, die ook dagelijks in het team aanwezig is, zorgt ervoor, namens de opdrachtgever, dat er altijd een op prioriteit gesorteerde lijst met gebruikerseisen is gebaseerd op een duidelijke visie op het eindresultaat en het beoogde bedrijfsdoel. Bij de start van iedere sprint kan de product-owner opnieuw bepalen waar de prioriteiten liggen, en dus reageren op veranderingen in de markt. Het team wordt begeleid door de ‘scrum-master’ en houdt dagelijks bij aanvang van de werkdag een zogenaamde ‘scrum-meeting’ (ook wel ‘standup-meeting genoemd). In deze staande bespreking beantwoordt elk teamlid de volgende drie vragen: wat heb je gedaan?, wat ga je doen? en wat zijn je problemen? Daarna gaat het team weer aan het werk om de opdracht te volbrengen. Tijdens een sprint staan alle taken duidelijk zichtbaar op het ‘taskboard’ en bepalen de teamleden zelf welke taken op een bepaald moment uitgevoerd worden en wie dit doet.
Ruimte voor zelforganiserend vermogen bij Scrum
Een belangrijke succesfactor van Scrum is het gebruik van het zelforganiserend vermogen van professionals:
- Het ontwikkelteam is zelf verantwoordelijk voor het resultaat en daarom voor de planning, de werkverdeling en de voortgangsbewaking;
- Het opdelen van het werk in kleine ‘work items’ van 2-4 uur geeft de ontwikkelaars zelf de mogelijkheid om de voortgang te bewaken (en geeft enkele keren per dag voldoening over bereikte resultaten!);
- Het team heeft geen hiërarchische projectleider (want dan voelen de teamleden zichzelf minder verantwoordelijk voor de voortgang), maar heeft wel een katalysator in de persoon van de ‘scrum master’;
- Feedback krijgen is essentieel om een goed product te maken, hoe eerder hoe beter, daarom is er veel en intensief contact tussen klant (product-owner) en ontwikkelaars;
- De rolverdeling tussen product-owner, die het ‘wat’ bepaalt, en de ontwikkelaars, die het ‘hoe’ bepalen, is duidelijk en hierdoor blijft iedereen in zijn kracht;
- De dagelijkse werkverdeling wordt door de teamleden zelf bepaald op basis van prioriteiten en competenties;
- Iedere sprint wordt afgesloten met een evaluatie en vastlegging van leerpunten (‘retrospective’) zodat het team de volgende sprint nog beter kan uitvoeren.
Scrum: innovatieve organisatie van projectmatig werken
Scrum is dus een innovatieve manier om software projecten tot een goed einde te brengen. Maar Scrum is ook breder inzetbaar. Onlangs sprak ik een marketingmanager die Scrum ook gebruikte voor het versnellen van de productontwikkeling en voor het realiseren van campagnes. Scrum is dus niet alleen geschikt voor software ontwikkeling, maar voor alle creatieve processen.
Volgens Ad Rabenort vraagt Scrum wel een belangrijke wijziging in de houding van de opdrachtgever. Nu ziet de opdrachtgever de verhouding met de softwareontwikkelaar vaak als een verticale opdrachtgever-opdrachtnemer relatie. Met Scrum wordt echter horizontaal samengewerkt en wordt de opdrachtgever medeverantwoordelijk voor het eindresultaat (en terecht!). Softwareontwikkeling wordt zo een proces van co-creatie.
De afgelopen jaren heeft Covalent in de praktijk bewezen dat met Scrum complexe projecten succesvol gerealiseerd kunnen worden met resultaten die opdrachtgevers en ontwikkelaars tevreden stellen.
Een vlot geschreven introductie tot Scrum kunt u lezen in het boekje ‘De kracht van Scrum’ van Rini van Solingen en Eelco Rustenburg.
Waar vind ik toepasbare kennis en gedeelde ervaringen?
Probeer het Pro-abonnement een maand gratis
En krijg toegang tot de kennisbank. 110 onderwerpen, kritisch, wars van hypes, interactief en geselecteerd op wat wél werkt.
Word een PRO
Je hebt gelijk dat elke organisatie anders is en dus een specifieke implementatie van Scrum nodig heeft. Net daarom is Scrum bewust als framework en niet als alles-voorschrijvende-methodologie gepositioneerd.
Het Scrum framework theoretisch begrijpen is makkelijk, het op een goeie manier in je organisatie inbedden is heel moeilijk. Uit onze praktijk (wij begeleiden zulke Scrum implementaties) blijkt dat de beste aanpak is om Scrum 'by the book' the implementeren, en geen 'cherry picking' te doen en maar enkele van de Scrum ideeën te implementeren. En dan van daaruit (inspect and adapt) de implementatie verder te verfijnen.
Leuk dat jij als HR professional interesse hebt, want ook jullie voelen vaak de impact van Scrum implementaties. Zo zullen andere skills nodig zijn in een organisatie, en gaan beloningen meer team-gericht dan individueel worden.
Groeten, Jef
Certified Scrum Coach at iLean.be
Esther: Ik denk dat Scrum een brug kan slaan tussen HR en IT: Empowered medewerkers, vaardige professionals, in combinatie met een eenvoudig maar krachtig framework om samen te werken geeft resultaat. Voor het bedrijf, en voor de medewerkers!
Hartelijke groet, Sabina
#scrum4overheid.nl
wordpress: agileperformance
#scrum4business
Streng in de methode blijven, tja, dat is in het begin waarschijnlijk het makkelijkst om de nieuwe werkwijze aan te leren. En hoe ga je als hard core scrummaster dan om met de rest van de organisatie? Is de business/opdrachtgever ook agile? Is bv de rol van de Product Owner volledig 'operationeel' en volgens het boekje? Oftewel gedelegeerd en bevoegd opdrachtgever? Ben benieuwd naar je ervaringen!