Agile assessments

Inleiding

Steeds meer organisaties adopteren een agile werkwijze voor het ontwikkelen van software. De overgang van een vooraf gedefinieerd proces naar een empirisch van onderaf gestuurd proces blijkt in de praktijk vaak geen sinecure en vraagt inspanningen op het gebied van organisatiestructuur, organisatiecultuur, personeel en techniek. In de praktijk constateren wij dan ook vaak ‘agile in name only’-implementaties die uiteindelijk onvoldoende de werkelijke voordelen van agile ontwikkelmethoden opleveren: het sneller bereiken van business value tegen lagere kosten en een wendbaardere organisatie.

Vaak begint de adoptie van agile met het toepassen van een aantal agile technieken, zoals het introduceren van een Scrum-board en dagelijkse stand-up meetings. Door het zichtbaar maken van de voortgang en het verbeteren van de communicatie worden al snel de eerste voordelen geboekt, maar agile werken is meer dan een Scrum-board en een stand-up meeting alleen. Het gaat om een totaal andere benadering van softwareontwikkeling, waarbij veranderingen worden omarmd en de stakeholders nauw betrokken zijn. Daarnaast dient voortdurend gestreefd te worden naar continue verbetering van zowel het proces als het product om het ultieme doel te kunnen waarmaken: kortcyclische opleveringen, zodat snel(ler) kan worden geprofiteerd van hetgeen is ontwikkeld.

In de praktijk komen we vaak tegen dat de developmentteams wel degelijk agile proberen te werken, maar dat de organisatie om hen heen hier nog niet volledig op is aangepast en soms zelfs weerstand uitoefent tegen deze verandering. Zeker wanneer meerdere teams agile werken, is het van belang dat de organisatie goed is ingericht en worden zaken als transparantie en inzicht belangrijker.

We zien dat veel organisaties op de goede weg zijn, bijvoorbeeld door het zelf uitvoeren van sprintreviews en retrospectives na iedere iteratie of de inzet van Scrum-coaches die ondersteuning bieden aan de teams. In aanvulling hierop adviseren wij organisaties om periodiek ook een onafhankelijke agile assessment uit te (laten) voeren om breder inzicht te krijgen in de verbeteringen aan het agile proces, zodat meer voordelen kunnen worden behaald.

Er zijn diverse methoden voor het uitvoeren van agile assessments. Deze variëren van korte online self-assessments voor individuele teams tot uitgebreide volwassenheidsmodellen die de gehele organisatie bestrijken. Omdat de inrichting binnen iedere organisatie anders is en er verschillende agile werkwijzen worden toegepast, is er in de markt geen algemeen geaccepteerde standaard.

KPMG heeft een agile assessment framework ontwikkeld dat op verschillende dimensies toetst of een agile adoptie geslaagd is in relatie tot de bedrijfsdoelstellingen en dat verbeterpunten onderkent. In dit artikel gaan wij in op het toetsen van agile werken, gebaseerd op het KPMG agile assessment framework, waarbij we speciale aandacht geven aan de grootste uitdagingen die organisaties hierin tegenkomen.

Uitdagingen bij agile werken

Voordat we dieper ingaan op het uitvoeren van agile assessments, willen we eerst kort stilstaan bij de uitdagingen die een agile werkwijze met zich meebrengt. Zoals we in de inleiding ook al benoemden, vereist de adoptie van een agile werkwijze een fundamenteel andere benadering en inrichting ten opzichte van de traditionele manier van softwareontwikkeling (vaak aangeduid met de term waterval- of V-modelmethode), wil een organisatie écht van de in de inleiding genoemde voordelen kunnen profiteren.

