Agile zonder empirisme
Hebben we het slechtste van twee werelden gecreëerd?
Veel organisaties werken tegenwoordig Agile. Dit in de vorm van Scrum, Kanban of grotere implementaties met SAFe. Toch zie ik vaak dat we als onderdeel hiervan oude kwaliteitsmechanismen afbouwen en ook meer en meer gaan vasthouden aan vooraf bepaalde scope, budget en deadline.
Teams moeten sneller opleveren en kwaliteit hoort ondertussen onderdeel van het hele proces te zijn. Maar dat vraagt om investeringen in kwaliteit én om empirisch werken: iets kleins opleveren, toetsen wat er gebeurt en op basis daarvan bijsturen. Ontbreken die investeringen en de ruimte om iets met nieuwe inzichten te doen, dan verliezen we de vangnetten van traditioneel werken én het leervermogen van Agile.
Dan creëren we het slechtste van twee werelden.
Budget en deadline zijn niet het probleem
Een discussie over story points bracht dit recent weer bij mij naar boven. Story points zouden onvoldoende voorspelbaarheid geven, dus moeten we nauwkeuriger schatten in uren en capaciteit. Maar hoeveel zekerheid proberen we eigenlijk uit een schatting te halen?
Softwareontwikkeling bevat onzekerheid. Je weet vooraf nou eenmaal niet precies welke oplossing werkt of hoe gebruikers erop reageren. Dat ontdek je door iets op te leveren en feedback te verzamelen. Vervolgens moet je daar wel naar kunnen handelen. Natuurlijk hebben organisaties budgetten en deadlines.
"Maar uit een vast budget en een einddatum volgt niet automatisch dat ook de volledige oplossing vooraf vast moet staan."
Spreek af welk probleem je wilt oplossen, hoeveel je wilt investeren en wanneer je resultaat verwacht. Focus dus op de outcome. Gebruik wat je leert om te bepalen wat je vervolgens bouwt in de tijd die je hebt.
Misschien zijn daarvoor minder features nodig dan bedacht. Als je het gewenste resultaat al hebt bereikt, waarom zou je dan doorbouwen? Als scope, budget én deadline vooraf vaststaan en nieuwe inzichten daar nauwelijks invloed op mogen hebben, krijgt een Product Owner te weinig ruimte om het product te sturen. De rol blijft dan beperkt tot een roadmap omzetten naar een backlog en bepalen welke story eerst komt.
Een Product Owner moet op basis van nieuwe informatie andere keuzes kunnen maken. Ontbreekt die ruimte, dan moet dat gesprek terug de organisatie in. Teams vertellen dat ze autonoom zijn, helpt dan niet. We doen verkapt traditionele softwareontwikkeling met Agile-termen.
We halen vangnetten weg zonder iets beters terug te bouwen
Vanuit mijn test- en kwaliteitsachtergrond zit hier het grootste probleem. Traditionele softwareontwikkeling had genoeg tekortkomingen, maar ook kwaliteitsmechanismen: reviews, testplannen en acceptatiemomenten. Iemand keek bewust naar risico’s voordat software verder mocht.
Agile en DevOps willen kwaliteit gedurende het hele proces inbouwen. Daar sta ik helemaal achter, maar dat moeten we dan ook doen.
Helaas zie ik nu te vaak dat;
de testfase verdwijnt terwijl testautomatisering nog onvoldoende is;
we minder requirements vastleggen zonder samen het gewenste gedrag en de risico’s goed te bespreken;
benodigde documentatie wordt overgeslagen onder het mom van Agile;
we vaker releasen terwijl we nauwelijks zien wat de software in productie doet.
Die snelheid komt voor een deel doordat we werk weglaten. Dat is snelheid op geleende tijd. De rekening volgt in defects, rework, technische schuld en steeds moeilijker wordende releases.
Zonder kwaliteit kun je niet snel leren
Als we oude vangnetten weghalen, moeten we iets beters terugbouwen. Anders houden we elkaar voor de gek. Wanneer je weken nodig hebt om te bepalen of een wijziging veilig is, kun je niet snel leren. Zonder goede productiefeedback weet je bovendien niet of die wijziging het gewenste effect heeft. En als iedere release spannend is, groeit vanzelf de behoefte aan extra controles en coördinatie.
Daarom maakt Quality Engineering Agility mogelijk. Ingebouwde kwaliteit geeft teams het vertrouwen om kleine veranderingen veilig op te leveren, feedback te verzamelen en opnieuw te beslissen.
Dat vraagt investeringen in testbaarheid, automatisering, goede afstemming en inzicht in productie. Dat kost tijd, maar deze disciplines horen bij een goede manier van Agile werken. Naast als dat het nodig is om de ruimte te krijgen om op basis van nieuwe inzichten van koers te veranderen.
Bij Conexxia werken we aan die samenhang tussen organisatie, engineering en kwaliteit. In mijn volgende blogs diep ik uit hoe dat bijdraagt aan ‘Get Quality Outcomes. Faster.’
