Agile: de oorsprong, principes en toepassing

Eind jaren negentig begonnen verschillende methodologieën voor softwareontwikkeling publieke aandacht te krijgen. Elke methodologie had een andere combinatie va oude en nieuwe ideeën, maar ze legden allemaal een nadruk op nauwe samenwerking tussen het ontwikkelingsteam en de stakeholders aan de businesskant en op frequente oplevering van waardevolle software. Ook draaide het in alle benaderingen om zelforganiserende teams. Begin 2001 is de term agile toegekend aan deze verzameling methodologieën toen zeventien softwareontwikkelaars bij elkaar waren gekomen in Snowbird, Utah, om hun ideeën en verschillende benaderingen van softwareontwikkeling te bespreken.

Voordat we in agile software development duiken, moet mij iets van het hart… Agile softwareontwikkeling is in feite géén innovatietechnologie… Sorry mensen.

Agile is een methodologie voor softwareontwikkeling. Niets meer, niets minder.

Agile hoort eigenlijk niet echt thuis in een artikel over innovatiemethodologieën (Zie ook de andere delen over Design Thinking en Lean Startup). Ik heb het echter toch meegenomen om dit punt duidelijk te maken – ik heb namelijk gezien dat veel mensen design thinking, lean en agile behandelen alsof het een en hetzelfde ding is. Dat is het niet. Wat niet wegneemt dat agile softwareontwikkeling heel goed kan werken zij aan zij met een innovatiemethodologie, en zoals we in het eerder artikel over de lean startup al hebben gezien is het feitelijk in het lean-startupproces gebakken. De andere reden dat ik agile meeneem, is dat de onderliggende principes ervan erg lijken op de besproken innovatiemethodologieën.

Proces

De agile ontwikkelingsmethoden splitsen productontwikkeling uit in kleine time increments, vaak ‘sprints’ of ‘iteraties’ genoemd, om de hoeveelheid voorafplanning en -design te minimaliseren.

  Iteraties (‘herhalingen’) of sprints zijn korte tijdsraamwerken die doorgaans één tot vier weken duren. Bij elke iteratie werkt een crossfunctioneel team aan alle functies: planning, analyse, ontwerp, codering, unittesting en acceptatietesting. Aan het einde van de iteratie wordt er een werkend product uitgegeven aan stakeholders en gebruikers om te meten hoe succesvol het is. Dit proces minimaliseert het risico en de onzekerheid en maakt het mogelijk om het product op basis van gebruikersfeedback snel aan te passen aan veranderingen. Sleutelconcepten in agile softwareontwikkeling zijn user stories, daily meetings en incremental development. Deze sleutelconcepten dienen allemaal dezelfde doelen: risico en onzekerheid wegnemen door in kleine ‘tijdsincrementen’ te werken; de alignment in een crossfunctioneel team vergroten; en waardevolle software produceren die frequent wordt vrijgegeven aan gebruikers om relevante feedback te krijgen. Werkende software is daarom de voornaamste maatstaf voor de voortgang. Onlangs heeft David Thomas, een van de opstellers van het Manifesto for Agile Software Development, een vereenvoudigde en gemoderniseerde versie van het agileproces voorgesteld.

Geüpdatete versie

1. Zoek uit waar je bent.
2. Neem een kleine stap vooruit richting je doel.
3. Pas je inzicht aan op basis van wat je hebt geleerd.

Het geüpdatete proces lijkt erg op de build-measure-learn-loop die in de lean startup wordt gebruikt.

 

Doel en toepassing Agile

Het hoofddoel van agile softwareontwikkeling is risico’s en onzekerheid verminderen en meer inzicht in gebruikers krijgen door veel versies uit te brengen. Daardoor kun je je snel aanpassen aan de feedback die je je gebruikers ontlokt. Dit doel lijkt heel erg op wat we bij design thinking en de lean startup hebben gezien. In essentie zijn deze innovatie– en softwareontwikkelingsmethoden ontwikkeld om het risiconiveau omlaag te brengen, wat je ook terugziet in hun processen en onderliggende principes. Agile softwareontwikkeling gaat hand in hand met elke innovatiemethodologie zolang er software nodig is voor het ontwikkelen van je experimenten of als je testontwerpen of MVP’s (is hetzelfde) nodig hebt om je meest kritieke hypothesen te valideren. Het is op zichzelf ook een nuttig proces als het grootste deel van je onzekerheid zich bevindt in de haalbaarheid van de technische oplossing die je voorstelt. Merk op hoe er speciale aandacht is voor het lenigen van risico’s door vaak versies uit te geven en voor het vervullen van klantbehoeften via waardevolle software. Ook weerspiegelt het manifest een zeer mensgerichte aanpak voor het organiseren en managen van een team.

Wat ik van agile softwareontwikkeling vind

Ik zie vaak dat agile softwareontwikkeling wordt misbruikt omdat mensen vergeten om hun lovenswaardige missie uit te splitsen in functionele incrementen. Elk increment/feature moet op zichzelf staand van waarde zijn voor de gebruiker, en dus is het zinvol om er een sprint omheen te creëren en om die, als hij klaar is, beschikbaar te stellen aan gebruikers. Wat ik vaak hoor is dat mensen claimen dat ze agile gebruiken aangezien ze het ontwikkelingsproces van een groot IT-project in kleinere sprints hebben uitgesplitst, maar tegelijkertijd hebben ze geen enkele intentie om ook maar iets uit te brengen voordat de hele mikmak klaar is. We zouden dit ‘onzekerheidssprints’ moeten noemen, want je doet dan meerdere sprints zonder ook maar enige onzekerheid weg te nemen, wat nou net het hele punt is… In hoeveel sprints je je project ook indeelt, je maakt geen gebruik van de agilemethodologie als je niet frequent op zichzelf staande functionele software uitbrengt – om op die manier onzekerheid weg te nemen door op basis van de feedback van klanten te begrijpen wat zij willen en vervolgens indien nodig je koers te veranderen. In het hart van agile softwareontwikkeling bevindt zich de wens om de risico’s te verminderen en om iets te creëren wat gebruikers nuttig en prettig vinden. Door: Jarl Rosenlykke Originele titel: Fast track to learning Design Thinking, Lean Startup, Agile, Pretotyping, and Design Sprint Bron: UX Planet Vertaling: Eduard Pieterse Kerkman, taallijn.nl