5 inzichten over Agile
Hoe ondersteun je de businessdoelen zo optimaal mogelijk vanuit de projecten en programma’s? En wat kunnen we van elkaar leren? Tijdens een Tribers Campfire Session onder leiding van Arie van Bennekum, Melvin van Drimmelen en Ronald Flinterman ontstaan 5 inzichten over Agile.
“Vanuit De Tribers zijn wij overtuigd van de kracht van eenvoud, ook in projecten,” vertelt Melvin van Drimmelen, Agile Coach binnen De Tribers. “Eén van de concepten die daarbij kan ondersteunen, is Agile.” Reden voor De Tribers om samen met Arie van Bennekum een Ronde Tafel rondom Agile te organiseren. Arie is één van de 17 grondleggers van het Agile Manifesto.
Uit het delen van kennis en praktijkervaringen ontstaan tijdens de Ronde Tafel de volgende 5 inzichten:
eenvoud leidt tot focus
Het principe achter Agile is ‘serving the business by being adaptive’ aldus Arie. “Als je Agile goed doet, heb je eenvoud in je projecten,” zo stelt hij. “Niet alleen bij IT, maar ook bij marketing, professionele domeinen en productontwikkeling. Ik pas het overal toe, tot en met mijn privé-omgeving, zelfs bij het verbouwen van mijn keuken. Daarbij waren mijn constraints de tijdslijnen en het budget. Ik hou van koken, dus wilde graag allerlei apparatuur laten installeren. Tijdens de verbouwing moest ik daarover uiteraard keuzes maken. Daarbij wijzigden tijd en geld niet, maar de inzichten wel.” Eén van de deelnemers geeft aan juist voor andere constraints te kiezen. “Wij gaan niet uit van tijd en geld, maar van tijd en scope.”“De klassieke triple constraint bestaat uit requirements, tijd en geld. Daardoor wordt er dan in de praktijk echter vaak iets overgeslagen, vaak zijn dat werkzaamheden achter in de meestal sequentiële keten zoals het testen,” zegt Arie. ”Bij traditionele methoden ga je bij de triple constraint tijdens het project altijd variëren op tijd en geld, waardoor je bijna altijd ook op de kwaliteit van requirements gaat variëren. Binnen Agile leveren we alleen een requirement op die helemaal klopt. Dat betekent dat ik wellicht niet alle requirements oplever, maar wat ik oplever klopt wel. Voor die selectie staan de genoemde bedrijfsdoelen voorop, niet een vaste lijst van requirements. Tijd en geld schuiven daarbij niet.”“Eerst definieer je het doel, en zet je tijd en geld vast als parameters. Tijdens het project pas je wellicht ergens de requirements aan, want elk project kent verrassingen,” vertelt Ronald Flinterman, projectmanager bij De Tribers. Door het doel en de parameters helder te maken, kun je tijdens het project makkelijker keuzes maken en rechtvaardigen.”
het belang van visuals
Een eyeopener voor een aantal deelnemers was het gebruik van visuals. Arie: “Iedereen in een workshop – architecten, gebruikers, ontwerpers en techneuten – heeft zijn eigen taal. Visuals werken goed omdat zij een gemeenschappelijke taal brengen die iedereen begrijpt. Daarnaast worden documentatie en Word-documenten nog al eens met elkaar verward. Documentatie is bewust en ordelijk geregistreerde informatie. De vorm is echter vrij en moet het team dienen.”De visuals worden ingezet ten behoeve van allerlei documentatie waaronder systeemdocumentatie en rapportages. Veel deelnemers herkennen dit. “Ik lever geen rapportages meer aan, maar vraag liever aan mijn opdrachtgever om langs te komen in de projectruimte. Daar kan hij op de muur zien wat er gebeurt.” Dat brengt eenvoud in het project, en bespaart veel tijd. Ook foto’s van de visuals worden als rapportage gebruikt. “Een high light rapport in PRINCE2 hoeft geen geschreven rapport te zijn, maar kan goed met een flip chart,” zegt Arie. Hij gebruikt hiervoor specifieke ‘information radiators’. “Een grafische weergave van bijvoorbeeld de opgeleverde requirements. Dit is een grafiek inclusief color design; we zetten een lijn uit met punten. Rondom de lijn kennen we drie gebieden; een groen gebied wat aangeeft dat het goed gaat. Een blauwe gebied, wat aangeeft dat er aandacht nodig is. En het rode gebied, waarbij het niet goed gaat. De ideale lijn bestaat niet, want je werkt ergens aan. Hiermee kun je echter van een afstand in één oogopslag zien hoe het gaat.”Eén van de deelnemers gebruikt het bord zelfs om successen te vieren:“Wij hebben een taartlijn; als een KPI gehaald is, hangen we hem over de taartlijn heen. De afspraak is dat ik dan de volgende dag voor taart bij de koffie zorg.”
PRINCE2 kan prima samen met Agile
Het idee dat Agile haaks staat op PRINCE2 is een groot misverstand, zo blijkt tijdens de Ronde Tafel. “Veel mensen kennen PRINCE2 vooral in combinatie met de waterval-methodiek, maar dat hoeft niet,” stelt Arie. “PRINCE2 is in principe een vrije mantel waarin je onder kunt brengen wat je wilt en werkt met fases, net als Agile. De Agileprojectcyclus past bijvoorbeeld zo op PRINCE2.” Eén van de deelnemers is het hier volmondig mee eens: “De tollgates uit PRINCE2 kunnen zo overgenomen worden.” Het is daarbij vooral van belang dat je met elkaar de juiste dingen afspreekt, ook al zijn de benamingen in Agile en PRINCE2 net even anders. Daarnaast zal je wel de invulling van tollgates moeten veragiliseren maar dat Agile en PRINCE2 niet samen gaan is een mythe. “Of het nodig is, is wat anders,” stelt Arie met een knipoog. Ondanks dat PRINCE2 goed te combineren is met Agile, is er wel een verschil qua benadering. “Agile is meer gebaseerd op een ontwikkelingsbenadering; het draait om continu leren en veranderen,” zegt Ronald. “PRINCE2 gaat meer uit van een design ontstaan vanuit het totale geheel.”Eén van de deelnemers geeft aan dat zij binnen haar organisatie veel verschillende projectmanagementmethodes tegenkomt. “Binnen onze organisaties lopen er mensen rond die uitgaan van PRINCE2, een aantal die uitgaan van MSP (Managing Succesfull Projects) en een behoorlijk aantal Agile-teams. Een opdrachtgever roept dan enthousiast dat hij een Agile-project wil, maar bij sommige dingen als een eenvoudige vervanging van een systeem vind ik een waterval prettiger.”Een combinatie van methodes lijkt goed te werken. “De organisatie als geheel Agile laten doen, lijkt mij niet handig. Geheel PRINCE2 of MSP™ is echter ook niet handig,” gaat de deelnemer verder. Arie: “Bij een waterval leg je vooraf alles vast. Dat werkt anno nu niet meer. De wereld waarin we leven verandert in een te hoog tempo. Een werkwijze die deze verandering omarmt en niet onderbrengt in moeilijke en tijdrovende processen is de enige weg. Bij complexe oplossingen voor complexe situaties ontdek je een deel van de oplossing tijdens het project. Uitvinden onderweg is iets waar je niet onderuit kunt.”
agile beperkt zich niet tot de kleinere deelprojecten
Veel organisaties worstelen met de alignment tussen meerdere projecten. Eén van de vragen vanuit de deelnemers is dan ook of Agile geschikt is voor een programma met meerdere deelprojecten. Volgens Arie wel: “Hiervoor kun je verschillende methoden toepassen. Voorbeelden zijn het Agile PM Framework, LESS en het Scaled Agile Framework. Dat helpt je om optimaal te schalen, waarbij de samenhang tussen de teams en hun afhankelijkheden duidelijk wordt.“ Dat Agile alleen voor kleine projecten zou gelden is een andere mythe. Zo werkt Arie met een Agile coachingsteam in de Agile Software Factory van Cegeka. In deze factory (Leuven, Brussel) worden zowel miljoenenprojecten als kleine app-projecten succesvol uitgevoerd.“Wij werken met ‘golden rules’ om de afhankelijkheden tussen de teams te borgen,” vertelt een deelnemer. Eén van de basisregels is dat er maximaal 30% afhankelijkheid in de sprints zit. Dat blijkt soms lastig. “In het ene team is het dan maar 30%, terwijl dezelfde afhankelijkheid voor iemand in het andere team 70% betekent.”Daarnaast spelen incidenten een rol. Hiervoor zijn verschillende oplossingen. Zo kan een visuele ‘fast lane’ voor incidenten helpen. “Reserveer 10% voor de fast lane. Als er geen incidenten zijn, is de fast lane niet nodig en kun je de 10% gebruiken voor het andere werk,” adviseert Arie. “Daarnaast werkt het enorm als je ‘work-in-progress’ minimaliseert; ‘stop starting, start finishing’.” Eén van de deelnemers gebruikt de heartbeat voor incidenten. “Dan komt er een ‘on hold’-kolom bij, waar de andere items een plaats krijgen.” Een andere deelnemer hanteert de 80-20 regel: “Mijn mensen mogen maximaal 80% van hun tijd in een project participeren, anders kun je geen prioriteit geven aan incidenten in de bestaande applicatie.”
accountability alleen is niet genoeg
Verantwoordelijkheid nemen is een belangrijk aspect van het Agile-gedachtengoed. Er bestaat daarbij een verschil tussen ‘accountability’ en ‘responsibility’, zo blijkt uit de gesprekken tijdens de Ronde Tafel. “Wij hebben binnen onze organisatie veel discussies gevoerd over het verschil tussen accountability en responsibility,” vertelt een deelnemer. “Accountability kan iemand je opleggen. Responsibility is echter een eigen keuze; je voelt het zelf.” Een andere deelnemer beaamt dit: ‘Het gaat over het voelen van de verantwoordelijkheid. Het is een verschil tussen ‘ik ben hier en ik doe iets’ of ‘ik ben hier en ik wil iets bereiken’.”De manier waarop Agile binnen de organisatie wordt ingevoerd heeft hier ook invloed op. “Als je Agile hiërarchisch vanuit de top doorvoert gaan mensen alleen maar meer terug in hun oude posities,” stelt een deelnemer. “Daarnaast moet ook de opdrachtgever leren hoe het werkt; na het eerste half jaar wordt vaak gezegd dat Agile te weinig oplevert. Als projectmanager investeer ik veel tijd in het meenemen van de opdrachtgever; hij moet bijvoorbeeld leren hoe hij uitlegt waarom hij iets wil hebben.” Arie: “Daarnaast werkt ook hier de information radiator van de requirements mee. Mensen nemen tijdens hun stand up zelf de taak van het bord en gaan er mee aan de slag. Dit pull systeem genereert daarmee direct commitment van degene die het oppakt.”