Een eerste uitdaging die we vaak terugzien binnen organisaties is door wie agile binnen de organisatie wordt gedragen. Vaak zien we in de praktijk dat de invoering van een agile manier van werken enkel en alleen wordt gedreven vanuit de IT-organisatie, die wel de noodzaak ziet om de manier waarop software wordt ontwikkeld te veranderen, maar de rest van de organisatie niet voldoende meekrijgt om echt agile te kunnen werken. In dat geval is er dan eigenlijk hooguit sprake van een ‘lokale optimalisatie’, zonder dat het hoofddoel wordt bereikt. In sommige gevallen kan dit zelfs op een dusdanige teleurstelling uitlopen dat het gevoel overheerst terug bij af te zijn. Organisaties komen er dan vaak te laat achter dat de adoptie van agile uiteindelijk niet zozeer een operationeel vraagstuk is, maar juist veel meer strategisch van aard en niet alleen tot de IT-afdeling behoort. Agile softwareontwikkeling is geen doel op zichzelf, het is immers volgens het Agile Manifesto ([AM01]) de business value die de belangrijkste driver zou moeten zijn. Het is hier dan ook de business die in de driver’s seat moet plaatsnemen. Ondanks het feit dat de teams grotendeels zelfsturend zijn en daardoor bottom-up worden gedreven, dient de strategische sturing wel degelijk vanuit de businessdoelstelling te komen. Agile als prominent onderwerp op de agenda van de IT-directeur is daarom onvoldoende.

Vraagstukken op strategisch niveau zijn uiteraard nauw verwant met de missie en doelstellingen van de organisatie en geven richting aan de agile implementatie. De kernvraag daarbij is wat business value in dat opzicht voor een organisatie inhoudt. Is een snel veranderende markt en daarmee een kortere time-to-market een belangrijk aspect? Of is het doel meer intern gericht en zijn het de efficiencywinsten die de business value bepalen? Ook kan bijvoorbeeld sneller innoveren een belangrijke drijfveer zijn om agile te willen werken.

Naast strategische aspecten zijn het veelal de operationele uitdagingen waarmee organisaties worstelen. Hier is een goede begeleiding van de teams belangrijk. Om kortcyclisch en in nauw verband met elkaar te kunnen samenwerken zal een organisatie vaak anders moeten worden ingericht. Dit is echt een organisatievraagstuk: is er sprake van een omgeving waarin de teams optimaal kunnen presteren en die aansluit bij de beoogde doelstellingen? Dit gaat vaak over de beschikbaarheid van informatie, tools, medewerkers en sturing. Zoals duidelijk moge zijn, moet een oplossing voor deze vraagstukken gezocht worden binnen de keten van het voortbrengingsproces; van het opstellen van de eerste requirements tot het succesvol in productie brengen van een feature. De wijze waarop de organisatie dit proces heeft ingericht is namelijk bij een agile werkwijze bepalend voor de vraag of het behalen van de businessdoelstellingen sowieso binnen bereik komt.

Daarnaast zijn er ook binnen de ontwikkelteams zelf verbeterpunten aan te wijzen. Aangezien vrijwel iedere agile werkwijze dun is aan de methodekant, lijkt implementeren gemakkelijk. In de praktijk blijkt echter dat agile werken vaak een ‘mindshift’ van zowel ontwikkelaar als product owner vereist. Niet zelden moet van oude ‘gebruiken’ worden overgestapt op een nieuwe, andere manier van werken. Onlosmakelijk verbonden met de ontwikkelteams is de kwaliteit van hetgeen wordt opgeleverd en de manier waarop dit gebeurt. De inzet van voldoende technische hulpmiddelen en tools is een voorwaarde om steeds snel (binnen twee tot vier weken) te kunnen opleveren.

Hier een top tien van veelvoorkomende uitdagingen die we in de praktijk voorbij zien komen:

