MANAGEN VAN AGILE PROJECTEN Copyright protected. Use is for Single Users only via a VHP Approved License.
Andere uitgaven bij Van Haren Publishing Van Haren Publishing (VHP) is gespecialiseerd in uitgaven over Best Practices, methodes en standaarden op het gebied van de volgende domeinen: - IT en IT-management; - Enterprise-architectuur; - Projectmanagement, en - Businessmanagement. Deze uitgaven zijn beschikbaar in meerdere talen en maken deel uit van toonaangevende series, zoals Best Practice, The Open Group series, Project management en PM series. Op de website van Van Haren Publishing is in de Knowledge Base een groot aanbod te vinden van whitepapers, templates, gratis e-books, docentenmateriaal etc. Ga naar www.vanharen.net. Van Haren Publishing is tevens de uitgever voor toonaangevende instellingen en bedrijven, onder andere: Agile Consortium, ASL BiSL Foundation, CA, Centre Henri Tudor, Gaming Works, IACCM, IAOP, IPMA-NL, ITSqc, NAF, Ngi, PMI-NL, PON, The Open Group, The SOX Institute. Onderwerpen per domein zijn: IT en IT-management ABC of ICT TM ASL CATS CM CMMI COBIT e-cf ISO 17799 ISO 20000 ISO 27001/27002 ISPL IT-CMF TM IT Service CMM ITIL MOF MSF SABSA Architecture (Enterprise en IT) ArchiMate GEA Novius Architectuur Methode TOGAF Business Management BABOK Guide BiSL BRMBOK TM EFQM escm IACCM ISA-95 ISO 9000/9001 Novius B&IP OPBOK SAP SixSigma SOX SqEME Project-, Programmaen Risicomanagement A4-Projectmanagement DSDM/Atern ICB / NCB ISO 21500 MINCE M_o_R MSP TM P3O PMBOK Guide PRINCE2 Voor een compleet overzicht van alle uitgaven, ga naar onze website: www.vanharen.net
Managen van agile projecten 2 e geheel herziene druk Bert Hedeman Henny Portman Ron Seegers
Colofon Titel: Auteurs: Redactie: Reviewers: Tekstredactie: Uitgever: Managen van agile projecten - 2 de geheel herziene druk Bert Hedeman (Hedeman Consulting) Henny Portman (Hedeman Consulting) Ron Seegers (Projectmeester) Hajati Wieferink (Hedeman Consulting) Bob Hotho (Fortes) Diederick van Nieuwburg (Ministerie van Infrastructuur en Milieu) Geert Wissink (Stedelijk Museum Amsterdam) Wijnand Lens (Dolgoz) Wim Leenders (Ruimtelijk Informatie Management) Rinus Vermeulen Van Haren Publishing, Zaltbommel, www.vanharen.net ISBN Hard copy: 978 94 018 0024 2 ISBN ebook: 978 94 018 0576 6 Druk: Eerste druk, eerste oplage, juni 2014 Tweede geheel herziene druk, eerste oplage, december 2015 Lay-out en DTP: CO2 Premedia, Amersfoort NL Copyright: Van Haren Publishing, Hedeman Consulting, 2014, 2015 DSDM and AgilePM are registered trademarks of Dynamic Systems Development Method Limited (DSDM Consortium) in the United Kingdom and other countries. PRINCE2, PRINCE2 Agile, MSP and MoP are registered trademarks of AXELOS Limited. Niets uit deze opgave mag vermenigvuldigd, vastgelegd in een geautomatiseerd bestand of openbaar gemaakt worden op of via enig medium, hetzij elektronisch, mechanisch, door fotokopieën of anderszins, zonder voorafgaande schriftelijke toestemming van de uitgever. Ondanks alle zorg die aan deze uitgave is besteed, kunnen er eventuele fouten in voorkomen. De uitgever en de auteurs aanvaarden geen aansprakelijkheid voor het optreden van fouten en/of onvolkomenheden.
Woord vooraf Agile is een begrip dat zich de laatste jaren heeft ontwikkeld tot een hype. Het begrip komt voort uit de softwareontwikkeling en is in die context in 2001 stevig op de kaart gezet met het Manifesto for Agile Software Development, beter bekend als Agile Manifesto. Anno 2015 heeft agile begrippen als nieuw, next en 2.0 mijlenver ingehaald en heeft het zich lang en breed ontworsteld aan het thema softwareontwikkeling. Agile als begrip is onstuitbaar in opkomst en is blijkbaar - overal toepasbaar: op ambtenaren en de overheid als geheel, op de zorg, op auto s (de Chevrolet Agile, jawel!), op gitaren (google maar eens), uiteraard op verandermanagement en natuurlijk ook op projectmanagement, programmamanagement, portfoliomanagement en PMO s. Laten we eerlijk zijn, het woord agile is vanuit marketing perspectief spot on. Het heeft de positieve lading van beter, sneller, nieuw, makkelijker en efficiënter ineen. Afgelopen jaren heb ik meerdere bijeenkomsten en presentaties bijgewoond met als thema agile projectmanagement. Keer op keer werd ik teleurgesteld: het ging nooit over projectmanagement maar telkens weer over het toepassen van agile in softwareontwikkeling. Ik ben dan ook zeer blij met dit boek. Eindelijk een goede en vooral leesbare uitleg van agile projectmanagement. Ja: echt projectmanagement. Dit boek gaat écht niet over softwareontwikkeling, dit boek gaat over het managen van agile projecten. Over het waarom, het hoe en het wat van het managen van agile projecten, gebaseerd op de methode AgilePM (Agile Project Management). Wat dit boek extra bijzonder maakt is het deel IV, dat inzicht geeft in hoe AgilePM, PRINCE2, Kanban, Lean Six Sigma en Scrum zich tot elkaar verhouden en hoe deze methoden wel of niet zijn te combineren. Lof voor de auteurs voor dit deel! Laat dit deel de vele projectenorganisaties in Nederland inspireren tot een frisse blik op het vakgebied. Ik vind het agile gedachtegoed een verrijking voor het P3M-vakgebied. Ik hoop van harte dat het bijdraagt aan het loslaten van het dogmatische streven naar de standaard manier van werken en aan de omslag naar het gebruiken van de meest geschikte methode voor elk project of programma. Als agile net zo n impact heeft op project-, programma- en portfoliomanagement als het al heeft gehad op softwareontwikkeling, dan staat ons nog heel wat te wachten. Bob Hotho
Woord vooraf van de auteurs Ter gelegenheid van de tweede druk hebben wij dit boek ingrijpend herzien. De eerste druk dateert van ruim een jaar geleden en is gebaseerd op DSDM/Atern versie 2 en het Agile Project Management Handbook Version 1.2 van APMG. Ondertussen heeft APMG een ingrijpende herziening van het AgilePM, Agile Projectmanagement Handbook Version 2 en de bijbehorende examens op de markt gebracht. Deze tweede druk sluit hierop aan. Een tweede reden voor een ingrijpende herziening wordt gevormd door ontwikkelingen in het agile veld. Steeds meer organisaties maken gebruik van continue oplevering, DevOpsteams en Kanban. Daarnaast heeft AXELOS PRINCE2 Agile in de markt gezet. In deze herziene druk lichten we ook deze methoden toe. Wij willen al diegenen die vermeld zijn als reviewer zeer hartelijk danken voor hun onmisbare bijdrage aan de totstandkoming van dit boek. Wij staan nog steeds open voor commentaren en suggesties. Bert Hedeman, Henny Portman, Ron Seegers, november 2015
Inhoudsopgave Deel I: Methodische beschrijving van AgilePM 1 1 Inleiding 3 2 Uitgangspunten Agile 13 3 AgilePM-filosofie en -raamwerk 15 4 AgilePM-principes 17 5 Succesfactoren 23 6 Rollen en verantwoordelijkheden 27 7 Procesmodel 33 8 Producten 43 Deel II: Projectmanagement 49 Inleiding 50 9 Managen van projecten 51 10 Opstellen van eisen 57 11 Maken van schattingen 61 12 Maken van plannen 65 13 Leveren van kwaliteit 69 14 Beheersen en rapporteren 75 15 Managen van risico s 83 16 Testen 87 17 Configuratiemanagement 89 18 Communicatie en samenwerking 93 Deel III: Technieken 99 Inleiding 100 19 Timeboxing 101 20 Gefaciliteerde workshops 107 21 MoSCoW-prioritering 109
VIII 22 Iteratieve aanpak 113 23 Modelleren 117 24 Planning Poker 119 Deel IV: Afstemming 123 Inleiding 124 25 Positionering 125 26 Continue oplevering en DevOps 127 27 PRINCE2 en AgilePM 129 28 PRINCE2 Agile 135 29 Scrum 143 30 Kanban 149 31 Lean Six Sigma 153 32 Combineren van verschillende aanpakken in één project 157 33 Managen van verschillende aanpakken in één portfolio 161 Bijlagen 166 Bijlage A Vragenlijst Projectaanpak 167 Bijlage B AgilePM-rollen en verantwoordelijkheden 173 Bijlage C AgilePM-productspecificatie 179 Bijlage D Begrippenlijst 191 Bijlage E Vertaallijsten 203 Literatuurlijst 215 Index 217
Deel I: Methodische beschrijving van AgilePM Copyright protected. Use is for Single Users only via a VHP Approved License.
1 Inleiding Het projectmatig uitvoeren van taken en doorvoeren van veranderingen in organisaties is de afgelopen jaren gemeengoed geworden. Doorgaans wordt daarbij teruggegrepen op traditionele projectmanagementmethoden. Dat levert echter niet altijd datgene op wat nodig is. Teamleden klagen er vaak over dat ze belemmerd worden door allerlei eisen en voorwaarden waar ze aan moeten voldoen. Gebruikers worden niet bij het proces betrokken en het project biedt geen ruimte om de veranderingen die zich tijdens het project aandienen mee te nemen. Een eerste oplevering van producten vindt vaak pas na maanden plaats, zonder tussentijdse afstemming met de klant en gebruikers. Dat heeft tot gevolg dat de resultaten (te) laat worden opgeleverd en niet aansluiten op de werkelijke behoefte van de klant. Bovendien schiet men ook door in het aantal projecten. Alles wordt een project, ook het reguliere onderhoud van systemen. Dat levert enorm veel extra administratieve rompslomp op. Deze knelpunten hebben geleid tot verschillende nieuwe aanpakken voor het ontwikkelen van maatwerkresultaat die allemaal te classificeren zijn als agile. Agile betekent zoveel als wendbaar. Kenmerkend aan agile is dat het hier eerder gaat om een denkwijze dan om een methode. Dit agile gedachtegoed heeft vervolgens weer geleid tot een aantal afgeleide methoden zoals Scrum en XP. Deze richten zich allemaal op het ontwikkelen van het op te leveren resultaat via zelfsturende teams in korte sprints van enkele weken. Tegelijkertijd zie je daarbij een sterke verschuiving plaatsvinden van werken in projecten naar onderhoud in de reguliere bedrijfsvoering (Business as Usual, afgekort: BAU). Maar voor het doorvoeren van complexe en risicovolle veranderingen blijft het werken in projecten nodig. Het probleem is echter dat die nieuwe methoden geen directe verbinding hebben met de bestaande projectmanagementmethoden. Hoe initieer je initiatieven? Hoe bepaal je de oplossingsrichting? Hoe escaleer je dreigende overschrijdingen en wanneer? Hoe informeer je de overige belanghebbenden buiten de direct projectbetrokkenen? Deze vragen hebben weer geleid tot de behoefte aan een raamwerk dat de agile methoden kan verbinden met het overkoepelende bedrijfs- en programmamanagement. Dat is AgilePM. Agile Project Management (afgekort: AgilePM) is een van de weinige agile methoden 1 die ook het managen van projecten beschrijft binnen een agile aanpak. AgilePM is een specifieke subset van de Agile Project Framework van het DSDM Consortium. Dit boek beschrijft het managen van agile projecten in algemene zin en is bedoeld voor iedereen die betrokken is bij het managen van agile projecten. Met dit boek reiken we dan ook verder dan het beschrijven van AgilePM alleen. Tegelijkertijd blijft dit boek ook geschikt voor lezers die zich willen voorbereiden op de examens AgilePM Foundation en Practitioner. 1 In juni 2015 heeft AXELOS PRINCE2 Agile op de markt gebracht. Zie voor een samenvatting van PRINCE2 Agile hoofdstuk 28.
4 Managen van agile projecten 1.1 Agile Manifesto Het agile gedachtengoed is voor het eerst formeel vastgelegd tijdens een bijeenkomst in 2001 in het Manifesto for Agile Software Development. Dit manifest stelt: - mensen en hun onderlinge interactie boven processen en hulpmiddelen; - werkend resultaat boven allesomvattende documentatie; - samenwerking met de klant boven contractonderhandelingen; - inspelen op verandering boven het volgen van een plan. Daarmee wordt gesteld dat de linker items meer waarde hebben dan de rechter items, maar wordt niet aangegeven dat de rechter items geen waarde zouden hebben. Dit manifest is daarbij gebaseerd op de volgende twaalf principes: - De hoogste prioriteit is het tevredenstellen van de klant. - Verwelkom voortschrijdend inzicht. - Lever regelmatig goed werkende software op. - Zorg voor dagelijkse samenwerking tussen gebruikers en Ontwikkelaars. - Bouw projecten rond gemotiveerde individuen. - De meest effectieve manier om informatie te delen is door met elkaar te praten. - Werkende software is de belangrijkste maat voor voortgang. - Agile processen bevorderen constante ontwikkeling. - Voortdurende aandacht voor hoge kwaliteit en een goed ontwerp zorgen voor flexibiliteit. - Eenvoud, de kunst van het weglaten, is essentieel. - Het beste resultaat komt voort uit zelfsturende teams. - Zorg voor regelmatige evaluatie en verbetering van de processen. 1.2 Wat maakt agile projecten anders? Het managen van agile projecten verschilt wezenlijk van het managen van traditionele projecten, al gebiedt de eerlijkheid te zeggen dat ook in traditionele projecten al veel technieken worden toegepast die kunnen worden geclassificeerd als agile. In principe is de agile aanpak dan ook niets nieuws. Agile is eigenlijk een consistente samenvoeging van al langer bestaande technieken vanuit de behoefte om de wendbaarheid en daarmee de toegevoegde waarde van projecten te vergroten. In de traditionele projectaanpak is de Projectmanager verantwoordelijk voor het opstellen van de plannen, het aansturen van de uitvoering en het rapporteren van de voortgang. Kortom, hij is verantwoordelijk voor het aansturen en beheersen van het project. Voortgang wordt in traditionele projecten vaak gemeten op basis van het percentage gereed van de uit te voeren activiteiten. Mijlpalen richten zich op het opleveren van tussenproducten, bijvoorbeeld een schaalmodel of een stroomschema. Fasen worden meestal standaard ingedeeld naar type werk, bijvoorbeeld analyse, planning, ontwerp, werkvoorbereiding,
Inleiding 5 uitvoering en ingebruikname. Werkzaamheden worden volgtijdelijk uitgevoerd (watervalmethode). Resultaten worden pas aan het eind van het project opgeleverd. Gestuurd wordt meestal op basis van de gedefinieerde scope en kwaliteit, terwijl men probeert tijd en geld te beheersen. Tabel 1.1 Verschillen tussen de watervalmethode en een agile aanpak Watervalmethode Agile aanpak Aansturen en beheersen door Projectmanager Zelfsturende teams Werkzaamheden volgtijdelijk Werkzaamheden iteratief Voortgang op basis % activiteiten gereed Voortgang op basis % gereed product Mijlpalen wanneer werkzaamheden zijn afgerond Timeboxes met beoordeling tussenproducten Fasen met tussenresultaten Increments met op te leveren deelproducten Beheersing op tijd, geld en kwaliteit Beheersing via op te leveren functies Resultaat wordt einde project opgeleverd Resultaat wordt incrementeel opgeleverd Projectmanager dirigerend Projectmanager faciliterend In agile projecten ligt de verantwoordelijkheid duidelijk anders en worden projecten bovendien anders gestructureerd (zie tabel 1.1). Bij agile projecten vormen de zelfsturende teams de basis. Deze zijn volledig verantwoordelijk voor het realiseren van het op te leveren resultaat dat tot stand komt via korte iteraties 2 in vaste timebox es 3. De eisen worden bepaald door de gebruikersvertegenwoordigers in samenspraak met het Ontwikkelteam. De Project manager is alleen verantwoordelijk voor het inrichten van het project, het opstellen en bewaken van het Realisatieplan en de communicatie tussen het Ontwikkelteam en het bedrijfs- en programmamanagement. De rol van de Projectmanager kan hierbij het best worden getypeerd als structureren en faciliteren. In agile projecten wordt verder de voortgang gemeten op basis van gereed product en niet op basis van de gereedheid van de uit te voeren activiteiten. Mijlpalen zijn de data waarop de verschillende deelproducten worden opgeleverd (bijvoorbeeld een nieuwe functionaliteit in een website) en niet wanneer bepaalde activiteiten zijn afgerond. Agile kent geen fasen, maar increments. Soms worden increments wel fasen genoemd, maar in essentie is een increment toch iets anders dan een fase. Een increment is een tijdsperiode met daarbinnen weer één of meer timeboxes, waarin een deelresultaat van het eindresultaat wordt ontwikkeld en opgeleverd. Een increment levert dus een werkend deel op van het eindresultaat. Een fase levert meestal slechts een tussenproduct op (zie figuur 1.1). In agile projecten is altijd sprake van een incrementele oplevering. Verder worden agile projecten niet beheerst op basis van tijd en geld, maar op basis van het aantal op te leveren functies 4 binnen een vooraf gedefinieerde tijd. Het Ontwikkelteam richt zich daarbij geheel op de prioriteiten van de klant en de gebruikers. Wat de hoogste prioriteit heeft, wordt ook als eerste ontwikkeld. Het voordeel daarbij is dat juist daarvan 2 Iteratie: cyclus van vaststellen, plannen, ontwikkelen en reviewen, waarin het gewenste eindresultaat verder wordt ontwikkeld. 3 Timebox: vaste tijdsperiode waarbinnen een doelstelling wordt gerealiseerd. 4 Functie: een specifieke werking waaraan het resultaat moet voldoen.
6 Managen van agile projecten ook meestal de eisen al het duidelijkst zijn te definiëren. Omgekeerd zou je misschien zelfs kunnen zeggen: als we nog niet weten waar iets aan moet voldoen, dan zal de urgentie in werkelijkheid wel niet zo hoog zijn als wordt beweerd. Tussenresultaat Ontwerp Tussenresultaat Voorbereiding Tussenresultaat Realisatie Ingebruikname Implementatie Fase Fase Fase Fase Traditionele projectfasering (watervalmethode) Ingebruikname Ingebruikname Ingebruikname Increment Increment Increment Incrementele oplevering Figuur 1.1 Watervalmethode versus incrementele aanpak Een ander uitgangspunt van agile is dat niets in één keer perfect is en dat voor een goed resultaat herhaaldelijk terugkoppelen noodzakelijk is. Verder gaat agile uit van een voortschrijdend inzicht bij zowel de klant, de gebruikers als het Ontwikkelteam. Klanten en gebruikers weten vaak pas wat ze echt willen als ze een eerste resultaat zien. Net als het uitvoerende team zien ook klanten en gebruikers gaandeweg nieuwe, betere oplossingen. Het zou toch zonde zijn hier geen gebruik van te maken. Dit houdt wel in dat eerder opgeleverde resultaten later soms opnieuw aangepast moeten worden. Dat is jammer, maar het staat in geen verhouding tot het blijven doorgaan op de foute weg. Doordat de afzonderlijke iteraties meestal kort zijn, is het aanpassen van eerdere resultaten voor het Ontwikkelteam ook geen groot probleem. Bovendien zien zij dat het nieuwe resultaat extra toegevoegde waarde oplevert voor de klant. Al met al is dit een hele aanpassing. Een veelgehoorde stelling is dat agile alleen geschikt zou zijn voor softwareontwikkelingsprojecten. Dat is niet het geval. Agile kan eenvoudig en zeer effectief worden toegepast in ieder project waarbij een sterke samenwerking met de gebruikers gewenst is. Het voordeel van agile projecten is dat teamleden en gebruikers samenwerken vanaf de start van het project en dat er frequent terugkoppeling plaatsvindt van het Ontwikkelteam naar de klant. Overal waar dat van belang is, levert de agile aanpak voordelen op.
Inleiding 7 Soms wordt gesteld dat agile strijdig is met iedere andere vorm van projectmanagement. Ook dat is niet juist. Een goede projectaanpak kan juist condities scheppen voor het optimaal toepassen van agile. Agile kan dan ook zeker worden gecombineerd met een gestructureerde projectaanpak. 1.3 Waarom agile projecten? Er zijn meerdere redenen om projecten op een agile wijze aan te pakken: (Te) laat opleveren Te laat opleveren van de afgesproken projectresultaten zorgt vaak voor grote frustraties bij de klant en de gebruikers. Het kan zelfs een reden zijn om het project in zijn geheel af te blazen. Agile ondervangt dit probleem door juist het op tijd opleveren van het eindresultaat als uitgangspunt te nemen in de gehele projectaanpak. Een agile project wordt beheerst door het al dan niet opleveren van het aantal functies en niet door het besteden van extra tijd of geld. De ruimte in de functies wordt gevonden door het prioriteren van de functies naar de toegevoegde waarde voor de klant en het opleveren van die functies in de volgorde van die prioriteit. Ongebruikte functies De ervaring leert dat de helft van de opgeleverde functies in traditionele projecten in de praktijk niet of nauwelijks wordt gebruikt (zie figuur 1.2). Dit komt doordat bij het definiëren van de benodigde functies vaak alle theoretisch mogelijke alternatieven worden geïdentificeerd, zonder dat deze goed worden geprioriteerd. In agile projecten worden bij alle beslispunten in het project de functies geprioriteerd. Overbodige functies worden niet meegenomen. Vaak of altijd: 20% Soms 16% Zelden 19% Vaak 13% Nooit 45% Altijd 7% Zelden of nooit: 64% Figuur 1.2 Gebruik van opgeleverde functies in traditionele projecten (bron: Standish Group) De klant wil wat anders Een andere frustratie van klanten en gebruikers is dat het opgeleverde resultaat vaak niet voldoet aan de verwachtingen, wat die dan ook mogen zijn. Het eindresultaat voldoet niet aan de kwaliteitseisen, er ontbreken noodzakelijke functies of het resultaat sluit niet aan op de gewenste bedrijfstoepassingen.
8 Managen van agile projecten In agile projecten staan de klant- en gebruikerseisen centraal. Vanuit dit principe worden diverse technieken aangereikt om optimale afstemming tussen klanten en gebruikers enerzijds en het Ontwikkelteam anderzijds te bewerkstelligen. Dit gebeurt door het faciliteren van workshops, het actief stimuleren van een continue samenwerking tussen gebruikers en Ontwikkelaars en door het telkens tussentijds opleveren van gebruiksklare resultaten. Voortschrijdend inzicht Een belangrijk kenmerk van agile projecten is dat het Ontwikkelteam openstaat voor veranderingen. In traditionele projecten worden veranderingen vaak gezien als een probleem in plaats van als een kans. Dat komt doordat in die projecten de op te leveren functies worden vastgezet en het management stuurt op tijd en geld in plaats van dat zij binnen de gestelde tijd en geld de maximale toegevoegde waarde proberen te leveren. Maximaliseren toegevoegde waarde In agile projecten worden functies nadrukkelijk opgeleverd in volgorde van hun toegevoegde waarde voor de klant. Verbeteringen die meer toegevoegde waarde leveren dan de oorspronkelijk beoogde resultaten worden in die context alleen maar toegejuicht. Door de iteratieve ontwikkeling in korte cycli zijn de perioden van ontwikkeling kort. Hierdoor en door de intensieve samenwerking tussen gebruikers en het Ontwikkelteam zal ook het aantal verrassingen beperkt blijven. Vertraagde ROI Een uitloop van het project kan funest zijn voor de Business Case van het project als geheel. Agile ondervangt dit probleem door incrementeel op te leveren. Niet alles in één keer, maar per increment wordt een werkend deel van het eindresultaat opgeleverd dat vanaf dat moment ook meteen een deel van de beoogde toegevoegde waarde levert. Over-engineering Het Ontwikkelteam heeft vaak de neiging het beste van het beste op te leveren (gold plating). Dat is vaak niet in het belang van de bedrijfsvoering. Goed is goed genoeg! Dit gebeurt meestal als het Ontwikkelteam naar binnen is gericht. In agile projecten is het Ontwikkelteam echter geheel op de klant en de gebruikers gericht. Agile richt zich volledig op het leveren van de maximale toegevoegde waarde aan de bedrijfsorganisatie. Over-engineering wordt voorkomen door frequente afstemming over en prioritering van de eisen per functie en door het incrementeel opleveren van een werkend resultaat. Een agile Projectmanager over het nut van agile werken voor zijn organisatie: Sinds we agile werken als basis hebben gekozen voor al onze projecten, voor zowel de product- als de softwareontwikkeling, kennen we een snellere time-to-market, werken we veel beter samen en voelt iedereen meer trots voor het bedrijf. Het geheim van onze implementatie ligt op twee punten: het hoge management stond vanaf het begin achter de nieuwe werkwijze en bleef erachter staan, ook als het even niet meezat. En we bleven
Inleiding 9 communiceren over het waarom van de werkwijze, de cultuur, en wat het nut was voor iedere collega maar ook voor de organisatie als geheel. Ik vraag me af waar we zouden zijn geëindigd als we niet met agile werken waren begonnen. Ik wil er eigenlijk niet aan denken. 1.4 Redenen om niet agile te werken Natuurlijk worden er ook redenen aangedragen om projecten vooral niet agile uit te voeren en alles bij het oude te laten: Alles moeten opleveren Je zou geen agile aanpak kunnen gebruiken als in een project alle beschreven functies moeten worden opgeleverd. Dat hoeft echter geen probleem te zijn, omdat de ruimte in de functies vaak ligt in de prioritering van de onderliggende eisen en subfuncties en niet in het beperken van de op te leveren functies als geheel. Gedetailleerde specificatie Datzelfde wordt gezegd als er vooraf een gedetailleerde specificatie is opgesteld. Toch kan er dan ook nog agile worden gewerkt. Alleen hoeven dan in de opeenvolgende increments en timebox es de eisen niet verder te worden uitgewerkt. Wel moeten dan bij de start van de opeenvolgende increments en timeboxes de specificaties opnieuw worden gevalideerd. De ervaring leert dat vanwege het voortschrijdend inzicht veel specificaties tijdens de uitvoering alsnog moeten worden aangepast. Bestaande standaarden en best practices Een veelgehoorde opmerking is: agile is een goede aanpak, maar bij ons werkt het niet. Daarbij wordt verwezen aan de noodzaak aan controle en het moeten voldoen aan interne en externe standaarden. AgilePM is een aanpak die echter juist antwoord geeft op dat probleem. Het combineert de agile aanpak van de uitvoering met de beheersing van de projectsturing. Werken met externe leveranciers Ook het werken met externe leveranciers wordt vaak als reden aangevoerd om niet agile te werken. Maar het dichttimmeren van een contract in een zo snel veranderende wereld is meestal geen optie. De praktijk leert dat ook met externe partijen goed agile is samen te werken (zie hoofdstuk 28 PRINCE2 Agile). 1.5 Waarom zijn met een agile aanpak nog projecten nodig? Het tegenovergestelde wordt ook vaak beweerd: Met een agile aanpak hebben we geen projecten meer nodig. Waar dat het onderhoud van bestaande systemen betreft is dat inderdaad vaak waar. Het wordt echter totaal wat anders bij het doorvoeren van complexe en
10 Managen van agile projecten risicovolle veranderingen. Dan kan er veel fout gaan als er niet eerst een algemene oplossingsrichting is vastgesteld. Als niet eerst de zinvolheid van de totale investering is beoordeeld. En als tijdens de uitvoering niet het werk van de verschillende teams wordt gecoördineerd. En als tijdens de uitvoering niet goed wordt gecommuniceerd met alle belanghebbenden bij het project en niet alleen met de directe vertegenwoordiger van de gebruikers. De kernproblemen zijn vaak: Slechte voorbereiding De agile aanpak werkt goed als zowel de probleemstelling en de oplossingsrichting eenduidig zijn bepaald. Als deze niet vanzelfsprekend zijn, dan zullen ze eerst moeten worden onderzocht en vastgesteld, zonder dat men zich verliest in de details. Zonder deze voor bereiding zal men tijdens de uitvoering steeds weer de basisuitgangspunten van de opdracht ter discussie stellen, wat alle voordelen van de agile aanpak teniet doet. In de agile aanpak Scrum stelt men niet voor niets dat er wel eerst een product backlog moet zijn voordat de sprint backlog kan worden vastgesteld (zie hoofdstuk 29 Scrum). De AgilePM-aanpak zorgt voor een goede voorbereiding, zonder dat daarbij het gehele project in detail wordt uitgewerkt. Slechte communicatie Slechte communicatie wordt vaak gezien als het kernprobleem van projecten die mislukken. Het managen van de verwachtingen van alle betrokken partijen maar ook het betrekken van alle noodzakelijke partijen bij de besluitvorming is essentieel voor het succesvol uitvoeren van ieder project. AgilePM ondersteunt de communicatie in projecten door het faciliteren van de communicatie tussen partijen, door het visualiseren van oplossingen en door het goed definiëren van rollen en verantwoordelijkheden van de verschillende belanghebbende partijen. 1.6 Over dit boek Dit boek is geschreven voor de Projectmanager die leidinggeeft of gaat geven aan agile projecten. Vanuit deze invalshoek is er een directe aansluiting met het DSDM AgilePM, Agile Project Management Handbook V2. Het is echter geen rechtstreekse vertaling van dit handboek. Op onderdelen geven we een eigen visie op het managen van agile projecten. Verder hebben we getracht de methode meer toegankelijk te maken voor de lezer. Om die reden hebben we de hoofdstukken uit het Engelse handboek anders ingedeeld en onderverdeeld in drie delen. We hebben bovendien een deel IV toegevoegd over de toepassing van AgilePM in combinatie met PRINCE2, Scrum, Lean Six Sigma en Kanban. Ten slotte hebben we een vertaallijst Nederlands-Engels en een vertaallijst Engels-Nederlands opgenomen in bijlage E. Deel I. Methodiek In deel I worden de uitgangspunten, het raamwerk, de filosofie, de principes en de succesfactoren van AgilePM beschreven. Verder worden in dit deel de AgilePM-rollen, -processen en -producten beschreven.
Inleiding 11 Deel II. Projectmanagement In dit deel wordt nader ingegaan op de consequenties van de AgilePM-aanpak voor de verschillende aspecten van projectmanagement. Deel III. Technieken In deel III worden de afzonderlijke technieken beschreven die in agile projecten worden toegepast om ervoor te zorgen dat de filosofie en uitgangspunten van AgilePM in projecten ook daadwerkelijk worden ingevuld. Deel IV. Afstemming In dit deel wordt ingegaan op de vraag hoe de verschillende methoden zich tot elkaar verhouden. AgilePM en PRINCE2 worden met elkaar vergeleken. Scrum, Lean Six Sigma en Kanban worden nader toegelicht. Verder wordt aangegeven hoe de verschillende methoden zijn te combineren en hoe een complete portfolio van projecten met verschillende methoden het best kan worden gemanaged. Bijlagen In bijlage A is een Vragenlijst Projectaanpak opgenomen. Bijlage B geeft een overzicht van de verschillende rollen en verantwoordelijkheden. Bijlage C geeft een overzicht van de Agile- PM-producten. Bijlage D bevat een begrippenlijst. In bijlage E zijn een vertaallijst Nederlands-Engels en een vertaallijst Engels-Nederlands opgenomen. 1.7 Voorbereiding op examens AgilePM Dit boek is een geschikte basis om zich voor te bereiden op het examen AgilePM Foundation en Practitioner. Daarvoor geldt als leeswijzer: Examenstof AgilePM Foundation: - deel I: in zijn geheel met uitzondering van de gemarkeerde alinea s in hoofdstuk 7; - deel II: alleen hoofdstuk 9; - deel III: in zijn geheel met uitzondering van hoofdstuk 24; - bijlage D: definitielijst. Examenstof AgilePM Practitioner: - deel I, II en III met uitzondering van hoofdstuk 17 en 24. - bijlagen A, B, C en D. De alinea s in hoofdstuk 7 Procesmodel, die geen examenstof zijn voor de AgilePM Foundation zijn in de kantlijn met een verticale lijn gemarkeerd. Voor de specifieke AgilePM-begrippen hebben we zo veel mogelijk de officiële vertaallijst van APMG aangehouden. Waar wij van deze vertaallijst afwijken, is in de vertaallijst de vertaling die door APMG wordt aangehouden er tussen haakjes achter vermeld.
12 Managen van agile projecten Ten slotte zijn we vanuit onze eigen ervaring op onderdelen van de officiële versie van AgilePM afgeweken. Waar we dat doen, vermelden we dit. Ook hebben we soms de verantwoordelijkheden anders belegd. In dergelijke gevallen hebben we de verantwoordelijkheden volgens AgilePM in een voetnoot opgenomen. 1.8 Gebruik van hoofdletters In dit boek worden alle specifieke AgilePM-rollen, -processen en -producten met een beginhoofdletter aangegeven, bijvoorbeeld Projectmanager en Timeboxplan.
2 Uitgangspunten Agile Zoals al in de inleiding gezegd, is agile meer een gedachtegoed dan een vastomlijnde methode. Dit gedachtegoed vindt zijn oorsprong in de IT-softwareontwikkeling en is in 2001 vastgelegd in het Manifesto for Agile Software Development, vaak kortweg Agile Manifesto genoemd. Sindsdien heeft agile zich meer en meer ontwikkeld tot een aanpak binnen de bredere context van productontwikkeling. De laatste jaren heeft agile zich verder verbreed tot een aanpak voor allerlei soorten projecten. In principe kan ieder project agile worden aangepakt waar nauwe samenwerking tussen gebruikers en Ontwikkelaars en een regel matige terugkoppeling van klanten en gebruikers naar het Ontwikkelteam vereist is. Agile biedt een raamwerk om een goed resultaat op tijd en binnen budget op te leveren, door het: - focussen op het op te leveren resultaat; - prioriteren van de gewenste functies ; - ontwikkelen van het op te leveren resultaat in korte iteraties (timeboxes); - incrementeel opleveren van het resultaat om maximale toegevoegde waarde te leveren; - stimuleren van de samenwerking tussen alle bij het project betrokken partijen; - vastleggen van kwaliteit, tijd en geld als een niet-onderhandelbare norm; - definiëren van duidelijke rollen en verantwoordelijkheden. In agile projecten staan de klant- en gebruikerseisen centraal. 2.1 Projectvariabelen Een van de belangrijkste verschillen tussen de traditionele projectaanpak en een agile aanpak is de beheersing van het project. In een traditioneel project worden scope en in mindere mate kwaliteit als norm vastgelegd en zijn tijd en geld streefwaarden. In een agile project zijn kwaliteit, tijd en geld een niet-onderhandelbare norm en worden de op te leveren functies geprioriteerd (zie figuur 2.1). Als werkzaamheden in een traditioneel project tegenvallen betekent dit vrijwel automatisch een uitloop in tijd en geld, omdat wordt vastgehouden aan de bij de start van het project gedefinieerde scope en kwaliteit. In een agile project wordt de scope vastgelegd in een aantal te realiseren functies. Deze functies worden vervolgens geprioriteerd. Als nu werkzaamheden tegenvallen worden optionele en niet noodzakelijke functies geschrapt. Zolang de noodzakelijke functies worden opgeleverd is er een levensvatbaar resultaat. De buffer bestaat dus uit de niet noodzakelijke functies die kunnen worden geschrapt. Dit is meestal voldoende om de gebruikelijke tegenslagen in een project op te vangen. Zolang er
14 Managen van agile projecten Varieert: Tijd Geld Functies Traditioneel Agile Vast: Scope Tijd Geld Figuur 2.1 Projectvariabelen in traditionele en agile projecten goed wordt geprioriteerd, zal dus vrijwel altijd de minimaal noodzakelijke subset van het resultaat kunnen worden opgeleverd. 2.2 Op maat maken Net als bij traditionele projecten is het bij agile projecten van belang de projectaanpak op maat te maken. Hoeveel increments zijn er nodig, hoeveel timeboxes per increment en hoelang duren de timeboxes? Hoe verdelen we de rollen en verantwoordelijkheden en kunnen we rollen eventueel samenvoegen? Wat doen we formeel en wat doen we informeel? Welke managementproducten gaan we gebruiken? Welke managementproducten kunnen we samenvoegen? Wat is het mandaat van de zelfsturende teams? Wanneer moet worden geëscaleerd? Belangrijk is het om dit bij de start van het project af te spreken. Zie hiervoor ook hoofdstuk 6 Procesmodel. Zorg altijd voor zichtbare beheersing.
3 AgilePM-filosofie en -raamwerk De AgilePM-aanpak omvat een filosofie en een raamwerk, bestaande uit acht principes en een viertal ondersteunende bouwstenen (zie figuur 3.1). De AgilePM-filosofie is dat ieder project moet worden afgestemd op duidelijk gedefinieerde bedrijfsdoelen en moet focussen op een vroege oplevering van producten die echt toe gevoegde waarde leveren aan de bedrijfsorganisatie. De AgilePM-principes zijn: (1) Focus op de bedrijfsbehoefte, (2) Lever op tijd, (3) Werk incrementeel vanaf een stevige basis, (4) Ontwikkel iteratief, (5) Werk samen, (6) Doe geen concessies aan kwaliteit, (7) Communiceer continu en duidelijk, en (8) Zorg voor zichtbare beheersing (zie hoofdstuk 4 AgilePM-principes). Filosofie Focus op de bedrijfsbehoefte beheersing Zorg voor zichtbare Mensen Processen Lever op tijd Communiceer continu en duidelijk Werk samen Ontwikkel iteratief aan kwaliteit Doe geen concessies Werk incrementeel vanaf een stevige basis Figuur 3.1 AgilePM-filosofie en -raamwerk De vier AgilePM-bouwstenen zijn: - Mensen > de rollen en verantwoordelijkheden (hoofdstuk 6); - Processen > de afzonderlijke stappen in de projectlevenscyclus (hoofdstuk 7); - Producten > de noodzakelijk op te leveren producten (hoofdstuk 8); - Toepassingen > de te gebruiken tools en technieken (deel III).
16 Managen van agile projecten
4 AgilePM-principes Agile kent twaalf principes (zie hoofdstuk 1 Inleiding). De agile principes zijn met name gericht op het zelfsturende team. AgilePM kent een achttal principes. De AgilePM-principes zijn meer gericht op het project als geheel. In dit hoofdstuk gaat het over de AgilePMprincipes die ten grondslag liggen aan de specifieke AgilePM-methode. Een agile project kan op verschillende manieren worden vormgegeven. Het is daarbij echter belangrijk dat te allen tijde deze acht AgilePM-principes worden nagevolgd. Als dat niet gebeurt, gaat een deel van de kracht van de onderliggende filosofie verloren en neemt de kans toe dat niet langer de maximale voordelen van de AgilePM-methode worden gerealiseerd. Het in onderlinge samenhang toepassen van al deze acht principes maakt het mogelijk met de op te leveren producten de maximale waarde te creëren voor de organisatie. De acht AgilePM-principes zijn: 1. Focus op de bedrijfsbehoefte. 2. Lever op tijd. 3. Werk incrementeel vanaf een stevige basis. 4. Ontwikkel iteratief. 5. Werk samen. 6. Doe geen concessies aan kwaliteit. 7. Communiceer continu en duidelijk. 8. Zorg voor zichtbare beheersing. 4.1 Principe 1: Focus op de bedrijfsbehoefte Iedere beslissing binnen het project moet gericht zijn op het realiseren van maximale toegevoegde waarde voor de organisatie. Het op te leveren resultaat moet bijdragen aan het effect dat de organisatie met het resultaat wil bereiken. Het op te leveren resultaat is een middel en geen doel op zich. Om aan te sluiten op dit principe: - Begrijp wat de echte prioriteiten zijn van de organisatie. - Zorg dat een valide Business Case wordt opgesteld. - Stel zeker dat de Bedrijfssponsor ook echt eigenaar is van het project. - Zorg dat de minimaal bruikbare subset van het op te leveren resultaat wordt opgeleverd. Dit eerste principe wordt ondersteund door de rol van de verschillende vertegenwoordigers van de bedrijfsorganisatie in de projectbesturing en het Ontwikkelteam en door de prioritering van de op te leveren functies. Een belangrijke basis voor dit eerste principe wordt gelegd in de Fundatiefase. De prioritering van de benodigde functies helpt het Ontwikkelteam om de focus op de bedrijfsbehoefte gedurende het gehele project vast te houden.
18 Managen van agile projecten 4.2 Principe 2: Lever op tijd Op tijd opleveren is voor de meeste projecten erg belangrijk. Door (te) late oplevering kan het gehele project mislukken. Dit is met name het geval bij commercieel georiënteerde projecten en projecten op basis van wet- en regelgeving. Maar ook bij gewone projecten kan late oplevering een faalcriterium zijn. Daarbij is het vaak niet belangrijk dat alles op tijd wordt opgeleverd, maar wel de minimaal bruikbare subset; en die dan het liefst nog in gedeelten, zodat de meest cruciale onderdelen wel alvast in gebruik kunnen worden genomen. Om aan te sluiten op dit principe: - Maak gebruik van timeboxes. - Leg tijd als een niet-onderhandelbare norm vast. - Prioriteer de op te leveren functies. - Laat bij tegenslag gewenste en optionele functies vallen. - Lever incrementeel op. Timeboxing en de prioritering van de benodigde functies zijn essentiële technieken voor het Ontwikkelteam om aan dit principe te kunnen voldoen. 4.3 Principe 3: Werk incrementeel vanaf een stevige basis Om zo snel mogelijk waarde toe te voegen moet er gefaseerd worden opgeleverd. Dit maakt dat belanghebbenden vertrouwen krijgen in het team, dat het team snel feedback ontvangt en dat de toegevoegde waarde voor de organisatie wordt gemaximaliseerd. Dus niet één resultaat op het eind van het project, maar deelresultaten aan het einde van ieder increment. Belangrijk daarbij is dat niet vooraf een gedetailleerd programma van eisen wordt opgesteld. Niet te weinig, want dan heb je geen houvast. Niet te veel, want dat kost alleen maar tijd en belemmert het team bij het gebruikmaken van voortschrijdend inzicht. Aan het begin van een project zijn toch nog niet alle eisen helder, het is dus zonde van de tijd om daar te lang bij stil te staan. De Engelsen noemen dit Enough Design Up Front (EDUF), in plaats van Big Design Up Front (BDUF) of No Design Up Front (NDUF). Om aan te sluiten op dit principe: - Bevestig telkens aan het einde van iedere timebox dat het juiste resultaat is opgeleverd. - Herijk formeel de prioritering en de levensvatbaar heid van het project bij ieder increment. - Streef naar het zo snel mogelijk realiseren van de bedrijfsdoelstellingen. In de Haalbaarheids- en Fundatiefase wordt de basis voor de uitvoering van het project gelegd. aan het eind van ieder increment wordt een bruikbaar deelresultaat van het op te leveren resultaat opgeleverd (zie hoofdstuk 7 Procesmodel).
AgilePM-principes 19 4.4 Principe 4: Ontwikkel iteratief Om maximale toegevoegde waarde te leveren, moet het op te leveren resultaat iteratief worden ontwikkeld. Dit geldt op alle niveaus van het project. Vrijwel niets wordt in één keer hele maal goed opgeleverd. Feedback is nodig om tot een goede oplossing te komen. Door het resultaat iteratief te ontwikkelen kunnen veranderingen eenvoudig worden meegenomen. Om aan te sluiten op dit principe: - Zorg voor een goed basisontwerp in de Fundatiefase. - Accepteer dat details vaak aan het begin van het project nog niet bekend zijn. - Zorg dat de gebruiker feedback geeft aan het einde van iedere iteratie. - Wees creatief, experimenteer, leer en ontwikkel. - Omarm veranderingen. Veranderingen zijn niet te voorkomen en als je een verandering doorvoert vergroot dat meestal de waarde van het op te leveren resultaat. Men vraagt niet voor niets om iets te veranderen. 4.5 Principe 5: Werk samen Samenwerking is belangrijk. Met name bij de vertaling van de bedrijfsbehoeften naar een werkbaar resultaat is samenwerking van essentieel belang. Uit het overleg tussen de deelnemers uit de bedrijfsorganisatie en de experts van de leverancier wordt pas echt duidelijk wat er nodig is. Uit de samenwerking komen oplossingen naar voren die ieder voor zich niet had gevonden. Samenwerking genereert ook energie. Het is daarbij wel essentieel dat partijen ook het mandaat hebben om samen beslissingen te nemen. In projecten geldt zeker: het geheel is meer dan de som der delen. Om aan te sluiten op dit principe: - Betrek belanghebbenden vanaf het begin bij het project. - Zorg dat de teamleden het mandaat hebben om samen beslissingen te nemen. - Zorg dat het Ontwikkelteam één team wordt. Het houden van gefaciliteerde workshops is een goede manier om de samenwerking vorm te geven en te versterken. De Projectmanager en de Teammanager spelen hierbij een belangrijke rol, maar ook de Bedrijfsanalist. Hij moet zekerstellen dat de gekozen oplossing aansluit op de bedrijfsbehoeften.
20 Managen van agile projecten 4.6 Principe 6: Doe geen concessies aan kwaliteit De kwaliteit van het op te leveren resultaat moet vooraf als een niet-onderhandelbare norm worden vastgesteld. Om aan te sluiten op dit principe: - Bepaal de kwaliteitsstandaard voordat met de uitvoering wordt gestart. - Bepaal vooraf de acceptatiecriteria en op welke wijze deze zullen worden getest. - Test vanaf het begin alle resultaten steeds weer opnieuw. - Review op het eind van iedere timebox het resultaat vanuit de bedrijfsoptiek. De vaste inrichting van een timebox en de prioritering van de benodigde functies helpen het Ontwikkelteam om aan dit principe te voldoen. Door niet-noodzakelijke functies te laten vervallen, voorkom je dat de kwaliteit van de op te leveren functies onder druk komt te staan. 4.7 Principe 7: Communiceer continu en duidelijk Zoals al eerder aangegeven wordt slechte communicatie vaak gezien als het grootste probleem in projecten die mislukken. AgilePM is voortdurend gericht op optimale communicatie tussen alle betrokken partijen. Om aan te sluiten op dit principe: - Zorg voor duidelijke rollen en verantwoordelijkheden. - Maak gebruik van storyboard s, modellen en dergelijke om oplossingen te visualiseren. - Houd dagelijks voortgangsbesprekingen (stand-ups 5 ). - Maak gebruik van gefaciliteerde workshops. - Moedig informeel overleg aan en stimuleer overleg. - Houd de documentatie beperkt. 4.8 Principe 8: Zorg voor zichtbare beheersing Uiteraard is het van belang dat je in control bent. Maar dat is niet voldoende. Dit moet ook voor anderen duidelijk zijn. Anders wordt men (terecht) zenuwachtig en grijpt men in waar het niet nodig is of houdt men beslissingen tegen omdat men niet zeker is. Dat geldt zowel voor de zakelijke rechtvaardiging van het project als voor de gekozen oplossing. Dat is zeer ineffectief. Een mondelinge toelichting is vaak niet voldoende. Om aan te sluiten op dit principe: - Zorg voor voldoende formele bewaking en rapportage. - Zorg dat plannen bekend zijn en communiceer de voortgang. 5 Een bijeenkomst waarbij de deelnemers blijven staan om een actieve houding te creëren en om ervoor te zorgen dat de bijeenkomst niet te lang duurt.
AgilePM-principes 21 - Rapporteer de voortgang aan de hand van opgeleverde resultaten. - Wacht niet tot men er om vraagt; rapporteer periodiek en proactief. - Evalueer ten minste bij ieder increment de levensvatbaar heid van het project. De Beschrijving Managementaanpak en het Realisatieplan in combinatie met het gebruik van timeboxes met vastgestelde reviewmomenten en Timeboxplannen (zie hoofdstuk 8 Producten) helpt de Projectmanager om voortdurend aan te kunnen tonen dat het project beheerst verloopt en onder controle is.
22 Managen van agile projecten
5 Succesfactoren 5.1 Randvoorwaarden voor succes Niet ieder agile project is bij voorbaat succesvol. Naast de acht AgilePM-principes zijn er nog andere factoren die in belangrijke mate bijdragen aan het succes (of het falen) van een agile project. Het ontbreken van zo n succesfactor is een risico voor het project en moet dan ook als zodanig worden opgepakt. Deze essentiële succesfactoren worden hieronder beschreven. Acceptatie van de agile aanpak vóór de start van het werk Het is belangrijk dat zowel de bedrijfsvertegenwoordigers als het Ontwikkelteam de agilefilosofie omarmen voordat een project op basis van agile wordt opgestart. Niet alleen in grote lijnen maar ook in detail: wat betekent de keuze voor deze aanpak voor het project en voor ieders rol binnen het project? Het is het mooiste als er een echte buy-in ontstaat bij de belangrijkste betrokkenen. Een agile Projectmanager over de invoering van de agile aanpak: Nu we zo n twee jaar agile werken, hebben we ook wat AINO-ervaringen gehad (AINO = Agile In Name Only, vergelijkbaar met PINO = PRINCE In Name Only). Men zei dat men agile werkte, maar er werden nog steeds gedetailleerde specificaties opgesteld en analisten en Ontwikkelaars werkten toch nog met de watervalmethode. We hebben er als begeleidingsteam toen enorm op gehamerd dat het niet uitsluitend ging om de tools, maar om de gedachte achter het agile werken en de voordelen die het oplevert. Door er uitgebreid over te praten en door het inzetten van workshops kregen we ze langzaam mee, en gingen de teams echt agile werken. En ja, door het introduceren van AINO als term maakten we het bespreekbaar. Mandaat voor het Ontwikkelteam Empowerment betekent letterlijk met gegeven macht. Het team moet behalve de autoriteit om beslissingen te nemen echter ook voldoende middelen en speelruimte krijgen om beslissingen te nemen. Het Ontwikkelteam is een zelfsturend team dat in nauwe samenwerking met de bedrijfsvertegenwoordigers werkt, binnen de gegeven randvoorwaarden. Dit kan alleen als de teamleden afzonderlijk en het team als geheel een mandaat krijgen van het management waarbinnen zij zelf beslissingen kunnen nemen. Commitment en betrokkenheid van het bedrijfsmanagement Zoals voor elk project is ook voor agile projecten commitment vanuit de organisatie essentieel. Belangrijk is dat de Bedrijfssponsor en de Bedrijfsvisionair zich ook echt verantwoordelijk voelen voor het succes van het project én de te realiseren baten. Dit commitment is voorwaardelijk voor de noodzakelijke inzet van de Bedrijfsambassadeurs en de Bedrijfsanalist in het project (zie volgende punt).
24 Managen van agile projecten Inzet van de Bedrijfsambassadeur en de Bedrijfsanalist De invulling van deze rollen is van essentieel belang, omdat zij de verbindende schakels zijn tussen de bedrijfsorganisatie en het Ontwikkelteam. Eigen werkruimte Een eigen werkruimte waar het Ontwikkelteam gezamenlijk en ongestoord aan de ontwikkeling van het projectresultaat kan werken, vergroot de productiviteit van het team, versterkt de onderlinge interactie en versterkt de gemeenschappelijke verantwoordelijkheid voor het op te leveren resultaat. Pas echter op dat het Ontwikkelteam zich daarbij niet isoleert van de bedrijfsvertegenwoordigers en andere belanghebbenden van het project. Bereikbaarheid bedrijfsvertegenwoordigers Een goede bereikbaarheid van alle betrokkenen is cruciaal om snel te kunnen schakelen tussen bijvoorbeeld Bedrijfsambassadeurs, Bedrijfsanalisten en de overige leden van het Ontwikkelteam. Ook een goede bereikbaarheid van de Bedrijfsvisionair en de Technisch Coördinator is belangrijk. Vaste teamsamenstelling Wisselingen in de teamsamenstelling zijn niet helemaal te voorkomen. Als het team te vaak en te snel van samenstelling verandert, wordt het risico echter te groot. Belanghebbenden verliezen dan het vertrouwen dat het team nog in controle is. De opgebouwde kennis en samen hang gaat verloren en relaties met derden moeten telkens opnieuw worden opgebouwd. Als er toch gewisseld moet worden, dan het liefst bij de start van een nieuwe increment. Voldoende kennis en ervaring Niet voor niets zegt Collins in zijn boek Good to Great: First who, then what. De juiste mensen aan boord, daar draait het om. Het gaat daarbij niet alleen over iemands technische kwaliteiten, maar ook over zijn kennis van de klantorganisatie, zijn sociale vaardigheden en zijn vermogen om te kunnen samenwerken in een team. Goed kunnen communiceren is daarbij een voorwaarde voor alle teamleden. Juiste teamgrootte Het team moet niet te klein, maar ook weer niet te groot zijn. Een aantal van circa zeven personen (minimaal vijf en maximaal negen) wordt doorgaans als ideaal gezien. Te kleine teams zijn kwetsbaar bij uitval van één van de teamleden. Kleine teams kunnen meestal ook niet alle noodzakelijke expertises afdekken. Grote teams hebben het probleem van subgroepen en een exponentiële toename van het noodzakelijke overleg. Grotere teams vragen dan ook vaak een meer formele aansturing, waarmee de wendbaarheid van een Ontwikkelteam gedeeltelijk verloren gaat. Grote teams kunnen dan ook het best worden opgesplitst in twee of meer parallelle, kleine teams.