Waarom Agile belangrijk is

Onlangs kreeg ik een e-mail met de vraag waarom we ons zorgen zouden moeten maken over Agile als het totale productontwikkelingsproces, inclusief mechanica en elektronica, in jaren wordt gemeten en volledig waterval is. De vraag verraste me. Ik werk al bijna twintig jaar met Agile praktijken en voor mij is het een gegeven dat snelle feedbacklussen beter zijn dan langzame.

Na zorgvuldiger nadenken realiseerde ik me echter dat de vraag gebaseerd is op een aantal aannames die op hun beurt weer gebaseerd zijn op onze overtuigingen over ons vermogen om te voorspellen. De eerste veronderstelling heeft te maken met ons vermogen om de vereisten voor onze producten maanden, kwartalen of jaren later optimaal te voorspellen. In veel industrieën waar producten mechanische en elektronische onderdelen bevatten, vereist de productiepijplijn lange doorlooptijden. Bijgevolg worden de productvereisten lang voor het begin van de productie geformuleerd. De misvatting is natuurlijk dat eisen voortdurend veranderen door nieuwe technologieën die beschikbaar komen, veranderende voorkeuren van klanten, acties van concurrenten, enzovoort. Een vuistregel in software zegt dat requirements met 1 procent per maand veranderen – een zeer conservatieve schatting als je het mij vraagt.

Dus, hoe te reageren op voortdurend veranderende vereisten? Er zijn in principe twee benaderingen. Of je neemt wendbaarheid aan en reageert voortdurend op veranderingen, of je verzet je tegen veranderingen in vereisten, verwerpt alles wat je kunt en accepteert met tegenzin diegene die je echt niet kunt negeren. Het resultaat van de laatste aanpak is natuurlijk een inferieur product omdat het gebaseerd is op de beste inzichten van jaren geleden.

De tweede aanname is dat we het effect van onze vereisten kunnen voorspellen. Deze worden gedefinieerd als we hopen een specifiek resultaat te bereiken als gevolg van het realiseren van de eis. We zien dit het vaakst bij bruikbaarheidseisen, maar het geldt in principe voor elke kwaliteitsattribuut van het systeem. Online bedrijven gebruiken A/B-testen van oplossingen om de effecten van verschillende realisaties van functies en kenmerken op gebruikers te bepalen. Deze bedrijven doen dat niet omdat ze zo slecht zijn in requirements engineering, maar omdat het effect van functies fundamenteel onbekend is als het gaat om de manier waarop mensen reageren op softwarefuncties.

Traditionele engineeringbedrijven zijn trots op hun vermogen om de mogelijkheden van systemen te voorspellen voordat ze ze bouwen, omdat engineering een set wiskundige hulpmiddelen biedt voor modelleren, simuleren en voorspellen. Deze modellen worden dan meestal bevestigd door laboratoriumtests en in sommige gevallen kleinschalige tests in de echte wereld voordat er volledig wordt toegezegd op een specifiek ontwerp. Hoewel dit in veel gevallen goed werkt, blijft het zo dat metingen in de echte wereld een veel hogere validiteit opleveren dan wiskundige modellen en laboratoriumtests. Zoals ik in eerdere posts heb verteld, toont onderzoek door ons en anderen aan dat minstens de helft van alle functies in een typisch systeem nooit wordt gebruikt of zo zelden wordt gebruikt dat de investering in R&D een verspilling is. Dus als we technieken kunnen gebruiken om stukjes functionaliteit of functies te implementeren en het effect te meten voordat we er meer bouwen, dan moeten we dat doen, omdat het de effectiviteit van onze R&D sterk kan verbeteren.

Hoewel velen begrijpen dat praktijkexperimenten met betrekking tot bruikbaarheid en gebruikersgedrag een noodzaak zijn, geldt hetzelfde voor alle kwaliteitsattributen. Denk aan alle beveiligingsoplossingen die we moeten uitrollen. Vaak gaat het om kwetsbaarheden voor bedreigingen die al bekend waren voordat het ontwerp van het systeem klaar was. Het bleek gewoon dat de risicobeperkende strategieën die de ingenieurs in het systeem hadden ontworpen niet voldoende waren. Weten we ook zeker dat het huidige systeemontwerp ons de hoogste prestaties, de beste robuustheid en de hoogste energie-efficiëntie geeft? Natuurlijk niet! In plaats van te vertrouwen op modellen en laboratoriumtests, hebben we real-world experimenten nodig met onze producten bij klanten in het veld om voortdurend te verbeteren. Modellen en laboratoriumtests zijn nog steeds nodig, maar vooral om ons te beschermen tegen de nadelen van minder geslaagde experimenten voordat ze worden ingezet.

Concluderend, als je in staat bent om de optimale set vereisten voor een systeem of product jaren voor de start van de productie of uitrol perfect te voorspellen en als je in staat bent om het effect van elke vereiste op de gebruiker, de klant en de kwaliteitsattributen van het systeem nauwkeurig te voorspellen, dan heb je geen Agile nodig. In alle andere gevallen biedt Agile (zowel pre-deployment als post-deployment – DevOps) de mogelijkheid voor een enorme verbetering in de effectiviteit van je R&D (zoals gemeten in gecreëerde waarde voor elke eenheid R&D). Het is niet zo dat we geen producten kunnen maken met behulp van traditionele watervalprocessen – natuurlijk kunnen we dat wel, want dat doen we al tientallen jaren. De uitdaging is dat we daarbij veel minder efficiënt te werk gaan, waardoor het risico op verstoring voor ons bedrijf toeneemt.