De Church of Agile wordt van binnenuit gecorrumpeerd door institutionele krachten die hebben geweigerd of niet in staat waren zich aan te passen aan de radicale menselijkheid die belichaamd wordt in haar samenwerkende, zelforganiserende, cross-functionele teams. Een uitgeholde schil van Scrum die de taakmeesters van Waterfall verbergt, is het Trojaanse paard van dit verraad.
Met Waterfall-methoden die zich voordoen als Scrum – noem het Scrumfall – bevestigen bedrijven opnieuw top-down micromanagement, versterken ze silo’s, beperken ze flexibiliteit en maken ze software-engineers tot handelswaar als louter radertjes die code tevoorschijn toveren. Deze schijnvertoning van echte Scrum maakt niet alleen de beloofde productvoordelen van Agile ongedaan, maar ook de mensgerichte principes, die de nadruk leggen op vertrouwen, samenwerking, respect, verbinding en duurzame werkomgevingen.
Agile had niet zo moeten zijn.
De gebroken belofte van Agile
Het Agile Manifesto is kort, krachtig … en revolutionair:
- “Individuen en interacties boven processen en tools”
- “Werkende software boven uitgebreide documentatie”
- “Klantsamenwerking boven contractonderhandeling”
- “Reageren op verandering boven het volgen van een plan”
“Oom” Bob Martin – een van de belangrijkste aanstichters en ondertekenaars van het manifest, en auteur van Schone code: een handboek van agile softwarevakmanschap – zou het manifest hebben gekarakteriseerd als “een reeks waarden gebaseerd op vertrouwen en respect voor elkaar en het promoten van organisatiemodellen op basis van mensen, samenwerking en het bouwen van de soorten organisatorische gemeenschappen waarin we zouden willen werken.”
Agile wordt verondersteld te zijn gericht op mensen, niet op processen – op mensen die nauw samenwerken om problemen samen op te lossen in een cultuur van autonomie en wederzijds respect, een duurzame cultuur die de gezondheid, groei en tevredenheid van elk individu waardeert.
Er is een geloof ingebed in het manifest dat deze benadering van software-engineering zowel noodzakelijk als superieur is aan oudere modellen, zoals Waterfall. Noodzakelijk vanwege de inherente complexiteit en onbepaaldheid van software engineering. Superieur omdat het gebruik maakt van de volledige samenwerkingskracht van ieders intelligentie. Maar dit is ondergeschikt aan het meest fundamentele idee van Agile: Wij waarderen mensen.
Het is tegenwoordig een zeldzame werkgever die geen lippendienst bewijst aan dat idee. “We waarderen onze mensen.” Maar veel bedrijven geven in plaats daarvan prioriteit aan het beheersen van hun grondstoffen. Dit is nu onaanvaardbaar om hardop te zeggen – in kringen van software-engineering zoals in een groot deel van het moderne Amerika – hebben veel bedrijven het in Scrum-kleding gestoken, waarbij ze de Agile-ideologie claimen terwijl ze het hiërarchische micromanagement van Waterfall opnieuw bevestigden.
Een schijnvertoning van echte Scrum
De verkeerde toepassing van verhaalpunten is de vector waarmee deze schijnvertoning van Scrum wordt geleverd.
Scrum-verhaalpunten waren oorspronkelijk bedoeld om de familielid complexiteit van verhalen. Ze zijn een benadering van een abstractie van de relatieve verwachte inspanning, een die is gemaakt voordat de engineering daadwerkelijk wordt ingeschakeld. Zij zijn niet een schatting van de tijd, en ze zijn niet een legitieme basis voor het stellen van een termijn.
En toch is dit precies hoeveel bedrijven storypoints gebruiken, die ze aan tijdlijnen binden om glanzende schattingen uit hun … nou ja, laten we zeggen petten te krijgen. Ze verwachten dan dat hun menselijke troeven zich aanpassen aan het plan in plaats van dat het plan zich aanpast aan de mensen en de opkomende lessen van implementatie.
Vervolgens pushen ze hun mensen om code uit te werken, waarbij ze op schema blijven om verhalen op tijd te leveren. Als blijkt dat een verhaal dat op 4 uur wordt geschat, eigenlijk 16, nou ja, tijd zal kosten om wat Red Bulls te beuken, en dan druk en slijpen om de fantasie-wiskunde in evenwicht te brengen die de waarde van de mensheid op nul zet.
Klinkt dat als een methodologie die “individuen en interacties” plaatst boven “processen en hulpmiddelen”? Een die “klantsamenwerking” boven “contractonderhandeling” stelt? Is het “reageren op verandering” in plaats van “een plan volgen”?
Duidelijk niet. Dit zijn verhalen als mini-watervallen, die elk de ingenieur behandelen als een radertje in de machine van hun werkgever. Verhalen als volledig gespecificeerde opdrachten voor stukjes code, zonder begrip van het ambacht, de creativiteit en het kritisch denken dat nodig is om dergelijke complexe problemen op te lossen.
Waterval met een andere naam is nog steeds achterhaald
Deze mini-watervallen vermomd als Scrum weerspiegelen een top-down, lineaire benadering die software-ingenieurs niet de autonomie, toegang en autoriteit geeft om de implementatie te stimuleren van wat het productteam vraagt.
Er is geen ruimte voor echte gesprekken en echte samenwerking. Er is geen ruimte voor betere ideeën om naar voren te komen, of voor iemand om van gedachten te veranderen.
Scrumfall vertrouwt er met andere woorden op dat het productteam (bestaande uit mensen) een complete en perfecte specificatie levert voordat de ontwikkeling begint. En het is afhankelijk van het ontwikkelteam (ook mensen) dat een volledige en perfecte implementatie plant voordat een enkele regel code wordt geschreven.
Zelfs Dr. Winston W. Royce, die het baanbrekende artikel schreef over wat we nu Waterfall noemen, geloofde niet dat dit mogelijk was. “Ik geloof in dit concept”, schreef hij, “maar de hierboven beschreven implementatie is riskant en nodigt uit tot mislukken.”
Toen de onvermijdelijke onvolkomenheden van specificatie en implementatie later naar voren kwamen, schreef Royce: “De vereiste ontwerpwijzigingen zullen waarschijnlijk zo storend zijn dat de softwarevereisten waarop het ontwerp is gebaseerd en die de reden voor alles vormen, worden geschonden.”
Geen wonder dat we een andere aanpak nodig hadden.
Kan Scrumfall ooit werken? Zeker, in de meest triviale gevallen. Een standaard inlogpagina nodig? Dat kunnen we tijdig specificeren, inschatten en uitvoeren zonder veel doorlopende samenwerking.
Maar voor alle werkelijk interessante, waardevolle en zelfs revolutionaire uitdagingen in software-engineering – het werk dat complex en niet-deterministisch is – hebben we mensen nodig die op zinvolle manieren samenwerken om samen betere oplossingen te bedenken.
Het vlindereffect kweekt insecten
Samenwerking brengt onvermijdelijke onzekerheid in het proces. (En absoluut de binnenvallende Waterval-taakmeesters verborgen in Scrum’s Trojaanse paard) een hekel hebben aan onzekerheid.) Onzekerheid is echter geen bug maar een kenmerk van Agile, dat erkent dat betere oplossingen alleen kunnen ontstaan als het proces het onbekende omarmt en het voorrecht van mensen beschermt om van gedachten te veranderen.
Het hele gebied van software-engineering is zo jong, slechts iets meer dan 50 jaar oud, en verandert zo snel. Vergelijk dat eens met de millennia van vooruitgang, verfijningen en standaardisaties van de civiele techniek. Zoveel van wat we doen is nieuw, een verkenning van het onbekende.
Software is ook orden van grootte complexer. Hoewel het onbewerkte aantal regels code slechts een grove maatstaf voor de complexiteit is, moet u bedenken dat zelfs een eenvoudige iPhone-app doorgaans 40.000 regels code heeft, terwijl meer substantiële software doorgaans miljoenen regels code bevat. De codebase van Google bevat naar schatting 2 miljard regels code, vergelijkbaar met de 3,3 miljard van het menselijk genoom.
Als je alle interacties tussen deze coderegels in ogenschouw neemt, betreed je het gebied van de chaostheorie, waardoor software zeer gevoelig wordt voor vlindereffecten: voor enorm onbedoelde gevolgen.
Kortom, we hebben te maken met een inherent niet-deterministisch proces. Het scheiden, isoleren en opsluiten van mensen zal de onzekerheid nooit wegnemen. Het afdwingen van naleving van willekeurige deadlines en rigide plannen zal geen deterministische resultaten opleveren.
In plaats daarvan creëren deze ketens van mini-watervallen chaos, waardeloze code en, ironisch genoeg, kostenoverschrijdingen en gemiste deadlines. Succes op lange termijn wordt opgeofferd aan Scrumfall’s noodzaak om op korte termijn aan willekeurige metingen te voldoen. Het is ook een zekere weg naar burn-out ingenieurs, die binnenkort zullen vertrekken naar andere kansen met meer voldoening en duurzaamheid, minder drukte.
De val van Scrumfall ontsluit de ware kracht van Agile
Agile blijft een heel goed idee dat de waarde van mensen boven die van processen stelt. De radicale herstructurering van de levenscyclus van softwareontwikkeling zal ons vakgebied blijven transformeren en superieure oplossingen produceren.
Maar om de ware kracht van Agile te ontsluiten, moeten we de niet-deterministische complexiteit van de betekenisvolle problemen die we oplossen volledig accepteren. Er is zoveel dat we niet weten aan het begin van een nieuw project, en volgens Agile is dat prima in orde. Slimme mensen die samenwerken in een mensgerichte cultuur kunnen hun eigen weg vinden naar een goede oplossing. Je hoeft ze alleen maar de flexibiliteit te geven om dingen op te lossen zoals ze denken dat het beste is.
Er zullen onderweg verkeerde afslagen zijn. Mensen zullen van gedachten veranderen of een betere oplossing zien. Sommige verhalen duren langer dan je verwacht. (En voor sommige is minder nodig.) Mogelijk moet u uw tijdlijn wijzigen, uw MVP heroverwegen of uw functies opnieuw prioriteren.
Agile stelt dat niets van dit alles kapot is, niets ervan een fout is en niets ervan verspild is. Dat is wat slimme mensen doen als ze complexe problemen oplossen. In plaats van te proberen al deze onzekerheid te beteugelen, verwelkomt Agile het als de essentie van creatie.
Er moet natuurlijk een evenwicht worden bewaard. Agile kan geen anarchie van ontwikkelaars zijn die nooit tot een voltooid product leidt. Goed geïmplementeerde Scrum (of Kanban) houdt het team op één lijn met wat nodig is en wat redelijkerwijs zal leiden tot het gewenste resultaat binnen beperkte tijd en budget.
Maar we moeten stoppen met het degraderen van de kracht van Agile door obsessief ijdelheidseenheden te meten in plaats van de waarde van wat wordt geleverd.
Om het ware potentieel van Agile te realiseren, moeten we ons opnieuw vasthouden aan de kernprincipes en deze naleven in alles wat we doen door de hardnekkige taakmeesters van Waterfall die zich in Scrumfall verbergen, te verbannen.
