Agile: oude wijn in nieuwe zakken?

De vertaling van het Friese spreekwoord "Men docht gjin âlde wyn yn nije sekken", een verbastering vanuit Mattheus 9:17, wordt regelmatig gebruikt in discussies over de waarden en principes van Agile. De stelling wordt ingenomen dat Agile slechts een nieuwe hype is van principes die lang geleden al zijn ontstaan met veelal de ondertoon dat deze de tand des tijds niet hebben doorstaan.

Voorbeelden hiervan zijn Project Mercury uit 1958, waarin Gerhard Weinberg het incrementeel en iteratief ontwikkelen al toepaste met iteraties van een half dag op basis van test driven development. Harlan Mills, software engineering thoughtleader bij de IBM Federal Systems Division, die in 1968 tegen de waterval stroming in feedback-driven refinement met direct klantbetrokkenheid introduceerde. Of Frederick Brooks, de Turing award winner, die met zijn boek 'The mythical man-month' uit 1975 niet alleen aantoonde dat het toevoegen van mankracht aan een achterlopend softwareproject dit project alleen maar verder vertraagt, maar ook de kracht aantoonde van kleine onafhankelijke teams middels zijn Group intercommunication formula.

Wanneer gekeken wordt naar de oorsprong van de Agile principes valt direct op dat de Agile principes ver voor de 21e eeuw al bekend waren, waarbij velen voortkomen uit publicaties in de jaren '60 en '70. Het is dus een feit dat Agile een 'oude wijn in een nieuwe zak' is; waarom werken de Agile principes vandaag de dag wel en niet in de tijd waarin ze afkomstig waren?

Fundamentele verandering gaat langzaam

Het omarmen van het Agile gedachtegoed is een serieuze, fundamentele verandering voor een software development organisatie. Één van de meest eenvoudige Agile frameworks, Scrum, benoemd dit feit al op pagina 3 van haar Scrumgids: "Scrum is: 1) lichtgewicht, 2) simpel om te begrijpen en 3) extreem moeilijk om te leren beheersen". Als één van de meest eenvoudige frameworks de moeilijkheidsgraad van Agile al aangeeft, wat betekent dit dan voor de complexere principes die niet door het framework worden gedekt.

Fundamentele verandering gaat langzaam. Kijk maar naar de ontwikkelingen op het gebied van leiderschap. De transitie van scientific management (1890 – 1940) naar faciliterend en inspirerend management (1995 – heden) heeft ongeveer een eeuw nodig gehad voor deze echt voeten aan de grond kreeg. Ook binnen Agile is deze langzame verandering zichtbaar. Al voor het ontstaan van het Agile manifesto was er een steeds sterkere stroming zichtbaar die zich distantieerde van gestructureerde software ontwikkeling. De samenkomst van de verschillende voorstanders van deze stroming is niets anders dan de druppel die de Agile emmer deed overlopen.

De Agile principes werken in samenhang

Ondanks de verschillende publicaties en aanbevelingen vanuit de onderliggende losse Agile principes, is een groot deel van het succes van Agile te vinden in de samenwerking van deze principes. Dit feit wordt regelmatig ondersteunt door de voorbeelden waarin slechts een aantal Agile principes worden toegepast, en de resultaten tegen vallen of zelfs desastreus zijn.

Één van de meest bekende voorbeelden hiervan is het principe 'Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.' Wanneer dit principe niet strak wordt gehanteerd wordt de deur opgezet voor een enorme toename van technische schuld of het opbranden van het team door continue druk vanuit het management. Daar waar traditioneel ontwikkelde systemen jaren van (slecht) beheer nodig hebben om tot spaghetticode te vervallen, is dit – wanneer het genoemde principe slecht wordt toegepast – binnen Agile al in een aantal malen te bereiken.

Het is daarom essentieel dat de Agile principes niet los van elkaar worden gezien. Sterk iteratief werken zonder sterke samenwerking met de business heeft nauwelijks voordelen, maar brengt wel risico's met zich mee. Of de situatie die een collega aanhaalde, een continu verbeterend ontwikkelteam zonder directe feedback vanuit de klant gaat heel efficiënt de verkeerde kant uit. Effectiviteit bereik je pas als de business en ontwikkelaars nauw samen werken om de klant tevreden te stellen.

De Agile principes zijn niet alleen voor ontwikkelaars

Vrijwel de meeste oorspronkelijke ideeën achter de Agile principes stammen af uit de vroege dagen van software ontwikkelaars. Een groep ingenieurs die apart gehouden werden van de rest van het bedrijf, nerds en geeks. Het kan toch niet zo zijn dat die principes bedenken die impact hebben op de rest van het bedrijf?

