Agile Manifesto: een aansporing om anders te kijken

Het Agile Manifesto stamt uit 2001 en nu al zijn er miljoenen organisaties door veranderd. Hoe kan een dergelijk stuk zoveel impact hebben en wat betekent dit voor de auditwereld? Uitgaan van de klantwens en iteratief ontwikkelen betekent natuurlijk dat ook audit en controle van de achterkant van het proces meebewegen naar de voorkant. Het Manifesto toepassen helpt daarbij.

Pas geleden had ik als agile-coach een gesprek met een risk officer van de bank waar wij beiden werken. Ik realiseerde mij tijdens dat gesprek hoe verschillend onze visie op samenwerken en waardecreatie was. Daar waar zij vooral opereerde in het paradigma van controle, test en bewijs aan het eind van het proces om de kwaliteit van het proces te waarborgen, ben ik er steeds meer van overtuigd dat kwaliteit bevorderd wordt door het vanaf het begin af goed te doen. Dat risicoreductie gebaat is bij veel experimenteren en kleine stapjes zetten. Immers, hoe kleiner de stap hoe gemakkelijker het is om terug te gaan zonder veel gevolgen. Heb je wel eens geprobeerd een trap op te lopen door vier treden tegelijk te nemen? Het niet halen van zo’n stap heeft veel meer gevolgen, je valt gewoon makkelijker om, je bent instabieler.

Fouten maken mag en ‘shift left’

Kleine stappen zetten betekent ook dat fouten maken mag en ervan doordrongen zijn dat je met kleine stappen op de langere termijn een beter resultaat haalt. Maar ‘fouten maken’ moet wel ‘mogen’. De aandacht voor kwaliteit en de borging ervan zit dan niet meer in controle achteraf maar in het vanaf het begin goed doen. Door direct in te zien dat het niet goed is, zet je gemakkelijk een stap terug en is de kans op een goed eindresultaat groter.

Deze ‘shift-left’gedachte (je verschuift de aandacht naar het begin van het proces; meestal van links naar rechts getekend in de stroomschema’s) is een van de gevolgen van het doorvoeren van de agile-principes. En omdat principes altijd de drijvende kracht zijn achter belangrijke stromingen en cultuurveranderingen is het de moeite waard om de principes van agile eens verder te bestuderen.

Het Agile Manifesto

Het Agile Manifesto is opgesteld door zeventien softwarespecialisten in Amerika en is tot op de dag van vandaag het uitgangspunt van het agile-gedachtegoed. Hoewel er sinds die tijd natuurlijk denkers zijn geweest die er verder over hebben nagedacht en werkers zijn geweest die nieuwe vormen van werken hebben toegepast, is het nog steeds een krachtig instrument om de agile-boodschap over te brengen.

Het Agile Manifesto is opgesteld door zeventien softwarespecialisten in Amerika en is tot op de dag van vandaag het uitgangspunt van het agile-gedachtegoed

De vraag blijft dan natuurlijk wel hoe je die vier uitgangspunten en twaalf principes van het Manifesto kunt verbinden met de shift-leftgedachte? En waarom is dat beter dan de oorspronkelijke manier van nakijken en testen achteraf? Om op die vraag een antwoord te geven moeten we het Manifesto eerst goed bekijken. Daarna zal blijken of het Manifesto daadwerkelijk in staat is om ook bij complexe materie als risicoanalyses en kwaliteitsborging gebruikt kan worden.

Vier uitgangspunten

Het Manifesto begint met vier uitgangspunten:

1. individu en interactie boven processen en gereedschappen;
2. werkend product boven nauwkeurige beschrijving;
3. samenwerken met de klant boven contractonderhande-lingen;
4. reageren op verandering boven vasthouden aan het plan.

Daar waar we in ieder uitgangspunt het tweede waarderen, waarderen we het eerstgenoemde meer. In feite wordt hier samengevat wat flexibiliteit betekent: individugericht samenwerken aan reële producten terwijl we reageren op veranderingen. Anders gezegd, je werkt als organisatie samen met de klant aan producten waar hij werkelijk iets aan heeft in een steeds wisselende context. Stephen Denning noemt agility in een van zijn boeken dan ook: ‘to outperform customer’s expectation’.

Twaalf principes

Vervolgens gaat het Manifesto verder met twaalf principes (zie kader). Iemand in mijn omgeving stelde eens dat als er ergens een probleem is, je door het lezen en toepassen van een of meer van die principes het probleem op kunt lossen. Op die manier bekeken is het dus een leidraad voor het oplossen van problemen. Je kunt de twaalf principes ook beschouwen als positieve adviezen: richt je werk in op een manier die coherent is aan de principes en het resultaat zal merkbaar beter zijn.

