In de loop van de geschiedenis is de software waaraan we werken steeds groter en complexer geworden. Hierdoor is het voor stervelingen al lang niet meer mogelijk om de gevolgen van elke wijziging te overzien. Al snel groeien daardoor de implicaties van wijzigingen onze menselijke capaciteiten boven de pet, en wordt een geplande kleine aanpassing regelmatig weer een spannende grote verbouwing. Het resultaat zijn te grote pull-requests om grondig te reviewen, en daarmee groeiende risico’s voor de stabiliteit van het software systeem waaraan we werken. Dit is dus niet de weg naar succes.
GeePaw Hill levert in zijn artikelen over Many More Much Smaller Steps de onderbouwing voor een praktische manier om deze complexiteit te lijf te gaan. Hij schetst hierin dat er in realiteit (vrijwel) nooit een vooruit te plannen lineair pad bestaat om het doel te bereiken, en kiest er daarom bewust voor om in plaats daarvan altijd zo klein mogelijke stapjes te maken. Elke afgeronde stap levert zo een nieuw keuzemoment op over de volgende stap, en programmeren wordt daarmee net zo Agile als het overkoepelende project. Uit getuigenverslagen van goeroes uit ons veld die met GeePaw samen hebben gewerkt, lees ik dat zijn stapjes zelfs kleiner zijn dan zelfs zij zich hadden voorgesteld…
De strategie van MMMSS is om het werk op te delen in stapjes die het systeem telkens van een stabiele toestand naar de volgende stabiele toestand brengen. Zo’n stap is daarmee de kleinste eenheid van integratie/release, en heeft als enige voorwaarde dat de stap het systeem niet slechter maakt. Belangrijk inzicht is dat een stap het systeem zeker niet altijd beter hoeft te maken; een stap kan ook waarde hebben omdat het de volgende stap eenvoudiger maakt. De flexibiliteit van kleinere stappen maakt het zo mogelijk om bewust rond problemen te navigeren, in plaats van alles tegelijk op te moeten lossen en het risico te lopen de weg kwijt te raken.
Fascinerend is dat stappen recursief weer te splitsen zijn in steeds kleinere stappen: User stories zijn de grote stappen die waarde hebben voor gebruikers op product niveau. Deze zijn op te delen in functionele wijzigingen die samen (uiteindelijk) de story realiseren. En deze stappen zijn weer verder op te delen in losse code wijzigingen waarna alle testen weer op groen staan. Elke stap op een lager niveau levert zo een bijdrage aan het behalen van de stap op het hogere niveau. Dit betekent echter niet dat dit een planning vergt waarin alle stappen vooruit worden gepland: De context van het hogere niveau is alleen nodig tijdens het plannen van de eerstvolgende stap op het lagere niveau. Deze aanpak levert daarmee een afbakening van de hoeveelheid informatie waar tijdens het bouwen van elke stap rekening mee moet worden gehouden. Na de beslissing wat de volgende stap is, vervalt de noodzaak om over de rest van de hiërarchie na te denken. Dat speelt pas weer bij het starten van de volgende stap, en dan is de realiteit inmiddels gewijzigd door de vorige afgeronde stap.
Meer en kleinere stapjes maken levert controle over wat we doen en meer zichtbaarheid naar de rest van het team. Net als in de fysieke wereld leveren kleinere stapjes meer stabiliteit en daarmee de mogelijkheid te reageren op onverwachte ontwikkelingen. De kunst is daarbij om de stapjes niet alleen klein te houden, maar ook doorlopend te blijven zoeken naar manieren om ze nóg kleiner te maken.
De gevolgen van kleinere stapjes maken zijn onder andere kleinere pull-requests, vaker voldoening voelen over het afronden van iets, meer natuurlijke momenten om pauze te nemen of tussendoor iets anders te doen, en meer momenten voor reflectie over bijvoorbeeld design en de gevolgen van de ingeslagen weg. En niet geheel onbelangrijk: Het vermindert de kans om vast te lopen in een onoverzichtelijke verbouwing. (En als het toch gebeurt is het waarschijnlijk niet zo erg om de stap weg te gooien en overnieuw te beginnen.)