Ondanks dat het valide principes en voorstellen waren hadden deze nauwelijks impact op de rest van het bedrijf. De technisch georiënteerde medewerkers waren zeker geen managers, en de invloed van hun principes kwam nauwelijks buiten hun groep. De integratie van software ontwikkeling in de rest van het bedrijf is pas gekomen met het steeds grotere belang van ICT ter ondersteuning van de bedrijfsprocessen. En zo werd ook de invloed van deze groep groter, en ontstond ruimte voor continu verbeterende samenwerking waarbij principes niet slechts meer door een beperkte groep werden erkent.

Vandaag de dag wordt vrijwel iedereen in het bedrijfsleven geraakt door de invloed van het Agile gedachtegoed. Projectmanagers gaan meer de omgeving management dan hun zelf organiserende teams, architecten klimmen uit hun ivoren toren om de teams te begeleiden in plaats van te controleren en de business neemt verantwoordelijkheid voor de informatiesystemen die zij nodig hebben.

Agile wordt niet langer alleen binnen de software ontwikkelingsafdeling toegepast. In trainingen komen we regelmatig mensen tegen vanuit marketing (Agile ontwikkeling van marketing campagnes), beleidsmedewerkers (Agile ontwikkeling van wetgeving en strategie) en HRM (Agile managen van HR-vraagstukken). Kortom, Agile is niet slechts voorbehouden aan ontwikkelaars, maar wordt de laatste jaren bedrijfsbreed toegepast.

De Agile principes worden ondersteunt door best practices

Een principe is natuurlijk prachtig, maar de vraag rijst al snel 'Hoe moeten we deze toepassen'? Frederick Brooks heeft uitvoerig onderzocht dat de enorme software ontwikkelteams waar IBM mee werkte, enorme beperkingen en productiviteitsverlies kende door de complexiteit van communicatie in het project. Grote projecten met sterke onderlinge afhankelijkheden vereisten uitvoerige processen en procedures om als geheel te kunnen samenwerken. Het principe dat daar uit volgde was het werken in kleine, onafhankelijke teams. Maar het duurde pas tot ver na het jaar 2000 voordat daar best practices in de vorm van geschaalde Agile frameworks voor ontstonden. Dus zelfs wanneer je overtuigt was van het principe was het inderdaad enorm complex en risicovol om daar een juiste uitvoeringsmethode voor te vinden.

Sinds het ontstaan van Agile en de bundeling van de principes zijn enorm veel experimenten uitgevoerd waarbij best practices zijn ontstaan voor het daadwerkelijk toepassen van Agile. Sommige zijn gebundeld in frameworks als SAFe, LeSS en Scrum, anderen worden individueel toegepast om niet voorgeschreven aspecten in een framework op te vullen. Denk hierbij aan best practices als Test Driven Development, het gebruik van user stories, het relatief schatten van de omvang en continuous integration.

Het selecteren van bestaande best practices of het uitvoeren van experimenten voor uitdagingen zonder een best practice, is één van de redenen waarom Agile vandaag de dag met steeds meer succes wordt toegepast. Het onderscheid daarin ook de teams die het matig doen van de teams die Agile op hoog niveau uitvoeren. Het bewust aanleren en integreren van best practices is daarmee van essentieel belang voor langdurig succes binnen het Agile werken.

De Agile principes worden écht toegepast

Het toepassen van de oorspronkelijke principes vereiste grote inspanning. Veel van de principes gingen in tegen de geldende visie op het gebied van software engineering. Daarvan afwijken was, ondanks de validiteit van het principe, alsof je tegen de stroom in moest roeien. Ondanks het feit dat op verschillende plekken met de principes werd geëxperimenteerd, werd het principe vaak slechts half uitgevoerd of deels aangepast om het passend te krijgen in het huidige methodiek van software ontwikkeling.

Het half uitvoeren leidde vaak tot tegenvallende resultaten, waardoor al snel de conclusie werd getrokken dat het een leuke gedachte was, maar niet gaat werken. En na enkele experimenten viel men terug op het systeem waar al jaren ervaring mee op is gedaan. Hetzelfde principe zie je vandaag de dag nog steeds terug wanneer Agile teams binnen een project wordt uitgevoerd. De Agile principes worden beperkt daar waar het de kaders van het project raakt. Wanneer het project, door wat voor reden dan ook, onder druk komt te staan, grijpt het projectmanagement terug naar de – voor hun – bewezen principes en wordt de toepassing van Agile versterkt.