• Het management is niet faciliterend, maar sturend. Bij het nemen van beslissingen wordt er nog te veel gestuurd vanuit het (project)management in plaats van dit over te laten aan de teams zelf.
• De product owner wordt verkeerd geselecteerd of heeft niet genoeg mandaat gekregen om zelfstandig beslissingen te kunnen nemen. Hierdoor is er onvoldoende daadkracht of moeten beslissingen later worden herzien.
• Er wordt onvoldoende tijd ingeruimd voor de product owner, waardoor deze maar slechts beperkt beschikbaar is voor het beantwoorden van vragen uit een team. Dit gaat ten koste van zowel de kwaliteit van het opgeleverde product als de efficiëntie van het team.
• Teamleden zelf worden onvoldoende beschikbaar gemaakt om te werken binnen een team. Er lopen vaak meerdere projecten tegelijk, waardoor er geen sprake is van een vaste teamsamenstelling. Hierdoor heeft het team moeite om continu te verbeteren.
• Binnen de sprints wordt nog te veel met miniwatervalletjes gewerkt. Indicatoren hiervoor zijn bijvoorbeeld dat bepaalde taken, bijvoorbeeld het testen, niet altijd af zijn aan het einde van een sprint. Taken worden onvoldoende ‘klein’ gemaakt, waardoor het uitvoeren van de taak langer dan een sprint duurt. Daarnaast wordt er te weinig aandacht besteed aan het automatiseren van taken (bijvoorbeeld regressietesten), waardoor het op lange termijn steeds lastiger wordt om de velocity te kunnen waarmaken.
• De release is klaar, maar door het onvoldoende betrekken van bijvoorbeeld de beheerorganisatie kan deze niet direct in productie worden genomen. Hier zijn vaak vele redenen voor te bedenken, bijvoorbeeld dat de beheerorganisatie vooraf nog niet is betrokken of niet in de methodewijziging meegaat. Hieruit blijkt vaak dat de organisatie als geheel nog niet goed is ingericht om agile te werken.
• Er wordt onvoldoende aandacht besteed aan het opstellen en zich houden aan de Definition of Done, waardoor later alsnog discussie ontstaat over hetgeen wordt opgeleverd door de teams (bijvoorbeeld het ontbreken van documentatie). Daarnaast wordt de Definition of Done niet met de betrokken partijen afgestemd, waardoor later alsnog herstelwerkzaamheden gedaan moeten worden (het is niet echt af).
• De teams meten te weinig. Niet alleen wordt er slecht omgegaan met de velocity, ook wordt weinig tot geen aandacht besteed aan andere metrics (bijvoorbeeld burndowns, kwaliteitskengetallen, aantal defects et cetera), waardoor algehele transparantie ontbreekt.
• Er worden geen goede afspraken gemaakt over beheerissues en kritische incidenten die eventueel met voorrang tijdens de lopende sprint moeten worden opgelost. Hierdoor werken deze verstorend en kan het team niet optimaal presteren.
• Een agile manier van werken staat of valt daarnaast met het proces van voortdurende verbetering (het proces volgens ‘inspect and adapt’, ook wel bekend als de kwaliteitscyclus van Deming). Continue aandacht voor dit proces is erg belangrijk. In de praktijk zie je dit proces, zeker na een groot aantal sprints, nog wel eens verslappen.

Om te kunnen beoordelen in hoeverre een organisatie geslaagd is in de adoptie van een agile ontwikkelproces en om te bepalen wat de mate van volwassenheid is van deze implementatie, heeft KPMG een assessment framework ontwikkeld. Dit framework toetst op verschillende dimensies in hoeverre de mate van agile adoptie is geslaagd in relatie tot de bedrijfsdoelstellingen.

Welke voordelen biedt een agile assessment?

Het uitvoeren van een agile assessment moet in onze visie bijdragen aan het overwinnen van de uitdagingen waarmee een organisatie te maken krijgt. Deze uitdagingen zijn per organisatie verschillend en zijn afhankelijk van vele factoren. Het bepalen van deze factoren moet dus een integraal onderdeel zijn van de aanpak, net als het bepalen van de algehele doelstelling van de assessment: wat zijn de primaire redenen voor het opstarten ervan? Bij de uitdagingen hebben we al een aantal van deze voorbeelden beschreven.

Vooropgesteld moet worden dat het doel van de assessment geen ‘audit’ is waarbij wordt beoordeeld op ‘goed’ en ‘fout’. Het is met name de bedoeling om inzichtelijk te maken welke principes worden toegepast, wat de volwassenheid is van deze principes en in welke mate de organisatie daarmee in staat is om effectief te werken.

Een van de belangrijkste uitgangspunten bij een agile assessment is dat er rekening moet worden gehouden met de fase van volwassenheid waarin de implementatie zich bevindt. Het is niet realistisch om een implementatie te beoordelen op het hoogste volwassenheidsniveau als de organisatie daar nog niet naartoe is gegroeid. Bij het bepalen van de mate van volwassenheid gebruiken we meestal het in figuur 1 weergegeven, vrij op CMMI gebaseerde, model.

