Agile toepassen met gezond verstand

Hoe groter de onzekerheid en dynamiek van een markt waarin de organisatie actief is, hoe meer de business en IT hunkeren naar flexibiliteit en experimenten. En in situaties die vragen om flexibiliteit is het lastig om vooraf alle specificaties te formuleren en vast te leggen – wat een vereiste is voor de traditionele watervalmethode.

De standaard Agile/Scrum-methodiek is dan ook ideaal om proofs of concept te realiseren en de verwachte snelheid van een groot ontwikkelproject te bepalen. In het laatste geval worden meerdere korte ontwikkelperioden – ‘sprints’ genoemd – gebruikt om functionaliteit van verschillende complexiteit te ontwikkelen, waardoor het projectteam een ​​vrij nauwkeurige indicatie krijgt van de doorloopsnelheid van het totale project.

De Agile-aanpak biedt nog meer voordelen:

• het centraal stellen van de specifieke uitdaging van de (interne of externe) klant of opdrachtgever
• snelle opleveringen (door bijvoorbeeld eerst de meest waardevolle functionaliteit te ontwikkelen)
• verspilling voorkomen (voor een proof of concept kan een uitgewerkte behoefteanalyse achtergwege blijven),
• kort cyclisch leren (bijvoorbeeld feedback van klanten na elke sprintdemo),
• de flexibiliteit om beslissingen pas laat in het proces te nemen (bijvoorbeeld achterstand prioriteiten stellen onderweg),
• empoweren van het team (bijvoorbeeld aanmoedigen in plaats van voorschrijven),
• ingebouwde integriteit (bijvoorbeeld soft controls, autoriteit op basis van expertise in plaats van hiërarchie)

Allemaal goede dingen, waardoor de Agile-methodiek zich tot in de boardroom zo gemakkelijk laat verkopen. Een van de gevolgen daarvan was dat van de ene op de andere dag alle projectmanagers eruit moesten of zich moesten laten omscholen tot Scrum Master. Ook leidde het tot backlogs (de geplande werkvoorraad) die permanent overstromen, onnodig veel dingen opnieuw moeten doen, en luie business en IT organisaties. Hoe dat zo?

Agile kan leiden tot luiheid

In de eerste ontwikkelweek wil de business een spreekwoordelijke groene auto, over drie sprints toch liever een blauwe en na sprint acht lijkt rood toch de beste keuze. Stel hier als buitenstaander een kritische vraag over en je krijgt te horen van het team dat in dit soort ‘flexibiliteit’ de kracht schuilt van Agile. Het scrumteam zelf, zeker als dat bestaat uit ingehuurde externen, zal hier niet snel kritische vragen over stellen. Zij blijven lekker doorprogrammeren, testen, de backlog refinen en braaf uitvoeren wat de product owner namens de business vraagt. Want: uurtje-factuurtje.

Omdat de impliciete aanname bij Agile is dat er altijd nog een sprint is, is het niet alleen belangrijk om kritisch te zijn op de functionele items op de backlog. Dezelfde aanname kan namelijk ook leiden tot een te gemakzuchtige houding vanuit het team ten opzichte van het opgeleverde werk. Niet kritisch doorvragen tijdens de refinement sessies en veel programmeerfouten leiden tot backlogs die grotendeels zijn gevuld met rework, het aanpassen of opnieuw bouwen van softwareonderdelen.

Een goede balans tussen enerzijds vertrouwen en anderzijds een positief-kritische houding richting het team is daarom een belangrijke voorwaarde om het beschikbare budget optimaal te laten renderen. Actieve betrokkenheid van senior bestuurders uit de business kan hier een belangrijke rol spelen.

Er is nog een andere belangrijke voorwaarde voor een succesvolle agile ontwikkelaanpak: een afgewogen balans tussen functionele en niet-functionele requirements. Laten we daar eens naar kijken.

