Softwareontwikkeling en Agile zijn anno 2022 praktisch synoniem aan elkaar. Meer dan 75% van de organisaties welke met ontwikkeling te maken hebben geeft aan Agile te werken of bezig te zijn met een Agile transformatie¹ ² ³. Inmiddels is Agile daarnaast steeds vaker terug te vinden bij bedrijven die maar weinig met Softwareontwikkeling te maken hebben. Uit onderzoek blijkt dan ook dat organisaties zelf inschatten dat een Agile aanpak gemiddeld 30% betere resultaten oplevert4. Zie bijvoorbeeld ook de sprekende case studies van SAFe, een prominent raamwerk voor Agile op schaal. Hiertussen bevinden zich tot de verbeelding sprekende namen, zoals Cisco en Air France KLM.
De meest genoemde beweegredenen tot een Agile transformatie zijn een snellere levering (Time To Market), meer interactie met stakeholders, meer betrokkenheid en transparantie binnen de eigen organisatie en de wendbaarheid om goed in te kunnen spelen op een steeds sneller veranderende markt.
Echter, deze krachtige voordelen worden niet als door het uitspreken van een toverwoord verworven. Bovendien is er een bruisende industrie van Agile experts en methodieken ontstaan, allen met een (vaak goed verdedigbare) visie over de weg naar succes en een bijbehorend lexicon. Soms zien we door de certificeringen en afkortingen het bos niet meer.
Wat is Agile?
In beginsel is Agile een manifest, geïntroduceerd door Kent Beck en ondertekend door een aantal vooraanstaande namen binnen IT en Development. Als kern stelt het vier vergelijkingen, zoals “Individuals and interactions over processes and tools”. Vervolgens wordt een aantal kernprincipes voor software ontwikkeling omschreven. Het werd al in 2001 opgesteld als tegenreactie op een overheersende cultuur van stroperige bureaucratie en lange, in te veel detail uitgewerkte projectplannen (die vervolgens maar zelden naar wens worden uitgevoerd). Het omschreven doel van deze denkwijze is om klanttevredenheid te bereiken door vroeg, vaak en in een vast ritme uitleveringen te doen, zodat op basis van de resultaten bijstelling kan plaatsvinden. Volgens de theorie kan hiermee de kloof tussen ‘business’ en ‘development’ gedicht worden. Agile in de praktijk manifesteert zich dikwijls als Scrum, Kanban, XP (Extreme Programming) of een combinatie daarvan. Voor Agile op schaal wendt men zich veelal tot SAFe, Scrum of Scrums, LeSS, of het Spotify model. Saillant detail is dat Scrum al in 1995 door Jeff Sutherland en Ken Schwaber werd geïntroduceerd.
Stuk voor stuk hebben deze aanpakken voor én nadelen. Vaak worden door bedrijven de ‘krenten uit de pap gevist’ om te komen tot een op maat gemaakte aanpak met een eigen smaak. Dit klinkt volledig in lijn met het gedachtengoed van wendbaarheid, maar maakt het wel tot noodzaak om de samenhang van verschillende onderdelen goed te doorgronden. Vaak wordt Agile ingezet als het eerdergenoemde ‘toverwoord’, met onwenselijke resultaten als gevolg.
Wat is het niet?
Dikwijls wordt aan uitvoerende teams gevraagd om in ‘sprints’ te itereren en op zelfregulerende wijze resultaten op te leveren, terwijl daaromheen een traditionele organisatie werkt volgens harde deadlines, voortkomende uit kritieke bedrijfsbelangen. Hierdoor kunnen “Agile eilanden” ontstaan. Zo blijkt uit onderzoek dat 70% van ondervraagde Agilisten wrijving ervaart tussen hun team en de rest van de organisatie5. Een andere valkuil is dat Agile als toverwoord lijdt tot een onafgebroken stroom aan deadlines, gehaaste ontwikkelaars en een daardoor opstapelende schuld van kwalitatief slecht ontwikkelde software (technical debt)6.
Dit is niet enkel een probleem binnen de grootste bedrijven, maar eerder een gevolg van verschillende, botsende systemen. Agile is een denkwijze waarvan het succes wordt bepaald door de mate waarin deze door de gehele organisatie wordt toegepast. Het is moeilijk voor te stellen dat harde deadlines ooit geheel zullen verdwijnen. Teams moeten duurzaam werk kunnen leveren, bijvoorbeeld door zelf hun snelheid (velocity) te bepalen. Een essentiële graadmeter voor deze duurzaamheid is de voorspelbaarheid van schatting ten opzichte van realisatie. Het bereiken van harmonie is nooit afgedaan met een simpele implementatie. Sterke teams hebben tijd en reflectie nodig om te groeien.
Hoe dan wel?
In de geest van de denkwijze zelf laat Agile zich het beste stap voor stap introduceren. Voor een pilot project laten we de scope (definitie) open, terwijl de doorlooptijd en het budget vast staan. Op deze manier werkt men toe naar een MVP (Minimal Viable Product), welke is bedoeld om een hypothese van toegevoegde waarde te toetsen en om reactie uit te lokken bij opdrachtgevers. De successen welke uit deze aanpak voortvloeien delen we vervolgens zo breed mogelijk om het draagvlak binnen de organisatie te vergroten. Onlangs heeft onze collega, Robert Tilmans, een artikel geschreven over de transitie van Project naar Poduct management, waarin verder wordt ingegaan op een dergelijke verandering.
Deze nieuwe denkwijze veronderstelt dat een bedrijf moet definiëren hoe waarde stroomt, om zich daar vervolgens omheen te organiseren. Het concept van ‘Flow’ is tevens een van de fundamenten van het breed gedragen Lean. Dit gedachtengoed veronderstelt dat men moet zoeken naar de kortste, meest duurzame doorlooptijd met de hoogst mogelijke kwaliteit en meerwaarde (voor mens en maatschappij). Denken in waardestromen vervangt het traditionele denken in projecten. Daarbij wordt vastgesteld dat waarde nooit door silo’s (bijvoorbeeld afdelingen) stroomt en teams dus multidisciplinair zouden moeten zijn. Voor geïnteresseerden biedt het boek “Project to Product” van Mik Kersten een welkome verdiepingsslag over dit onderwerp.
De theorie klinkt goed, maar de praktische toepassing blijkt vaak weerbarstiger. Het implementeren van blijvende verandering vereist een een krachtig draagvlak. John P. Kotter, emeritus hoogleraar verbonden aan Harvard, introduceert in “Leading Change” het concept van de Guiding Coalition. Deze coalitie bestaat uit ervaren en gerespecteerde leiders uit de organisatie, experts op deelgebieden en in deze context vaak Agile Consultants welke putten uit een brede kennis van praktijk en proces. Wanneer de coalitie handelt vanuit visie, met transparantie en middels een incrementeel opbouwende aanpak is de kans op een succesvolle transformatie groot. De meest succesvolle veranderingen vinden niet ‘top down’ of ‘bottom up’ plaats, maar veel vaker middle out.
Is Agile voor ieder bedrijf?
Om deze vraag te kunnen beantwoorden, is een eerste stap om te bepalen of sprake is van projectmatig werk. Een volgend zinvol onderscheid, geïntroduceerd door organisatietheoreticus Ralph Douglas Stacey in de “Stacey Matrix”, is om in kaart te brengen wat de respectievelijke moeilijkheidsgraad van de materie en de overeenstemming omtrent vereisten zijn. Agile gedijt in die situaties waarin meer onduidelijkheid bestaat en de complexiteit hoger ligt (ook wel ‘the edge of chaos’ genoemd). Een andere overweging is bijvoorbeeld de mate van externe afhankelijkheden: wanneer hoogfrequent met een groot leveranciersnetwerk moet worden afgestemd, kan dit het werken in een kort en vast ritme onwenselijk maken.
Mogelijk volgende stappen?
Hopelijk biedt dit artikel een interessante introductie over het onderwerp van Agile transformatie. Valid heeft geruime ervaring op het gebied van Agile en traditionele Project Management. Wanneer één of meerdere onderwerpen uit dit artikel tot de verbeelding spreken, gaan wij met plezier en vrijblijvend het gesprek aan.
1 Paper: Accelerating velocity and customer value… | Coleman Parks i.o.v. CA technologies | 2016
2 Survey: Mindset en de Agile toepassing in Nederland | 2019
3 Survey: Pulse of the Profession | Project Management Institute | 2017
4 Agile project delivery confidence | PwC | 2017
5 Report: State of Scrum | Scrum Alliance (independent non profit)| 2017
6 Article: Why Developers Hate Agile