Figuur 1. Model voor de mate van agile volwassenheid. [Klik op de afbeelding voor een grotere afbeelding]

Een integraal onderdeel van de assessment is het concreet aanwijzen van verbeterpunten, zodat het niet blijft bij bevindingen alleen. Het is enerzijds van belang om die gebieden te identificeren waar de organisatie als geheel zich kan verbeteren, maar anderzijds ook om te kijken waardoor de individuele teams beter kunnen gaan presteren.

Waar coaches een goed middel zijn om de daadwerkelijke implementatie binnen de teams te bewerkstelligen, is een assessment meer bedoeld om met een onafhankelijke blik en met iets meer afstand naar de implementatie te kijken en ook de strategische vraagstukken daarbij te betrekken.

De methode die KPMG hiervoor gebruikt, is met name hierop gericht en wordt in de volgende paragrafen verder toegelicht.

Methode

De in dit artikel gepresenteerde methode voor een agile assessment geeft niet alleen inzicht, maar levert tevens duidelijke verbetervoorstellen op. Een organisatie kan op basis hiervan zelf beslissen welke verbeteringen worden doorgevoerd en op welke termijn. Omdat het Agile Manifesto als basis is genomen, is de assessment toepasbaar op iedere agile methode (XP, Scrum et cetera), ook wanneer binnen een organisatie verschillende methoden door elkaar worden gebruikt. Daarnaast is deze aanpak schaalbaar (van één team tot grotere programma’s).

Inzicht over drie assen

De methode geeft de organisatie inzicht over drie assen/dimensies/stromen:

• organisatie & processen;
• tools & technieken;
• cultuur & gedrag.

Organisatie & processen

Bij het onderzoeken van de organisatie en de processen wordt allereerst goed gekeken naar de plaats van de afdeling, het programma of het project in de organisatie. Hierbij wordt tevens gekeken hoe dit past binnen het portfoliomanagement van de organisatie en hoe dit rijmt met de agile werkwijze die wordt gebruikt. Een essentieel onderdeel hierbij is ook hoe de ontwikkelteams samenwerken met andere stakeholders (product owner, ondersteunende afdelingen et cetera) en of hier verschillen en/of overeenkomsten tussen de teams zijn aan te wijzen.

Thema’s die aan deze stroom gerelateerd zijn:

• betrokkenheid van de business, de rol van de product owner en andere stakeholders;
• inrichting van de organisatie, de teams en de manieren van samenwerken;
• inrichting van de processen (architectuur, ontwerp, ontwikkeling, testen, releases, planning, beheer et cetera), ook in relatie tot de organisatie.

Ook besteden we in deze stroom aandacht aan de rol van innovatie & architectuur en aan manieren om vroeg betrokken te raken bij vernieuwingen vanuit de business en om de time-to-market te verkorten.

Tools & technieken

In deze stroom kijken wij naar de tools en technieken die worden gebruikt om het agile werken te ondersteunen. Het gaat hier om zowel fysieke (ruimte, Scrum-board, pokerkaarten) als softwarematige tools (inrichting ontwikkelstraat, mate van procesautomatisering, dashboards, verzamelen van metrieken, testtools et cetera).

In deze stroom wordt zo onder meer onderzoek gedaan naar:

• de technieken die de teams gebruiken in het afstemmingsproces (manier van plannen, gebruikte tooling et cetera);
• de transparantie waarmee gegevens over het proces en de geleverde kwaliteit beschikbaar zijn;
• de (onafhankelijke) wijze waarop metrieken worden bepaald;
• mogelijkheden voor verdere automatisering van het proces en ondersteuning van de ontwikkelaars.

Cultuur & gedrag

Het invoeren van een agile proces is niet alleen het opzetten van een nieuw proces, nieuwe teams en nieuwe rollen. Het is ook het invoeren van een nieuwe manier van denken, waarbij wijzigingen worden omarmd, waarbij teams zelfsturend zijn, waarbij moet worden gewerkt op basis van richting en ruimte. Dit betekent in veel gevallen een verandering van gedrag en cultuur. In deze stroom gaat de aandacht uit naar bewustwording, openheid en transparantie en het geven van richting en ruimte.

In deze stroom wordt onderzoek gedaan naar:

• hoe het team omgaat met veranderende prioriteiten;
• of er open wordt gecommuniceerd;
• de mate van zelfsturing binnen de teams;
• hoe de sfeer in het team is en hoe het team omgaat met het oplossen van problemen (impediments);
• of de status en het product voor alle betrokkenen inzichtelijk zijn;
• hoe evaluaties (retrospectives) zijn ingericht en hoe het team omgaat met continue verbetering.

Assessment is gebaseerd op de agile principes

Omdat agile processen per definitie empirisch van aard zijn, wordt niet gekeken naar de mate waarin een bepaald proces is geïmplementeerd, maar naar de mate waarin wordt voldaan aan een aantal agile principes. Deze manier van toetsen maakt het mogelijk dat verschillende implementaties met elkaar kunnen worden vergeleken en biedt een praktisch handvat voor het daadwerkelijk verbeteren van een geïmplementeerd proces in de context van de betreffende organisatie.

In figuur 2 wordt een voorbeeld gegeven van de onderzoeksvragen gebaseerd op deze principes.

Figuur 2. Voorbeeld van onderzoeksvragen gebaseerd op agile principes ([AM01]).

Figuur 2 (vervolg). Voorbeeld van onderzoeksvragen gebaseerd op agile principes ([AM01]). [Klik op de afbeelding voor een grotere afbeelding]

Aanpak

De aanpak is erop gericht om in een korte tijd een analyse van de situatie uit te voeren om zo het verbeterpotentieel in kaart te brengen. Hierbij wordt onderscheid gemaakt tussen quick wins en verbeteringen die op een langere termijn te behalen zijn.

Figuur 3. De fasen van de KPMG agile assessment.

Voorbereiding

In de voorbereidingsfase ligt de nadruk op het bepalen van de scope en doelstelling van het onderzoek en het verkrijgen van inzicht in de organisatie en de omgeving. Aangezien iedere organisatie anders is ingericht, is onze ervaring dat in de voorbereidende fase veel afstemming nodig is tussen de onderzoekers en de opdrachtgever, wil deze laatste het maximale kunnen halen uit het onderzoek. In de voorbereidende fase moet de juiste focus worden aangebracht, zoals het bepalen van de belangrijkste onderzoeksgebieden en eventuele aandachtspunten. In gezamenlijk overleg moeten de onderzoeksdoelstellingen worden bepaald, zodat de organisatie later zelf in staat is de eventuele verbeterpunten zelfstandig op te pakken.

Onderzoek

Tijdens het onderzoek ligt de voornaamste focus op het verzamelen en analyseren van informatie. Op basis van de in de voorbereidingsfase gestelde doelen wordt de ‘diepte’ van het onderzoek bepaald. In principe wordt er altijd informatie verzameld door gebruik te maken van onder andere deze instrumenten:

• Interviews of workshops met een representatieve doorsnede van de organisatie. Denk hierbij bijvoorbeeld aan het (hogere) management, de business en de product owner(s), de verantwoordelijke projectmanager(s), teamleden (waaronder de Scrum-master), een verantwoordelijke vanuit de beheerorganisatie en eventueel andere relevante betrokkenen. Het doel van deze interviews is om een goed beeld te krijgen van de processen, maar ook om vragen te stellen over de cultuur en het gedrag.
• Vragenlijsten die (eventueel anoniem) kunnen worden ingevuld door teamleden. Deze vragenlijsten zijn ondersteunend aan de interviews en zorgen ervoor dat eventuele onderwerpen die niet in de interviews naar voren zijn gekomen worden afgedekt.
• Onderzoek van documenten of andere relevante artefacten binnen het (ontwikkel)proces (op basis van een quickscan). Voorbeelden zijn: bedrijfsplannen (strategie), design- en architectuurdocumentatie, releaseplannen, product backlogs, sprint backlogs, documentatie (ontwerpdocumenten, technische documentatie, deploymentdocumentatie, testscripts), team- en managementrapportages (burndowns, dashboard, metrieken et cetera).
• Inventarisatie van het gebruik van technische hulpmiddelen in het ontwikkelproces: welke ondersteunende tooling wordt er gebruikt voor ontwerp, ontwikkeling, testen en procesondersteuning?
• (Optioneel) onderzoek van de softwarecode. Door de softwarecode te analyseren kunnen we problemen in de kwaliteit beter zichtbaar maken.