Een flatgebouw vraagt om een ander fundament dan een tuinhuis

‘De klant centraal stellen’ heeft een schaduwzijde, namelijk te vroeg in het ontwikkeltraject teveel focus op functionele requirements. Gebruikers willen niks liever dan aan het einde van iedere sprint weer een nieuwe set features zien, een verwachting die gestimuleerd wordt door de focus op 'visibility’ binnen de standaard agile ontwikkelmethodiek.

Het software-equivalent van een tuinhuis bouwen op deze manier is geen enkel probleem, maar een gebouw met vijftig verdiepingen realiseren met deze aanpak is geen goed idee: voordat het gebouw de tiende verdieping haalt, is het weer ingestort. Voor een gebouw van vijftig verdiepingen is het cruciaal om eerst een goed fundament te leggen, in plaats van te beginnen met bouwen en na iedere verdieping te bepalen wat er nodig is om de volgende verdieping te realiseren. Bij software is dat niet anders, hoewel de fundamenten (zoals de architectuur, security, schaalbaarheid, performance en monitoring) niet direct zichtbaar zijn voor de gebruiker.

Te vroeg te veel focussen op functionaliteit leidt tot een snel oplopende schuld (‘technology debt’) die ergens in de toekomst moet worden betaald. Het is een behoefte die het team achter het Scaled Agile framework gelukkig onderkent, via expliciete aandacht voor het onderwerp architectuur (‘Agile Architecture strategy’) en de realisatie daarvan (‘Architecture Runway’).

Net als bij het vorige attentiepunt, bepaalt ook hier weer de volwassenheid en standvastigheid van de direct betrokkenen in hoeverre het langetermijnperspectief het wint van tastbaar resultaat op korte termijn.

En dan is er nog een categorie software die aan het einde van het ontwikkelproces direct perfect moet werken, zonder ruimte voor fouten.

Agile gaat niet samen met first-time-right

Wanneer een vliegtuig voor de eerste keer los komt van de startbaan is er geen ruimte meer voor ‘oeps, dat lossen we in de volgende sprint wel op’. De eerste release naar productie moet goed zijn.

Daarnaast zijn de ruim acht miljoen coderegels aan boord van de F35 Lightning II ingebed in duizenden componenten, zoals de radar, motor en cockpit. Al deze onderdelen worden vervaardigd door honderden leveranciers. Om ervoor te zorgen dat ze desondanks in perfecte harmonie functioneren, moeten de architectuur, technologie en alle vereisten vooraf in detail worden gespecificeerd. Dezelfde context zorgt er ook voor dat pas relatief laat in het ontwikkelproces zinvolle functionele (integratie)testen kunnen plaatsvinden.

Een andere situatie die baat heeft bij een meer traditionele ontwikkelaanpak is een één-op-één conversie van een goed gedocumenteerde en stabiele legacy-applicatie. Ook hier worden de potentiële voordelen van Agile (bijvoorbeeld tweewekelijkse demo’s, frequent tussentijds in productie) vaak overtroffen door de bijbehorende extra kosten. De standaard Agile methodiek werkt dus minder goed in situaties waar:

• de vereiste functionaliteit bekend is, of zou moeten zijn, bij aanvang van het project
• de eerste oplevering de volledige reikwijdte van de functionaliteit moet dekken

Naast efficiëntere personeelsbezetting en toewijzing van middelen, biedt een meer traditionele methode ook meer ruimte voor tijdrovende taken, zoals het opstellen van een degelijke set documentatie. Niet alleen piloten en astronauten, maar ook engineers die complexe geautomatiseerde installaties onderhouden, en procesengineers in bijvoorbeeld chemie en elektriciteitsopwekking, kunnen niet zonder.

Soms heb je een snelle, wendbare, maar brandstofverslindende speedboot nodig, terwijl andere situaties juist vragen om een ​​voorspelbaar, robuust en efficiënt containerschip.