„Sorry, maar Agile verbetert je producten niet"
We hebben al de blogpost van Jeff Sutherland gedeeld, waarin hij reageert op een artikel van Adam Pisoni, die beweert dat Agile je producten in werkelijkheid niet verbetert. Hier is dan het bewuste artikel van Adam Pisoni, medeoprichter en voormalig technisch directeur van Yammer en oprichter van Responsive.org.
Als je niet regelmatig het werk van Steve Denning leest, raad ik je aan dat te doen. Hij is een van de beste auteurs als het gaat om de toekomst van werk. In een artikel dat hij voor Forbes schreef, stelt hij dat agile productontwikkeling mainstream is geworden, maar werpt hij ook de vraag op of het inmiddels net zo'n voorbijgaande hype is geworden als zoveel andere managementtheorieën. Zijn conclusie is dat Agile niet echt een hype is, want
„Agile en Scrum pakken direct actuele bedrijfsvraagstukken aan, waar de initiatieven van de 20e eeuw omheen liepen. In Agile en Scrum krijgen klanten via de Product Owner een stem en worden competenties boven autoriteit gesteld."
Hoewel ik het in principe met veel dingen in zijn artikel eens ben, moet ik zijn conclusie tegenspreken. Agile heeft inderdaad een goede stap in de juiste richting gezet, maar dat gaat mij niet ver genoeg. Voordat Agile bestond, kwam het veel te vaak voor dat teams extreem veel tijd en middelen nodig hadden om iets te bouwen, om pas op het moment van oplevering te ontdekken dat de klant dat helemaal niet wilde hebben.
Agile moest het vooral mogelijk maken om succesvolle producten te bouwen in een wereld die te snel verandert om te kunnen voorspellen wat mensen willen en hoe je dat het beste voor ze kunt bouwen.
Hoewel Agile een hele generatie softwareontwikkelaars heeft geleerd hoe belangrijk experimenteren en klantfeedback zijn, is het Agile niet gelukt om het oude gecentraliseerde command-and-control systeem in het management te veranderen, wat een groot deel van het probleem vormt. Ook met Agile hebben ontwikkelaars die te weinig invloed en te weinig context hebben, veel te lang nodig om producten te ontwikkelen die klanten eigenlijk helemaal niet willen hebben. Dat leidt tot ontevreden klanten, ongemotiveerde ontwikkelaars en gefrustreerde managers.
Ter informatie: van 1995 tot 2014 was ik altijd – op een korte onderbreking na het barsten van de eerste dotcom-bubbel na – ofwel een fulltime softwareontwikkelaar of teamleider van ontwikkelteams. In 1997 leidde ik een team dat de watervalmethode gebruikte (voorloper van Agile). Bij waterval deed je al het ontwerp- en planningswerk vooraf en ging je ervan uit dat je het werk daarna nog kon opdelen en afronden.
In 2004 werkte ik voor een bedrijf dat sterk vertrouwde op analyse en A/B-tests en zelfs wekelijkse releases had – daarmee was men daar zijn tijd vooruit. Ik herinner me dat mensen voor het eerst over Scrum spraken, en ik herinner me dat ik een duidelijk beeld had van het probleem dat ik probeerde op te lossen: slecht management.
Eerlijkheidshalve moet ik zeggen dat ik het Agile Manifest en de bijbehorende principes opnieuw heb gelezen en het met elk punt eens ben. Ze zijn vandaag nog net zo goed en relevant als in 2001, toen ze werden geschreven. Bij Agile bouw je iets iteratief en leer je er gaandeweg voortdurend bij, in plaats van een groot plan te volgen. Bovendien zou de klant gedurende het hele proces een nauwe vertrouweling moeten zijn, zodat je tijdens de hele ontwikkelfase van hem kunt leren. Aangezien het doel zou moeten zijn om voortdurend nieuwe informatie op te nemen, zou je er ook van uit moeten gaan dat je regelmatig van richting verandert.
Voordat Agile bestond, maakte het management een plan dat precies documenteerde (voorspelde) wat er gebouwd moest worden, hoe het gebouwd moest worden en hoe lang dat zou duren – waarbij dat laatste waarschijnlijk het belangrijkste deel was. Zoals we weten, waren deze plannen nauwelijks voorspelbaar en konden ze zelden worden nageleefd. Het resultaat waren onrealistische verwachtingen en deadlines.
Tot overmaat van ramp was het door de tijdsvertraging tussen het afronden van het plan en het opleveren van het product zeer waarschijnlijk dat het management zonder enig begrip voor de kosten nog van gedachten zou veranderen over het product. Dat irriteerde uiteraard veel ontwikkelaars, wier taak het was om het "plan" uit te voeren. Dat betekende dat de situatie met onrealistische deadlines alleen maar erger werd en veel teams dwong om door nog meer planning latere wijzigingen zo klein mogelijk te houden. Ironisch genoeg kregen de ontwikkelteams door het gebrek aan transparantie in het ontwikkelproces meer autonomie om te beslissen in welke volgorde ze het werk zouden doen, hoe ze het zouden bouwen, wie dat zou doen, enzovoort. Uiteraard is het gevolg van deze vorm van autonomie en het gebrek aan transparantie vaak wantrouwen tussen management en ontwikkelteam. Uiteindelijk was niemand gelukkig.
En toen kwam SCRUM. Daarmee moest de transparantie in het proces worden vergroot en de efficiëntie in de ontwikkeling worden verbeterd. Wekelijks konden managers beslissen welke stories (oftewel features) ze als volgende wilden hebben en de ontwikkelaars konden dan inschatten hoeveel tijd en middelen ze daarvoor nodig zouden hebben. Het team kon vervolgens de totale kosten van alle geprioriteerde stories bepalen en uitzoeken hoeveel van dat werk ze voor de volgende Sprint op zich konden nemen.
Scrum heeft de transparantie drastisch vergroot en het voor managers moeilijker gemaakt om meer te eisen dan er überhaupt gedaan kan worden. Er werd ook rekening gehouden met de behoefte om plannen iteratief bij te werken. Door de verhoogde transparantie bij Scrum hebben ontwikkelaars echter nog minder autonomie dan voorheen. De bevoegdheden van ontwikkelaars werden beperkt tot het inschatten hoe lang iets waarschijnlijk duurt en het uitkiezen van de volgende story uit een lijst die grotendeels door het management wordt bepaald.
Een ontwikkelaar die aan een story werkt, heeft mogelijk helemaal geen idee van de samenhang en waarom deze story zo belangrijk is of wat het achterliggende initiatief eigenlijk is.
Hoewel Scrum erin is geslaagd om impulsieve managers in toom te houden, kwam het er uiteindelijk toch op neer dat er meer controle over ontwikkelaars en hun werk moest worden uitgeoefend.
Nog steeds neemt het management de beslissingen, prioriteert het de features en bepaalt het wie in welk team aan wat werkt. Met zijn focus op het inschatten van de benodigde inspanning voor voorgeschreven werk en weinig context, kijkt Scrum terug naar de eeuwwisseling, waar Frederick Taylor fabrieksarbeiders gedetailleerde instructies gaf.
In het Taylorisme gaat men ervan uit dat managers degenen zijn die over de expertise en de context beschikken om te kunnen bepalen waaraan gewerkt moet worden. Daarom was het hun taak om medewerkers gedetailleerde plannen voor te schrijven, zodat die zo min mogelijk eigen beslissingen hoefden te nemen.
Vrij aan het einde van de Agile Principes duikt een nogal misplaatst uitgangspunt op, dat door Scrum wordt genegeerd:
De beste architecturen, requirements en designs komen voort uit zelforganiserende teams.
Theoretisch is het mogelijk om Scrum in te zetten voor het bijhouden van werk in zelforganiserende teams, maar dat is niet de bedoeling en het komt slechts zelden voor. De meeste boeken over Scrum benaderen het vanuit een top-down managementperspectief en niet vanuit zelforganisatie.
Agile was een belangrijke stap om te erkennen hoe belangrijk testen en iteratief werken op basis van klantfeedback zijn. Maar grotendeels is het gericht op meer efficiëntie en controle versus empowerment, in plaats van op zelforganiserende teams. Een van de auteurs van het Agile Manifesto, Andy Hunt, ziet dat ook zo.
Natuurlijk kun je beweren dat Agile niet het probleem is, maar methoden zoals Scrum. Dat subtiele verschil gaat echter verloren, omdat Scrum en Agile inmiddels bijna synoniemen zijn geworden. Toen Agile bekender werd, werd het helaas misbruikt door traditionele command-and-control modellen, waaruit methoden zoals Scrum zijn ontstaan.
Wat is het alternatief? Kijk eens naar de ontwikkelmethoden van Spotify of de structuren van Yammer. In plaats van individuele personen met werk te belasten, geef je teams meer autonomie om zelf te beslissen wat ze willen bouwen en hoe. Deze teams bestaan bovendien uit mensen uit de meest uiteenlopende disciplines, zodat ze alles wat nodig is zelf kunnen doen zonder op toestemming of ondersteuning van anderen te hoeven wachten.
Of je nu wel of niet met Scrum werkt in je organisatie – als je het gevoel hebt dat je te langzaam vooruitkomt en niet bouwt wat je klanten willen, zijn er verschillende mogelijkheden om met nieuwe modellen te experimenteren zonder meteen alles tegelijk te hoeven veranderen.
Kies een project en stel een klein, toegewijd team samen met mensen die alle benodigde vaardigheden hebben, ook als deze mensen verschillende managers hebben. Presenteer hun het probleem en geef hun de mogelijkheid om het op te lossen zoals zij dat het beste vinden.
Idealiter is dit project kort genoeg om snel te kunnen vaststellen of het experiment werkt. Als je het team maar moeilijk die eigen verantwoordelijkheid kunt geven, heb je ofwel de verkeerde mensen geselecteerd, of ligt het probleem misschien bij jezelf. Het een "experiment" noemen kan je helpen om je idee te verkopen. Hoogstwaarschijnlijk zul je ontdekken dat kleine, toegewijde en cross-functionele expertteams extreem veel kunnen bereiken in zeer korte tijd.
De volgende uitdaging is om te ontdekken hoe je dit op grotere schaal kunt toepassen, mocht het werken. Daarvoor heb je normaal gesproken nieuwe oplossingen nodig, wat tot nieuwe problemen leidt, waarvoor je weer nieuwe oplossingen nodig hebt. Het is niet eenvoudig, maar het is de moeite waard.
Je zult merken dat het werkt wanneer je team sneller nieuwe ideeën aan klanten kan presenteren dan voorheen. Dat is het doel.
Autonomie vereist vertrouwen en dat vereist weer een gedeelde context. Dat is de reden waarom deze nieuwere modellen afhankelijk zijn van volledige transparantie, als iedereen op de hoogte gehouden moet worden. Bij Yammer hebben we kortlopende projectteams, zodat mensen meer mogelijkheden krijgen om daadwerkelijk te werken en van de meest uiteenlopende andere mensen te leren – maar dat is slechts één manier waarop je dit kunt aanpakken.
Het is niet genoeg als het management alleen het spreekbuis van de klanten is. Ontwikkelaars en designers moeten zelf de behoeften en doelen begrijpen en verinnerlijken van de mensen voor wie ze iets bouwen.
Agile was een belangrijke stap weg van de organisaties en methoden uit het industriële tijdperk. Als je echter een organisatie voor de 21e eeuw wilt creëren, zul je verder moeten kijken dan Agile naar nieuwere modellen die autoriteit verdelen, zelforganiserend zijn en je klanten, partners en medewerkers echt uitnodigen om "Owner" van het proces te worden.
Deze tekst is afkomstig uit de [Blog van First Round]8https://firstround.com/review/im-sorry-but-agile-wont-fix-your-products/ "Agile Produkte") en is door ons naar het Nederlands vertaald.
Voor Scrum Masters bieden we de volgende trainingen en gratis bijscholingsmogelijkheden:
