Innovatie & Strategie

Software-ontwikkeling
teamwork

Beheersbaar agile

Grootschalig uit de bocht vliegen van grote agile projecten is te voorkomen

© Pixabay licence geralt
29 september 2020

Grootschalig uit de bocht vliegen van grote agile projecten is te voorkomen

Door grootschalig agile werken in de praktijk ontstaan inmiddels de eerste pijnlijke dossiers waarbij grote agile projecten mislukken. Gerard Meijer en Rini van Solingen laten zien hoe dit komt en wat je eraan kunt doen. Vorige maand publiceerden zij deel I: de oorzaken van falend agile in grote projecten. Deze maand geven zij in deel II aan met welke interventies je in grote agile projecten de noodzakelijke beheersmatigheid kunt toevoegen.

Door de toenemende dynamiek, snelheid en onvoorspelbaarheid in organisaties is men in de praktijk grotendeels overgestapt op agile manieren van werken. Aan de ene kant met veel positieve ervaringen, maar agile is zeker geen silver bullet. In de praktijk komen namelijk ook steeds meer concrete verhalen beschikbaar over grote projecten die met een agile manier van werken volledig ontsporen. Veelal komt dit doordat met de introductie van agile ook alle beheersmatigheid van de kar is gevallen. Bij grote projecten is er behoefte aan beheersing en planmatigheid. Zeker als het gaat om strategische initiatieven met een duidelijke scope en keiharde deadlines.

SAFe

Als agile inspanningen omvangrijk zijn en over vele teams lopen, wordt vaak extra coördinatie en afstemming ingericht met een schalingsraamwerk. SAFe (het Scaled Agile Framework) is daarvoor de de facto aanpak. Het meest prominente element van SAFe om planmatigheid aan te brengen, is de PI-planning. Dit is een terugkerende planningbijeenkomst (meestal 1x per kwartaal), waarbij alle teams gezamenlijk de komende periode vooruitplannen en afhankelijkheden afstemmen (zie ook AG Connect – van Solingen/van Lieshout – 25 oktober 2017).

Met behulp van SAFe wordt dan van PI-planning naar PI-planning gewerkt. Ook al worden deze bijeenkomsten als waardevol ervaren, toch blijkt de haalbaarheid van een kwartaal in de praktijk nog erg lastig. In de meeste grote projecten is besluitvorming echter gebaseerd op een zekere functionaliteit die op een vooraf bepaalde datum, binnen budget, in productie moet. Een PI-planning biedt feitelijk alleen een momentopname. Voor het verhogen van planbaarheid is SAFe bij grote projecten niet de oplossing; ook al wordt de schijn geboden dat dat wel het geval is doordat er elk kwartaal een PI-planning wordt gedaan.

Projectbeheersing aan agile toevoegen

Gelukkig is het wel mogelijk om de intrinsieke afwezigheid van projectbeheersing bij grote agile projecten er later ‘tegenaan te metselen’. In kader 1: Tien interventies om beheersmatigheid aan agile toe te voegen, wordt een lijst van maatregelen gegeven. De dode hoek bij grote agile projecten wordt daarmee zichtbaar gemaakt en beheersmaatregelen worden aangebracht.

Daarmee is het geen garantie dat grote trajecten nooit mislopen, maar het is dan in elk geval zeker geen verassing meer die pas laat en aan het einde van het budget zichtbaar wordt. Kleine projecten blijven uiteraard de voorkeur houden. Groot opknippen in klein is nog steeds een goed idee. Echter, als het écht groot is en niet kan worden opgeknipt, dan zullen beheersingsstructuren moeten worden toegevoegd. En dat kan. Ook bij grote agile projecten. Maar daarmee is agile geen silver bullet voor grote projecten. Silver bullets bestaan namelijk niet. Het blijft gewoon keihard werken. En vooral je verstand en vakmanschap gebruiken!

10 interventies om beheersmatigheid aan agile toe te voegen

 

1. Maak de definitie van projectsucces expliciet – Stel op voorhand expliciet op wat een project succesvol maakt. Welke meetbare indicatoren tonen aan dat het een succes is? Bepaal ook de kernoorzaak waarom projecten moeizaam verliepen of zelfs mislukten. Kies op grond van deze kennis de beste bijpassende projectstrategie. Agile kan dan best een prima keuze zijn. Maar het maken en uitvoeren van een lineair plan kan soms gewoon beter zijn.

2. Eis iteratief opleveren met een reallife DoD – Zodra er voor een agile werkwijze is gekozen, zal deze ook volgens die principes geïmplementeerd moeten worden. Iteratief opleveren en elke sprint integreren vormt de kern. De Definition of Done (DoD) is daarvoor cruciaal, maar krijgt in de praktijk niet de aandacht die het verdient. Zeker bij samenwerking tussen vele teams in een geschaalde aanpak raakt de DoD al snel op de achtergrond. De verleiding is dan groot om opleveren en integratie uit te stellen tot het eind van het kwartaal. Maar daardoor wordt de fundamentele basis onder agile – stapsgewijs opleveren – compleet overboord gekieperd. Richt dus beheersmatige maatregelen in die iteratief opleveren afdwingen. De DoD is daarvoor een onmisbaar instrument.

3. Werk de product backlog volledig uit – Hoewel agile in staat is om constant de product backlog aan te passen, is dat niet het primaire doel. Vooral bij grote projecten met vaste(re) scope en deadlines zijn wijzigingen niet heel welkom. Als het echt nodig is: prima, maar wel binnen de gestelde kaders en met zichtbare impact op tijd, geld en kwaliteit. Een manier om dat te doen is door de hele product backlog op voorhand uit te werken tot een detailniveau waarbij redelijk betrouwbare schattingen gemaakt kunnen worden. Dan kan er dus tijdmatig gepland worden en haalbaar rekening worden gehouden met deadlines.

4. Beheers de product backlog via formele change control – Met een volledig uitgewerkte product backlog kan ook een gestructureerde manier van change control worden ingericht. Als er gedurende het project werk ontdekt wordt dat moet worden toegevoegd, dan kan direct gekeken worden wat de impact is op het tijdpad en budget. Beter is dan om eerst te bepalen welke delen van de product backlog verwijderd moeten worden voordat iets mag worden toegevoegd. Om klassieke problemen rond uitloop, budgetoverschrijding en kwaliteitsproblemen te voorkomen, is formeel change control nodig; ook bij grote agile projecten.

5. Richt scope control op output en outcome in – Bij (grote) projecten met vaste scope en een vaste opleverdatum is het werken met agile extra uitdagend. Daarom is het belangrijk dat wat er wordt opgeleverd (output) en wat dat oplevert (outcome) op een gestructureerde manier onder controle wordt gehouden. Daarmee wordt een zwalkende scope onder invloed van eenvoudige aanpasbaarheid vermeden.

6. Voer voortgangsbewaking met resultaatmetingen in – Elke investering wordt gedaan op basis van een verwacht rendement. Als een en ander klein en overzichtelijk is, wordt dit vaak informeel en via de agile (review) meetings ingevuld. Zodra het groot wordt, is dat lastiger. Zeker als het gaat om resultaten die vanuit meerdere teams geïntegreerd worden. Dan is het belangrijk dat voortgangsbewaking expliciet wordt ingericht, waarbij zowel naar output als outcome meetbaar wordt neergezet.

7. Installeer risicomanagement – Bij grote projecten loopt een organisatie grote risico’s. Formeel risicomanagement is dan nodig. Installeer dat rond de agile manier van werken en de betrokken agile teams. Enerzijds op basis van kortcyclisch opleveren, continue kwaliteitstoetsen en validatie met gebruikers, maar daarnaast ook gewoon op alle standaardprojectrisico’s. Inderdaad, de klassieke boeken over risicomanagement mogen bij agile uit de kast worden gepakt.

8. Stel architectuurkaders op en richt auditing in – Veel agile trajecten gaan uit van emerging architectures: het principe dat door iteratief op te leveren en te toetsen, de benodigde architectuur vanzelf helder wordt. Dat is een mooie gedachte maar bij grote projecten in de praktijk vrijwel ondoenlijk. Werken zonder op voorhand bepaalde architectuurkaders is bij dergelijke projecten ondoenlijk. Een groot risico is namelijk dat teams zo snel mogelijk beginnen met sprinten en steeds weer een stukje aan het systeem vastbreien. Simpelweg vertrouwen dat de tijd het architectuurvraagstuk op zal lossen is echt te naïef; helemaal als er ook een keiharde deadline is.

9. Bouw managementexpertise over agile op – Het neerzetten van een agile context met dito cultuur wordt gedaan door het leiderschap en management van een organisatie. Als die nog beperkte kennis en ervaring hebben met agile, zullen ze veel beginnersfouten maken. De symptomen daarvan zijn het ingrijpen in detailbeslissingen die juist bij de teams horen te liggen en/of het uitblijven van actie door het management in het stellen van kaders voor diezelfde teams. Het is feitelijk ondoenlijk om succesvol een groot agile project tot een goed einde te brengen als het management agile niet beheerst. De korte route naar dergelijke ervaring en praktische expertise bij leidinggevenden is door deze bewust te werven op basis van hun trackrecord bij andere organisaties.

10. Ontwikkel persoonlijk vakmanschap en zelfdiscipline – Doordat agile sterk leunt op vakmanschap in de teams, hun volwassenheid, eigenaarschap en discipline, is dit een aandachtspunt dat continu energie en verbetering behoeft. In de praktijk is daar zelden gerichte aandacht voor. Het wordt eerder als vanzelfsprekend en reeds aanwezig beschouwd. Gerichte activiteit en ontwikkeling van vakmanschap en eigenaarschap is echter nodig. En dit houdt nooit op. Een bijl moet je blijven slijpen; zeker als deze intensief wordt gebruikt.

 

 

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (septembernummer, 2020). Wil je alle artikelen uit dit nummer lezen, klik dan hier voor de inhoudsopgave.

Lees meer over Innovatie & Strategie OP AG Intelligence
1
Reacties
Bop 05 oktober 2020 15:26

'Essjaail' ('agile', lenig) is trouwens geen zelfstandig naamwoord.
'Agility' wel.

Staat zo stom anders.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.