Scrum [1] is een aanpak voor het ontwikkelen van software. Ze wordt ook steeds meer gebruikt voor andere vormen van organisatieontwikkeling. Een voorbeeld daarvan is het implementeren van ICT-systemen. Welke voordelen heeft het gebruik Scrum bij implementeren? Is het één op één bruikbaar? En wat zijn de randvoorwaarden eigenlijk? Je leest het in dit artikel.
Projectmanagement is een goede methode voor het plannen en monitoren van ICT-implementaties, schreef ik in mijn vorige blogpost. Maar het focust zich vooral op de technische aspecten van het project – op de tastbare, waar te nemen en te toetsen eindproducten.
Een groot deel van de veranderingen die een nieuw systeem met zich mee brengt, bestaat echter uit de adaptatie door de organisatie – de mensen dus. Dat proces gaat over het zien van een noodzaak van veranderen en het willen en kunnen benutten van het nieuwe systeem. Dat is organisatieleren. Dat is een natuurlijk proces van aanpassen.
Scrummen dan maar?
Dit dilemma wordt vaker gezien en ICT-afdelingen en leveranciers zoeken steeds naar nieuwe aanpakken om de beperkingen van projectmanagement te compenseren.
Een medicijn dat ik inmiddels een paar keer ben tegengekomen is Scrum. Door die aanpak toe te passen zou het geïmplementeerde systeem beter bij de wensen aansluiten en daardoor beter geaccepteerd worden. En omdat de implementatie in korte fasen wordt opgedeeld zou ook het project beter te beheersen zijn.
Scrum? Wat is dat?
Scrum is aanpak om software te ontwikkelen. Kern ervan is dat een klein, multidisciplinair team in een korte periode (een ‘sprint’ van 2 – 4 weken) een werkende versie van een systeem oplevert.
In de praktijk betekent het dat een systeem – vaak terwijl het al in gebruik is – stukje bij beetje wordt opgebouwd en elke volgende versie een stukje beter is dan de vorige.
Je kent het principe van de apps op je smartphone. Je krijgt elke twee weken een update. Die biedt telkens iets meer dan de vorige versie en ziet er iets anders uit. De versie van een jaar geleden zou je niet meer terugkennen, maar omdat je in stapjes bent meegenomen kun je met de huidige versie prima uit de voeten.
Om dat proces te beheersen kent Scrum een aantal praktische hulpmiddelen en principes:
- Er is altijd een actueel overzicht van geprioriteerde openstaande gebruikerswensen;
- Elke sprint realiseert de haalbare verzameling hoogst geprioriteerde gebruikerswensen;
- Wensen worden uitgewerkt als ‘user stories’ die een gewenste gebruikerservaring beschrijven;
- Korte vergaderingen. Dagelijks over het onderhanden werk en aan het begin en eind van elke sprint iets langer om de sprint te plannen en te evalueren.
Tot nu toe klinkt het goed bruikbaar voor ICT-implementaties, niet waar? Maar om dit goed te laten werken moet je nog wel aan wat randvoorwaarden voldoen. Grofweg vallen die in twee groepen uiteen.
Scherpe afbakening. Scrum werkt het beste bij absolute grenzen tussen (deel) systemen. Ik noemde al het ontwikkelen van apps. Scrum werkt daar zo goed voor, omdat dit betrekkelijke kleine, op zichzelf staande programma’s zijn.
Is Scrum ook bruikbaar voor het ontwikkelen van business systemen? Ja, mits de systeemarchitectuur toestaat objecten toe te voegen en te wijzigen terwijl het geheel blijft werken. Bij nieuwe systemen wordt hiermee vaak rekening gehouden. Bij oude ‘legacy’ systemen ligt dat een stuk moeilijker.
Business systemen zijn vaak gekoppeld met andere applicaties. Zodra je als Scrumteam met koppelingen aan de slag gaat zul je toch met andere teams moeten afstemmen. Dat maakt de organisatie van het ontwikkelproces als snel complexer en de oplevering van het ene team afhankelijk van die van het andere.
Organisatiecultuur. De tweede groep randvoorwaarden hebben te maken met de organisatie. Scrum werkt alleen echt goed als het team 100% beschikbaar is voor het project. Het team is zelfsturend – dat is voor veel mensen een heel andere manier van werken dan ze gewend zijn.
De klant (gebruiker) centraal stellen vereist bovendien een actieve rol van een business manager als ‘producteigenaar’. In deze rol neem je volledige verantwoordelijkheid voor de prioritering van de wensen en de uitrol van het eindresultaat.
Hoe dit in de praktijk uitpakt is goed zichtbaar in het filmpje over Causeway [2]. Dit softwarebedrijf koos er bewust voor zich op te spitsen naar kleine teams waarin meer werd samengewerkt. Teams hebben een sterke focus op het volgende product en een ‘gebalanceerde vrijheid’ [3] om dat effectief op te leveren.
Dat vereist wel dat in het denken van alle medewerkers de klant centraal staat. Ze leven zich telkens weer in in ‘de pijn en de passie’ van klanten. Wat zo vooral duidelijk wordt, is dat scrum geen instrumentele aanpak is die je snel of in één project implementeert. Het is een bedrijfsfilosofie, waarvoor alle betrokkenen zich moeten inzetten.
Implementatiescrummen
Wat betekent dat voor de bruikbaarheid van Scrum in ICT-implementaties? In de eerste plaats dat Scrum heel goed bruikbaar is als je een ICT-systeem in kleine stappen fasegewijs kunt invoeren.
In de praktijk vind je deze situatie vooral als een systeem al ingevoerd is. Het wordt dan doorontwikkeld – omdat de leverancier met nieuwe versies komt, je stapsgewijs nieuwe functionaliteit in gebruik neemt en het bestaande gebruik wilt optimaliseren. Juist dat kan heel goed met scrum.
Of dat lukt hangt ook af van de leverancier van de software. Als die in een hoge frequentie nieuwe versies uitlevert – bijv. omdat ze ook met scrum ontwikkelt – kun je daar in het implementaties van updates heel goed op aansluiten.
Zo’n aanpak vereist ook in implementatiesprints een team van vrijgemaakte professionals, een betrokken opdrachtgever en gebruikers die hun wensen duidelijk verwoorden en begrijpen dat niet alle dezelfde prioriteit kan hebben.
De praktijk? Die is wel anders.
In de praktijk hebben ICT-implementaties een aantal kenmerken die moeilijk met Scrum samengaan. Zo vraagt een eerste implementatie van basisfunctionaliteit vaak een big bang scenario. Je kunt een basisadministratie niet in het oude en het nieuwe systeem tegelijk voeren en in stapjes overgaan.
Vaak kun je een implementatie trouwens best in fasen verdelen. Maar elke fase heeft dan wel een duidelijke, vooraf aangegeven scope. Je kunt dat dus niet met een product backlog besturen.
Gebruik je voor zo’n geval Scrum zoals ze bedoeld is, dan kun je vooraf de implementatiedatum niet overeenkomen, tenzij je gaandeweg ongelimiteerd mensen kunt bijschakelen. Beide kom ik in de praktijk niet tegen.
Scrum – nuttige hulpmiddelen voor elk project
Scrum zuiver toepassen kun je dus vooral tijdens het uitrollen van updates van software en bij het optimaliseren van het gebruik. Niettemin kun je een paar kenmerken van Scrum goed gebruiken in elk ICT-implementatieproject:
- Start elke dag met een kort gezamenlijk overleg. Alle teamleden bereiden dit voor. Het verloop van het project wordt uitgewisseld aan de hand van de vragen: wat heb je gedaan, wat ga je doen en waar loop je tegenop. Een dagstart geeft iedereen overzicht en houdt mensen betrokken.
- Werk full-time aan beperkte, goed afgebakende werkpakketten. Dat leidt tot focus en een enorme productiviteitswinst.
- Evalueer na elk afgerond werkpakket. Wees ambitieus en positief kritisch en pak verbeterpunten daadwerkelijk op.
- Stel een producteigenaar aan. Ben je producteigenaar, neem volledige verantwoordelijkheid voor de opdracht, de prioriteiten en het eindresultaat.
- Zie jezelf als multidisciplinair en zelfsturend team. Neem als professional volledige verantwoordelijkheid voor de producten waar je aan werkt. Sta voor het teamresultaat. Help collega’s waar je kunt.
Scrum is een aanpak voor het ontwikkelen van software. Maar het heeft kenmerken die goed kunnen helpen bij het implementeren van ICT-systemen.
Scrum geeft de beste resultaten als je incrementeel kunt implementeren. Dat kan vooral als de leverancier kortcyclisch nieuwe versies uitlevert. Het is ook bruikbaar voor het gefaseerd in gebruik nemen van nieuwe functionaliteit en het optimaliseren van het gebruik van systemen.
Daarvoor moet je wel wat doen. Dedicated teams samenstellen, investeren in focus en samenwerking. Verantwoordelijkheid nemen voor je taak, het teamresultaat en het eindproduct. En als professional investeren in de vaardigheden die nodig zijn om je thuis te voelen in zo’n team en waarde toe te voegen aan het eindproduct.
Elke gebruiker van een nieuw systeem of nieuwe versie heeft een natuurlijk adaptatieproces door te maken. Scrum kan dat proces niet overnemen. Maar het kan wel de brug tussen gebruikers en implementatieteam zo verkleinen, dat het systeem hem optimale waarde biedt. En dat is al heel wat gewonnen.
Noten:
[1] – Zoek je meer informatie over Scrum? Een goede uitleg van de kernelementen vind je op Wikipedia. Meer informatie en trainingen vind je onder meer op de website van Prowareness. De trend Scrum ook buiten softwareontwikkeling in te zetten – zelfs buiten het ICT-domein – is te zien aan de training Scrum framework non-IT. Het lijkt me een goede investering voor alle professionals die hun werk slimmer willen organiseren. En pragmatisch en realistisch staan tegenover veelbelovende nieuwe managementconcepten.
[2] – Het filmpje over Causeway is gewoon te zien op Youtube. Het staat ook op de website van Prowarenes, waar ik het de eerste keer zag.
[3] Men gaat in het filmpje niet verder op dit begrip in, maar gekoppeld aan ‘zelfsturing’ kun je je daar van alles bij voorstellen. Om focus te houden en tot een gemeenschappelijk doel te komen is het nodig om kaders aan te geven, regels af te spreken, rituelen te ontwikkelen.
[Nick Grooff is een scherpzinnig verandermanager, coach en blogger over verandermanagement en innoveren. Hij helpt bedrijven en instellingen hun strategie, structuren, ICT en mensen in samenhang te ontwikkelen en zo hun maatschappelijke waarde te vergroten.]
Nick, interessant en leuk artikel! Ik voeg er graag een paar persoonlijke ervaringen aan toe. In mijn beleving is er een essentieel verschil in gebruikersbeleving tussen een traditionele aanpak en scrum: een andere invulling van ‘rek’ in de thema’s tijd, geld, functionaliteit en kwaliteit. Traditioneel zet je de eerste drie vast en ontstaat (meestal ongewenst) de rek in de kwaliteit. Scrum zoekt de rek in functionaliteit. En dat is wennen voor organisaties. Zeker als je traditioneel met een plan van eisen stuurt op een vaste set functionaliteit. Hier hoort vaak een ‘leap of faith’ bij, maar ook discussie. Een interessante vraag: “heb je helemaal aan de voorkant van het project al je beste ideeën gehad, tijdens het opstellen van het PvE, of vertrouw je erop tijdens het project bétere ideeën te krijgen?”. Anders dan wet- en regelgeving bevatten de meeste klantspecificaties veel meer rek dan ze doen vermoeden. Dat is al helemaal van toepassing bij vernieuwing/innovatie. Dan wil je ‘terra incognita’ verkennen en dat is bij uitstek Scrumterrein.
De rol van Product Owner is inderdaad een essentiële. Ik denk dat in die rol het meeste wordt gevraagd van het samenbrengen van twee werelden: Business en IT. Een goede Product Owner moet vooral bewust keuzen kunnen maken en een werkelijke voorstelling hebben van wat die keuzen inhouden. Bovendien moet de Product Owner zowel naar de achterban in de organisatie een stevige rol spelen, als een goede invulling geven richting het scrum team.
Ik wil ook benadrukken hoe belangrijk een ‘definition of done’ is. Het idee achter scrum is inderdaad werkende software op te leveren, maar dan moet je ook heel scherp sturen op kwaliteit. Dat is immers een vrijheid die je níet opgeeft in een scrumtraject. Je rek zit immers in functionaliteit. Door heel scherp te sturen op die kwaliteit, wordt ook al snel duidelijk of je geen stappen overslaat in je sprint. Of onvoldoende uitvoert. Als je in een volgende sprint nog herstelwerk moet uitvoeren van een vorige sprint, is dat een teken aan de wand. Hoe eerder je hier tegenaan loopt (en op stuurt!), hoe beter de voorspellende waarde van je ontwikkelsnelheid (‘velocity’) wordt. En dat is nu net iets waar scrumsceptici tegenaan lopen: met scrum kun je niet plannen.
In software-ontwikkeltrajecten helpt scrum je – mits goed uitgevoerd en aan de randvoorwaarden voldaan – sneller en met minder fouten te ontwikkelen. Veelal zie je echter spectaculaire verbeteringen door de inzet van zogenaamde extreme programming technieken. Ik noem onder andere ‘test driven development’ (eerst testscrips maken, dan pas software die daaraan moet voldoen), ‘pair programming’ (zet twee programmeurs achter één computer) en ‘refactoring’ (gericht verbeteren/vereenvoudigen van al geschreven software). Deze combinatie – scrum + XP – is volgens mij de werkelijke ‘game changer’.
Terwijl ik schrijf en nalees zie ik hoeveel Engelse termen ik nodig had. Mea maxima culpa.
Mooie toevoegingen Edward over de rek in functionaliteit, de rol van de product owner en de ‘ definition of done’. Dank je wel.
Wat jij refactoring noemt doet me sterk denken aan het continu iteratief verbeteren van pakketinrichtingen. Als je dat als organisatie stelselmatig doet maak je steeds optimaal gebruik van je ICT-investeringen.
Zou er ook zoiets als ‘extreme implementation’ kunnen bestaan?
Goed stuk, Nick. Ik mis alleen één heel belangrijke randvoorwaarde. Een team moet niet alleen volledig beschikbaar zijn voor het project en hierin verantwoordelijkheid dragen, maar moet het ook krijgen. Een product owner moet het mandaat hebben om zelfstandig beslissingen (ook belangrijke!) te kunnen nemen en niet voor iedere beslissing goedkeuring aan een MT of directie moet vragen. Goedkeuring vragen vertraagt niet alleen, maar haalt ook de energie uit een project. Meer nog dan van het team, vraagt dit dus in veel gevallen een andere manier van werken van het management.
Zeker, Ineke, helemaal eens. Een heel terechte toevoeging!