Wendbaar projectmanagement Wat opdrachtgevers en software‐ leveranciers van wendbare project‐ methoden moeten weten om projecten opmerkelijk succesvoller uit te voeren. Drs. Edward Dalmulder Projectmissers zijn talrijk. Iedereen kent wel voorbeelden van uitgelopen planningen, overschreden budgetten en bedenkelijke resultaten. De natuurlijke reflex van zowel opdrachtgevers als softwareleveranciers is het verder aanhalen van de teugels. Waaraan u dat merkt? Onder andere aan meer specificaties, meer controlestappen en meer contractclausules. Meer grip – zo is de stellige overtuiging – moet immers tot betere projecten leiden. Maar is dat eigenlijk wel zo? Meer grip leidt in ieder geval tot meer ballast en samenwerking op basis van wantrouwen in plaats van vertrouwen. Bovendien staat grip veelal haaks op wendbaarheid: het vermogen om zeer flexibel op wijzigende omstandigheden in te springen. Ook als die wijzigingen tot een beter projectresultaat leiden. In deze white paper komt een nieuwe aanpak aan bod ‐ gebaseerd op wendbaarheid en Edward Dalmulder (1967) studeerde Informatica aan de Rijksuniversiteit Leiden en is partner bij Social Lime B.V. Hij heeft 25 jaar ervaring met softwareontwikkeling. In allerlei branches, waaronder corporaties, werkte hij zowel namens klanten als leveranciers aan IT‐ projecten. Dat deed hij in tal van rollen: van programmeur en tester tot projectmanager en kwaliteits‐ zorgmanager.
samenwerking – die zonder ballast tot (soms spectaculaire) verbeteringen leidt.
Waar de projectschoen wringt Projecten lijken per definitie eenmalige activiteiten. Ze kennen een kop en staart en leveren een uniek resultaat op; ieder project is anders. Steeds weer veranderen één of meer belangrijke parameters: specificaties, beschikbare middelen, budget, beschikbare tijd et cetera. Dat biedt veel minder
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 1
mogelijkheden om grip op het eindresultaat te krijgen dan in bijvoorbeeld een gestandaardiseerd productieproces. Wie herkent immers niet de volgende symptomen?
De opgeleverde software biedt niet de toegevoegde waarde die men vooraf verwachtte of lopen inmiddels achter op de realiteit.
De verkeerde functionaliteit is gebouwd, of de functionaliteit is verkeerd gebouwd.
Planning en budget worden overschreden. Vaak wordt dit pas op een zeer laat moment in het project zichtbaar.
De software is lastiger te onderhouden dan gedacht.
Spanningen in de relatie tussen klant en leverancier en tussen teamleden.
Ongemotiveerde teamleden die hun inspanningen niet gewaardeerd zien en die ontplooiingsmogelijkheden missen.
De lijst gaat eindeloos door. Logisch dat opdrachtgever en leveranciers op zoek zijn naar manieren om dat te voorkomen. Maar vrijwel automatisch komen ze in de greep van grip: bij ieder volgend project worden de teugels nog strakker aangehaald en uitgeroepen dat het nu niet mis kan gaan. Het resultaat? Meer specificeren en met meer detail, vroegtijdiger specificeren, nóg strakker sturen op geld en tijd. De Interessant: op zoek naar meer grip introduceert men vooral meer ballast en wantrouwen.
projectballast
neemt
alleen
maar
toe,
evenals
de
verwachtingen. Maar juist die ballast vreet tijd, geld en energie. Erger nog: het vreet vertrouwen. Nog een paar opvallende bevindingen uit de zoektocht naar verbetering:
In de regel streeft men naar optimalisatie binnen het bestaande proces. Het proces an sich wordt zelden ter discussie
gesteld,
waarvoor
veel
opmerkelijke
verbeteringen buiten beeld blijven.
Projectmensen denken graag dat de toekomst maakbaar, voorspelbaar en controleerbaar is. Meer grip zorgt voor meer succes. Naast projectballast zorgt dit echter ook
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 2
voor een projectmanagementstijl die lang niet altijd het beste uit de medewerkers haalt. Meer controle staat haaks op meer vertrouwen; ontplooiing wordt ingedamd in plaats van aangemoedigd. Wie voelt zich geroepen onder dat soort omstandigheden het beste uit zichtzelf en het team te halen?
Zowel aan de kant van de afnemer als de leverancier zoekt men naar afbakening om risico’s uit te sluiten. Waar dat toe leidt? Steeds dikkere contracten, hogere boeteclausules, stringentere afspraken, uitgebreidere SLA’s
enzovoort.
Dit
soort
samenwerking
is
overduidelijk gebaseerd op wantrouwen in plaats van vertrouwen. Zijn alle symptomen gegarandeerd uit te bannen? Nee – zo werkt de wereld niet. Kan het beter? Gegarandeerd.
Een andere kijk op projecten Een andere manier van projectsturing begint met een heroverweging van de vorm en rol van ‘grip’. De wereld is niet volledig maakbaar en wij zijn dus gebaat bij een begrip van ‘grip’ dat daarop aansluit. Continue wijzigingen vragen om flexibiliteit of wendbaarheid: weten wat er verandert en het De wereld is niet voor 100% maakbaar. Waarom profiteren we niet van de mogelijke verbeteringen die veranderingen ons brengen in plaats van ze als ongewenste uitzonderingen te zien?
proces bijsturen waar nodig. Wendbaarheid die hand in hand gaat met een passend evenwicht tussen centrale aansturing en decentrale verantwoordelijkheid. Kortom, een vorm van sturing die balans brengt tussen het vermogen om met veranderingen om te gaan en de wens naar een maakbaar proces. Een andere kijk op projecten: van statisch naar dynamisch, van ballast naar wendbaarheid, van wantrouwen naar leren en groeien. Het kon natuurlijk niet uitblijven: op steeds meer plaatsen realiseert men zich de tekortkomingen van traditionele
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 3
proojectmethodeen en is men m op zoeek naar verbeteringen.. Hoeewel de so oftwarebrancche vooruittstrevend heet te zijn,, kom men de gew wenste verbeteringen in eerste insta antie uit een n and dere hoek. Uit U de hoek van v Toyota bbijvoorbeeld d – dat Lean n den nken introdu uceerde – en n de hoek vaan Motorola a en Generall Eleectric, waar Six S Sigma fu urore maaktee. Dit wendb bare denken n ngers in autoomatiseringssland en datt en doen kreeg ook aanhan dde de afg gelopen jare en tot zeerr interessan nte nieuwee leid aan npakken die veelal worden samengevvat met term men als Lean n en A Agile. der de loep p Latten we eenss twee interressante meethoden ond nem men: Scrum en Extreme e Programm ming (XP).
Meeer over Scrum...
Fiiguur 1 ‐ Scrum m
Typ pisch voor Sccrum zijn de volgende eleementen:
De Prod duct Owner r (de klantrrol) is veran ntwoordelijk k voor hett vastleggen van alle eiisen en wen nsen in een n
© 2011 Sociaal Lime B.V.
Wendbaar prrojectmanagem ment – versie 2
Pag. 4 4
Product Backlog. Dit overzicht staat altijd op volgorde van prioriteit. Scrum kent drie rollen (Product Owner, Scrum Master en Scrum Team Member). Er zijn drie ‘artefacten’ (Product Backlog, Sprint Backlog en Burndown Chart). En er zijn vier belangrijke meetings (Sprint Planning, Daily Scrum, Sprint Demo en Sprint Review).
Per time box (dit heet in Scrum een sprint) worden de bovenste features van het Product Backlog geselecteerd om gemaakt, getest en opgeleverd te worden. Dit gebeurt tijdens de Sprint Planning Meeting. De geselecteerde features heten samen de Sprint Backlog.
Het werk wordt uitgevoerd door een multidisciplinair Scrum Team onder aanvoering van een Scrum Master.
Een sprint duurt gemiddeld twee tot vier weken.
Plannen gebeurt in de regel niet in uren of dagen, maar in zogenaamde punten. Op basis van ervaring kun je meten hoeveel punten een team gemiddeld per sprint kan afronden. Dit wordt aangeduid met velocity.
Een Burndown Chart is een grafiek van het resterende aantal punten in een sprint en geeft dagelijks inzicht in de voortgang.
De Daily Scrum Meeting is een dagelijks terugkerend ritueel van circa 15 minuten waaraan iedereen deelneemt en drie vragen beantwoordt: (1) wat heb ik gisteren gedaan, (2) wat ga ik vandaag doen en (3) welke belemmeringen ervaar ik.
Iedere sprint eindigt met een Sprint Demo van de afgeronde features (die daadwerkelijk klaar moeten zijn) en met een Sprint Review om de verbeterpunten voor het vervolg te identificeren.
...en over Extreme Programming In tegenstelling tot Scrum richt XP zich expliciet op program‐ meren. Het is opgebouwd rondom een aantal gebruiken, waaronder Paarsgewijs programmeren, Herschrijven en Test‐ gedreven ontwikkelen. Figuur 2 bevat een overzicht.
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 5
Figuur 2 2 ‐ XP Practicess
n paar intereessante gebru uiken: Een
Paarsgew wijs progra ammeren i s het gebru uik om mett twee perrsonen achte er één compputer te zitte en en samen n te progrrammeren. Vergelijk V heet met de rol r van een n chauffeur en een bijrijder. Dit leevert in de praktijk p een n – bijzonder efficiënte manier vann kennisdeling op en – zeker zo belangrijk – veel minderr fouten.
Bij Testtgedreven ontwikkele o en is het uitgangspunt u t eenvoudig: zorg dat je eerst je ttestscripts scchrijft en gaa daarna programmer p en. Schrijf uuitsluitend die d code diee nodig is om succesvo ol door de teest te komen n. Zo zorg jee voor kwaalitatief hoog gwaardige teests en softw ware.
Herschrijven is het proces van het continu u verbeteren n van softtware. In het bijzonderr het verw wijderen van n ‘dubbele’ code en daa arnaast het vverhogen van de cohesiee c en hett verlagen vvan de afha ankelijkheid.. van de code Softwaree is dus gee en product w waar je na het projectt vanaf mo oet blijven, m maar een prooductiemidd del dat je nett als and dere produ uctiemiddele n voortdurend moett verbeteren.
© 2011 Sociaal Lime B.V.
Wendbaar prrojectmanagem ment – versie 2
Pag. 6 6
De klant schrijft specificaties in de vorm van User Stories. Technische taal is verboden; het draait om de taal en situatie bij de klant.
Nog een interessant gegeven uit de hoek van XP zijn de User Stories. Dit is de methode die wordt gebruikt om klantwensen – en dus de specificaties – te documenteren. User Stories hebben een zeer kort formaat, meestal als volgt: “Als een
wil ik < doel> omdat ”. Een voorbeeld: “Als een geregistreerde gebruiker wil ik mijn password kunnen wijzigen om het veiliger te maken of eenvoudiger te onthouden.” De belangrijkste spelregels die bij User Stories horen: de klant stelt ze op en kent een prioriteit toe. In Scrumtermen: de Product Owner is verantwoordelijk voor de inhoud en volgorde van de Product Backlog. Tot slot nog een ander interessant gegeven. Het is gebruikelijk dat de klant per User Story vooraf de gebruikerstesten (ook wel acceptatietesten genoemd) specificeert. De klant documenteert daarmee niet alleen de gewenste functionaliteit, maar ook hoe hij toetst of de software daaraan voldoet. Dat is uiterst waardevolle informatie voor het ontwikkelteam en voorkomt veel discussie na afloop.
Concrete verbeteringen Methoden als Scrum en XP putten kracht uit verschillende pragmatische principes. Denk aan: 1. Werken op basis van altijd actuele verwachtingen en feitelijke informatie. 2. Resultaatgericht en flexibel werken. 3. Nauwe samenwerking met voortdurende kennis‐ overdracht. 4. Voortdurende feedback; korte terugkoppellussen. 5. Grote mate van zelfstandigheid en een open houding.
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 7
De winst van wendbare projectmethoden ligt verder op allerlei terreinen. Zonder uitputtend te zijn, volgt hierna een thematisch overzicht om de gedachten te bepalen. Communicatie Methoden als Scrum en XP gaan uit van multidisciplinaire teams die intensief met elkaar samen‐ werken. Doordat de klant hier een belangrijke rol bij speelt (denk maar aan de rol van Product Owner bij Scrum), ontstaat ook intensieve communicatie tussen de klant en de leverancier. Sterker nog: die wordt van cruciaal belang geacht. Toegevoegde waarde Tijdens een Sprint wordt die functionaliteit ontwikkeld die door de Product Owner als meest belangrijk is aangemerkt. Dat gebeurt iedere Sprint opnieuw; tussentijdse wijzigingen van prioriteiten zijn geen probleem. Je hebt daardoor de zekerheid dat optimaal op toegevoegde waarde wordt gestuurd. En User Stories die helemaal onderaan staan op de Product Backlog? Loop je zo niet het risico dat die helemaal buiten de Gebruikmaken van Sprints betekent dat je iedere keer weer kiest voor het ontwikkelen van de wensen met de hoogste prioriteit.
boot vallen? Ja. En dat is maar goed ook. Het gaat blijkbaar om functionaliteit met een zeer lage prioriteit, anders stonden ze niet zo laag op de lijst. Waarom zou je een project eindeloos door laten doorlopen voor het implementeren ervan? Planning Het planningsproces begint in Scrum na het opstellen van de Product Backlog. Per item of User Story geeft het Scrum Team als geheel een initiële planning. Hierover bestaat dus consensus bij alle teamleden, in plaats van bij één specialist. Vervolgens gaat de eerste Sprint van start, waarin op basis van een educated guess (of ervaring uit het verleden) een schatting wordt gemaakt van hoeveel werk men gedurende die sprint aankan. Binnen enkele iteraties weet men met vrij grote nauwkeurigheid wat de velocity van het team is en dus wanneer alle functionaliteit is ontwikkeld.
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 8
Dit maakt ook een andere insteek mogelijk: sturen op toevoegde waarde. Als je weet dat voor de laatste 35 punten nog 2 Sprints nodig zijn, kun je je afvragen of je dat ervoor over hebt. Het gaat immers om functionaliteit met de laagste toegevoegde waarde. Je kunt ook besluiten het project al te stoppen vanuit de zekerheid dat je tijdens de eerste sprints al de functionaliteit met de hoogste toegevoegde waarde hebt ontwikkeld. Waarom het project eindeloos door laten lopen? Leren en groeien Een van de grootste winstpunten betreft de aandacht en mechanismen voor groei. Zo kent Scrum de Sprint Review waarin na iedere Sprint wordt gekeken naar de sterke punten van de voorbije Sprint en de te verbeteren punten. Het kortcyclische karakter van Scrum zorgt dus voor zeer frequente leer‐ en groeimomenten. Zo kent XP onder andere het eerder genoemde Paarsgewijs programmeren. Betere
software
Het
volgen
van
wendbare
projectmethoden lijkt in vrijwel alle gevallen tot (veel) betere software te leiden. Zowel in termen van een beperkt aantal fouten als in termen van aansluiten op de klantbehoeften. Zie ook de volgende paragraaf.
Praktische resultaten De hiervoor benoemde verbeteringen klinken natuurlijk goed. Wie zou er niet willen overstappen naar deze methoden? Maar hoe zien de daadwerkelijke verbeteringen er in de praktijk uit? Wat zijn realistische streefcijfers? Er zijn verschillende onderzoeken gedaan, in het bijzonder de volgende uit 2008:
Michael Mah vergeleek 26 wendbare projecten tegen een database met 7.500 voornamelijk traditionele projecten.
David Rico beoordeelde 51 gepubliceerde rapporten op het gebied van wendbare projecten.
VersionOne hield een online onderzoek onder 3.000 mensen.
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 9
Dr. Dobbs Journal (DDJ) hield een online onderzoek onder bijna 650 mensen.
Een greep uit de resultaten:
Wendbare projecten zijn gemiddeld 16% meer productief dan traditionele projecten. [Mah]
23% van de ondervraagden zei dat de productiviteit significant was toegenomen en 50% zei dat de productiviteit was toegenomen. [VersionOne]
De ontwikkelkosten zijn afgenomen (32% van de onder‐ vraagden) of zelfs significant afgenomen (5% van de ondervraagden). [DDJ]
De time‐to‐market is verbeterd (64%) of zelfs significant verbeterd (23%). [VersionOne]
De opgeleverde software bevat tenminste 10% minder fouten (volgens 84% van de ondervraagden) of zelfs tenminste 25% minder (30%). [VersionOne]
De klanttevredenheid is wat hoger (47%) of zelfs veel hoger (31%). [DDJ]
Bijlage 2 bevat de verwijzingen naar relevant achtergrond‐ materiaal.
Veranderingen in gang zetten Zoals voor alle veranderingen geldt, hoeveel ‘moois’ ze ook brengen: veranderen is lastig. Het doet een groot beroep op de mensen die bij het veranderingsproces zijn betrokken. Vaak moet afscheid worden genomen van overtuigingen en jarenlange gebruiken en gewoonten. Veranderen begint daarom met een heldere visie op de toekomst. En een iteratief plan dat al even Lean is als de gewenste verbeteringen! Het volgende eenvoudige stappenplan geeft een aanzet.
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 10
FFiguur 3 ‐ Veran nderingstrajectt
Bewustzijn Creëer bewustzijn biij de betrokk ken mensen n 1. B oveer de tekortk komingen va an de huidigge methoden n en over dee moogelijkheden die methode en als Scrum m en XP bieden. Bijlage 1 1 bevvat een overrzicht van relevante liteeratuur die als vertrek‐‐ pun nt kan dienen. Wil Zet keennis over (h het bestaan vvan) deze m methoden om m 2. W in d de wil om te t verandere en. Doe dit vvanuit een visie v en mett con ncrete verbetteringen voo or ogen. g aan het vermog gen van dee 3. Vermogen Werk gericht nsen om te v veranderen. N Niet alleen ‘emotioneel’,, bettrokken men maaar ook door het ontwikk kelen van kennnis en vaard digheden. 4. D Doen Ga v van start me et een repreesentatief pro oject en doee ervvaring op. Dit D project zal ongetw wijfeld handv vatten voorr verrbetering aan nreiken, maa ar ook een im mpuls opleve eren voor dee (intterne) promotie van de n nieuwe werkkwijze. 5. V Verbeteren Zorg voo or het verbetteren van de e aanpak op p bassis van de geconstateerrde bevindiingen. Een interessante i e aan npak: implem menteer de verbeteringeen op basis van Scrum.. Zorrg
daarnaaast
voor
het
onntwikkelen
van
dee
sprreekwoordellijke olievlek k.
© 2011 Sociaal Lime B.V.
Wendbaar prrojectmanagem ment – versie 2
Pag. 11 1
Het spreekt voor zich: een veranderingstraject verdient meer detail en invulling. Zeker op het gebied van communicatie en de daarvoor in te zetten middelen. Communicatie moet als onderdeel van het stappenplan worden ontwikkeld en daar als integraal onderdeel in meelopen.
Tot slot Verbeteren is een reis. Geen eindbestemming. Ik ben zeer benieuwd of deze white paper u tot een reis heeft weten aan te zetten. Of van invloed is geweest op de koers van uw huidige reis. Ik nodig u uit om eens contact met mij op te nemen om uw ervaringen tegen mij aan te houden. De kans is groot dat we er samen van leren. Ik in ieder geval. Alphen aan den Rijn, 16 januari 2011 Edward Dalmulder [email protected] 06 – 505 24 231
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 12
Literatuurlijst Voor wie meer wil weten over wendbare vormen van project‐ management: 1.
Beck, K. (2003). Test‐Driven Development. Addison Wesley.
2.
Beck, K. (2005). Extreme Programming Explained ‐ Embrace Change. Addison Wesley.
3.
Cohn, M. (2004). User Stories Applied for Agile Software Development. Addison Wesley.
4.
Cohn, M. (2006). Agile Estimating and Planning. Addison Wesley.
5.
Cohn, M. (2010). Succeeding with Agile ‐ Software Development Using Scrum. Addison Wesley.
6.
Kniberg, H. (2007). Scrum and XP from the Trenches. C4Media Inc.
7.
Kniberg, H. a. (2010). Kanban and Scrum ‐ making the most of both. C4Media Inc.
8.
Morgan, J. a.‐J. (2009). Lean Six Sigma for Dummies. John Wiley and Sons.
9.
Poppendieck, M. a. (2007). Implementing Lean Software Development ‐ From Concept to Cash. Addison Wesley.
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 13
Onderzoeksresultaten De volgende bronnen en documenten kunnen dienen als vertrekpunt voor wie meer over de resultaten van wendbare methoden wil weten: 1.
Mann, Chris and Maurer. (2005). Proceedings of the Agile Development Conference, 70‐79. IEEE Computer Society.
2.
Rico, D. (2008). What is the ROI of Agile vs. traditional methods?
3.
VersionOne (2008). The State of Agile Development: Third annual survey.
4.
Cohn, M. (2009). Succeeding with Agile: Software Development using Scrum. Addison‐Wesley.
5.
Mah, M. (2008). How agile projects measure up and what this means to you. Cutter consortium Agile Product & Project Management Executive Report 9.
© 2011 Social Lime B.V.
Wendbaar projectmanagement – versie 2
Pag. 14