Validatie

Tijdens de validatie worden de verschillende bevindingen geverifieerd en in samenhang bestudeerd en wordt de volwassenheid op ieder principe beoordeeld. Daarnaast worden hieraan verbetermogelijkheden gekoppeld. De gevonden issues en verbetermogelijkheden worden besproken met de opdrachtgever (inclusief eventuele andere verantwoordelijke personen), waarbij de opdrachtgever zijn reflectie op het onderzoek kan geven. Naar aanleiding van de bespreking worden de verbetermogelijkheden verder uitgewerkt en wordt de conceptrapportage opgesteld.

Rapportage

In de eindfase van de opdracht worden de conceptrapportage en de aanbevelingen met de opdrachtgever besproken en wordt de rapportage afgerond. Eventueel is het mogelijk om op basis van de definitieve rapportage met een aantal sleutelpersonen binnen de organisatie een challengesessie te organiseren waarin op basis van de aanbevelingen een eerste stap kan worden gezet om te bespreken hoe deze kunnen worden geïmplementeerd.

Resultaten

Als we kijken naar de resultaten van de assessments die we hebben uitgevoerd, zien we de genoemde uitdagingen in meerdere of mindere mate terugkomen. Dit is mede afhankelijk van het stadium van volwassenheid waarin de implementatie zich bevindt. De meeste organisaties blijven steken bij het derde stadium van volwassenheid. Slechts een enkele keer wordt het vierde of vijfde stadium bereikt. Daar ligt een kans voor veel organisaties om naar het volgende stadium toe te groeien.

Ongeacht het stadium van volwassenheid worstelen veel organisaties nog met een aantal fundamentele waarden uit het Agile Manifesto. Voorbeelden zijn:

• Het mandaat van de product owner is in veel gevallen nog verkeerd belegd.
• Er wordt nog te weinig vertrouwd op zelfsturing van de teams.
• Voldoende zichtbaarheid naar alle lagen van de organisatie ontbreekt.
• In de oplevering (demo) van een sprint wordt vaak software getoond die niet is ‘afgemaakt’ – wat mogelijk (deels) wordt veroorzaakt door het feit dat taken niet voldoende klein zijn gemaakt. Het gevolg is wel dat hierdoor onduidelijkheid blijft bestaan over de daadwerkelijke status en voortgang van het project.
• Er wordt nog te weinig gebruikgemaakt van de technische mogelijkheden die er zijn om effectiever te werken en de kwaliteit te verhogen, zoals geautomatiseerd testen en continuous integration.

In agile assessment worden niet alleen de negatieve bevindingen genoemd. We zien bij jonge implementaties van agile ook vaak positieve punten waardoor al snel voordelen van de nieuwe werkwijze behaald worden. Hier kan door te kijken naar het volgende volwassenheidsniveau de continue verbetercyclus worden ingezet.

Conclusie

De afgelopen tien jaar heeft een massale adoptie van een agile werkwijze binnen organisaties plaatsgevonden en is de volwassenheid van de implementaties toegenomen. Echter, het continue spel van inspectie en adoptie blijft belangrijk om het rendement van agile te behouden of te vergroten. Het is daarom belangrijk om hier continu aandacht aan te blijven besteden.

De hier beschreven assessmentmethode is toepasbaar op alle agile methoden, zoals Scrum, XP en Kanban. Met een relatief beperkte inspanning wordt met deze methode objectief vastgesteld hoe goed de processen functioneren. Gezien de opname van ‘continuous improvement’ in de agile principes behoeft het geen verbazing te wekken dat deze assessments vaak veel verbetervoorstellen opleveren. Hier maken de teams dan ook vaak goed gebruik van.

Bovenal tonen deze assessments vooral aan dat organisaties de agile principes serieus en goed willen toepassen. Het is dan ook goed om vast te stellen dat met de tijd organisaties op een steeds hoger agile maturity level gaan functioneren. Deze organisaties slagen er daarmee in daadwerkelijk en aantoonbaar business value te realiseren met softwareontwikkeling!