De 12 principes van het Agile Manifesto

1. Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.

2. Verwelkom veranderende behoeften, zelfs laat in het ontwikkelproces. Agile-processen benutten verandering tot concurrentievoordeel van de klant.

3. Lever regelmatig werkende software op. Het liefst iedere paar weken, hooguit iedere paar maanden.

4. Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.

5. Bouw projecten rond gemotiveerde individuen. Geef ze de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.

6. De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.

7. Werkende software is de belangrijkste maat voor voortgang.

8. Agile-processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.

9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.

10. Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.

11. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.

12. Op vaste tijden onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

Samenvattend kun je stellen dat principes  1,  2  en 3 de waardecreatie voor de klant centraal stellen. Voor de klant krijgt een product waarde als hij het snel kan gebruiken en snel kan (laten) verbeteren. Het hoeft niet helemaal door en door besproken en ‘af’ te zijn. Hoe sneller je alvast delen kunt gebruiken, hoe meer waarde het heeft.

De principes 4 , 5  en 6  zetten het individu centraal. Dagelijks samenwerken in vaste kleine autonome groepen waarbij een-op-eencommunicatie de norm is, wordt door de meeste mensen als prettig ervaren. Lencioni (onder meer auteur van De 5 frustraties van teamwork) stelt vast dat vertrouwen het belangrijkste bindmiddel is in een groep en hij stelt dat gebrek aan vertrouwen altijd tot verhoogde onkwetsbaarheid lijdt (‘ik vertrouw hem niet en dus stel ik mij onkwetsbaar op’). In grote groepen werken aan onderling vertrouwen is heel moeilijk. Vooral als er ook nog een sturende manager is.

Principe 7 stelt dat je niets hebt aan een auto waarvan een wiel ontbreekt (‘maar de rest is heel mooi, hoor!’). Op dat moment heb je meer aan een fiets. Dan kom je (wellicht koud en bezweet) tenminste nog ergens aan. Dit principe zegt, samen met principes 8 en 9, iets over het product en hoe wij aankijken tegen duurzame productontwikkeling. Net zomin als je iets hebt aan een auto met drie wielen, heb je niets aan een product waarvoor mensen moesten lijden om het te maken. Door constant aandacht te mogen besteden aan een goed ontwerp en technische hoogstandjes wordt werk leuker en worden resultaten beter.

In principes 10, 11 en 12 wordt een aantal werkwijzen voorgesteld die de nadruk leggen op leuker werk: doe vooral geen zinloze dingen, in een zelforganiserende groep is ruimte voor creativiteit en door reflectie, gericht op verbeteren, wordt iedereen daadwerkelijk beter.

Zo op het eerste gezicht lijken deze principes vrij logisch. Wat is hier nu zo vernieuwend aan? En waarom zijn ze zo belangrijk gebleken voor miljoenen bedrijven over de hele wereld?

Agile-principes veroorzaken een paradigmaverandering bij veel mensen. Een verandering van denken doordat opeens vanuit een ander blikveld wordt gekeken

Paradigmaverandering

In het boek The Phoenix Project (een novelle over de inzet en noodzaak van DevOps, een populaire agile-manier van werken) wordt een kwaliteitsbeambte opgevoerd die in het begin van het boek een waar schrikbewind voert. Hij is altijd overal tegen en heeft overal, onder het mom van kwaliteitscontrole, een (negatieve) mening over. Nadat de hoofdpersoon met een externe consultant (Amerikaanse businessboeken werken graag met een ‘guru’ als aangever van nieuwe ideeën) tot de slotsom is gekomen dat de DevOps-manier van werken de oplossing is voor hun oneindige achterstanden en problemen, krijgt de kwaliteitsman een zenuwinzinking van het feit dat kwaliteitscontroles worden verplaatst van het eind van het proces naar het begin. Tijdens een paar dagen afwezigheid komt hij echter tot inkeer en wordt hij een van de grootste voorstanders van deze manier van werken. Een wat wonderlijke plotverandering maar hiermee wordt goed aangegeven wat agile-principes doen: ze veroorzaken een paradigmaverandering bij veel mensen. Een verandering van denken doordat eigenlijk opeens vanuit een ander blikveld wordt gekeken.

Mijn eigen ‘Phoenix-projectmoment’