Aangezien ook steeds meer (nieuwe) projectmanagers ervaring op doen met Agile zie je dat steeds meer ruimte ontstaat om de principes echt toe te passen. Iedereen vindt zijn nieuwe rol en daardoor komt het effect van Agile echt tot zijn recht. In die situaties hoor je de mensen dan ook vaak zeggen: "Nu snap ik het, ik zou niet meer terug willen naar de traditionele manier van het leiden van projecten". En naarmate meer en meer Agile principes écht worden toegepast, wordt ook steeds meer duidelijk wat de kracht van Agile is.

En voor mijzelf, ondanks het feit dat ik pragmatisch ben in de route naar het Agile werken, geloof in sterk in de Agile principes. Het goed begrijpen is essentieel om de resultaten die Agile belooft ook daadwerkelijk te bereiken. De principes, ook al zijn ze oud, hebben een ongelofelijk effect op wat teams kunnen bereiken. Mijn stelling is daarom:

Oude wijn kun je alleen maar in nieuwe zakken doen als je de wijn nooit hebt opgedronken.


Historische referenties naar de roots van Agile principes. Meer informatie over de history van de Agile waarden en principes zijn te vinden in het artikel 'Historical Roots of Agile Methods: Where did 'Agile Thinking' Come from?'.

  • Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software. [1985, Gilb]
  • Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces.
  • Agile processen benutten verandering tot concurrentievoordeel van de klant. [1981, Boehm]
  • Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden. [1958, Gerhard Weinberg]
  • Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project. [1999, Beck]
  • Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren. [1985, Weinberg]
  • De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten. [1994, Crowley]
  • Werkende software is de belangrijkste maat voor voortgang. [1985, Gilb] [1991, Martin]
  • Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden. [1999, Yourdon]
  • Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility. [1972, Dijkstra]
  • Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel. [1975, Dijkstra]
  • De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams. [1968 – 1969, Harlan Mills] en [1950, Tata en Prasad]
  • Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan. [1800, National Cash Register's program] en [1940, Training Within Industry]
DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • Wat Agile teams kunnen leren van de American Football World Champions

    Marco de Jong ziet 10 belangrijke lessen voor Agile teams in de successen van zijn favoriete Football team.

    Lees verder
  • Lean kan niet mean zijn

    Laat ik meteen met de deur in huis vallen: Lean gaat niet samen met mean. Punt.

    Lees verder
  • Het effectief meten van Agile teams (deel 1)

    Als het gaat om het inzichtelijk maken van de volwassenheid van Agile teams, zitten Agile coaches veelal tussen twee vuren ingesloten. Aan de ene kant hebben zij "de organisatie" die graag wil weten hoe hun Agile teams het doen en aan de andere kant "de Agile teams" die zelf verantwoordelijk zouden moeten zijn voor hun continue verbetering.


    Lees verder
  • Stop de excuuscultuur!

    Het is 10.13 uur als de laatste deelnemer aan de meeting binnen komt lopen, 13 minuten later dan de bedoeling was. Met een net getapte geurende koffie in zijn ene hand en een stapel papieren in zijn andere hand schuift hij aan tafel. Terwijl de voorzitter verder wil gaan met zijn punt, komt de volgende opmerking over tafel: "Ja, sorry dat ik te laat was, ik moest nog even bellen."

    Lees verder
  • Mind over Matter

    Een transitie naar agile begint vaak met het opleiden van mensen in de rollen, gebeurtenissen en producten vanuit een agile framework. Na de initiële opleiding worden onderling afspraken gemaakt, hulpmiddelen uitgerold en gaan de teams vol energie aan de slag.

    Lees verder
  • De kracht van visuele feedback

    Visuele feedback (of visual management) is één van de meest zichtbare onderdelen binnen organisaties en wordt binnen een Lean omgeving meestal als één van de eerste onderdelen ingericht.

    Lees verder
  • De noodzaak van een lerende organisatie

    Hoe beter je als organisatie kunt leren, hoe effectiever je in staat bent om te plannen. Het lerend vermogen van jouw organisatie staat gelijk aan de wendbaarheid van jouw organisatie. In deze serie van blogs kijken we daarom naar de essentiële aspecten van het creëren van een wendbare, lerende organisatie.

    Lees verder
  • Back to Basics

    In deze blogpost kijken we naar de complexiteit van het toevoegen van Inspect & Adapt binnen bestaande organisaties en gaan we daarom terug naar de absolute basis van een lerende organisatie.

    Lees verder