Mij overkwam hetzelfde toen ik moest nadenken over de functie van testen. Testen en examineren doen we aan het eind. Dat hoort zo. We doen dat om te ‘bewijzen’ dat de stof goed geleerd is en dat alles naar behoren functioneert. Maar wat is dat: ‘de stof goed geleerd’ of ‘naar behoren functioneren’? Welke norm wordt hier gehanteerd? Blijkbaar is er vooraf vastgesteld welke norm gehaald moet worden. Blijkbaar is vooraf vastgesteld wat ‘naar behoren functioneren is’. Om de analogie met een examen vast te houden, blijkbaar zijn de vragen en de gewenste antwoorden vooraf bekend. Als dat het geval is hoef je alleen nog maar de juiste antwoorden bij de vragen uit je hoofd te leren. Toegegeven, je hebt er misschien niet veel van begrepen (een andere norm!), maar je haalt je examen wel.

In mijn professionele carrière heb ik behoorlijk wat testen en examens afgelegd die voortkwamen uit die gedachte. Uit een vaste set van bijvoorbeeld 1000 vragen worden er 40 geselecteerd en – 35 goed gegeven antwoorden betekent: geslaagd. Geen wonder dat velen slagen voor dit soort examens, gewoon 1000 vragen stampen.

Testen is examineren

Met het testen van producten gaat het eigenlijk hetzelfde. Er wordt niet zomaar iets gevraagd van een computermodel. Of van een strijkijzer. De geteste functies relateren aan de gewenste functies. Is het strijkijzer heet genoeg of niet te heet? Er wordt niet getest of je er ook hondjes mee kunt verwarmen. Is het algoritme logisch als een dataserie als input wordt gegeven (in het begin van de artificiële intelligentie werd een computer de vraag gesteld wat te doen aan het probleem dat veel ongelukken gebeuren op de eerste en de laatste tree van een trap. Antwoord van de computer: eerste en laatste tree weghalen…)?

Incrementeel opbouwen binnen agile

In agile werken wordt veel waarde gehecht aan waardetoevoeging en samenwerking. De eerste iteratie moet meteen waardevol zijn. Bij een strijkijzer zou de eerste iteratie een glad oppervlak zijn waarmee gestreken kan worden. De test die daarbij hoort is vanaf dat moment al beschikbaar: kun je er mee over kleding glijden dat over een stevige ondergrond gedrapeerd is. Als dat niet het geval is heeft de test gefaald. Lukt het, dan kan verder gewerkt worden aan de volgende iteraties: warmte toevoegen door elektriciteit en warmte regelen. Ontwerp en vormgeving worden in alle iteraties meegenomen. Heeft de eerste iteratie nog nauwelijks een handvat nodig, in de tweede wordt het belangrijk (brandgevaar). De test of het strijkoppervlakte glad genoeg is, blijft hetzelfde gedurende het hele proces (in alle iteraties) gelijk.

In agile werken wordt veel waarde gehecht aan waardetoevoeging en samenwerking

In dit voorbeeld wordt al gebruikgemaakt van een aantal van de Manifesto-principes:

• Samenwerken met de klant (immers, je wilt weten met welke minimale waarde al kan worden gestreken, met andere woorden: waar wordt het strijkijzer voor gebruikt).
• Technisch vernuft kan een product verbeteren (wordt het strijken makkelijker als je warmte toevoegt en kan het ook zonder warmte).
• Geen zinloze dingen doen (geen tests opnieuw ontwerpen die al eerder nuttig zijn gebleken).

Agile volgens Denning

Volgens Stephen Denning in zijn boek The age of agile staat het agile-gedachtegoed voor drie wetten. En alle drie zijn ze herkenbaar in het Manifesto. De eerste agile-wet is de wet van samenwerken in kleine groepen. Toepasbaar in alle beroepen en nagenoeg in alle omstandigheden. De tweede is de wet van de consument. Bedrijven bestaan niet om geld te verdienen, bedrijven bestaan om de consument te plezieren, om waarde toe te voegen. De derde wet is de wet van het netwerk. Niemand en geen enkele organisatie staat alleen en dicteert. Overal zijn netwerken nodig. Duidelijk herkenbare en minder zichtbare. Door transparantie tussen organisaties en personen wordt samenwerking bevorderd en de klant gediend. Gediend in en met duurzaamheid.

Agile en audit

Als auditor en tester, controleur en coördinator doe je er dus goed aan om je te laten doordringen van de toegevoegde waarde van deze principes. Als wij meewerken aan het begin van het proces door aandacht te hebben voor de normen die aan het eind worden gesteld, hoeven we minder bij te sturen en is er minder verspilling en dus meer waarde. In duurzaamheid, in geld, in menselijk onderling vertrouwen. En dat doen we door het Agile Manifesto creatief en samenwerkend na te leven.