Snel kwalitatieve software bouwen is tegenwoordig geen grote uitdaging meer. Erachter komen wat je moet bouwen om de juiste problemen op te lossen wel! Het onderwerp van dit blog spookt al een tijdje door mijn hoofd. Ik blijf me namelijk verwonderen over het effect dat een projectaanpak heeft op het succes van een project. Waarom zien we zeer capabele teams veel slechter presteren dan verwacht?
In de afgelopen jaren heb ik veel bedrijven gezien die een agile aanpak proberen te hanteren, waarmee ze een meer traditionele ‘watervalaanpak’ van softwareontwikkeling vervangen. Bij deze ‘oude’ benadering probeert men het complexe softwareontwikkelingsproces te vereenvoudigen met het vooraf vastleggen van de softwarevereisten in documentatie.
Deze benadering werkt prima als je bij de start je specifieke behoeften kent. Eventuele wijzigingen in die behoeften worden behandeld als onregelmatigheden en maken eigenlijk geen deel uit van de aanpak. Toch kun je zelfs met een watervalaanpak het project nog aanpassen aan eventuele veranderingen.
Als je kiest voor een agile strategie, dan accepteer je dat je niet alles weet. De scope wordt vooraf niet exact vastgesteld, maar het project wordt gestuurd op succescriteria, planning, budget en kwaliteit. Er kan een mate van onzekerheid ontstaan. doordat het totale plaatje onbekend is.
Onzekerheid zorgt ervoor dat managers niet kiezen
De meeste traditionele managers vermijden onzekerheid, ze willen graag een gegarandeerde return on investment zien. Je moet je dan de volgende vraag stellen: Wil je liever een aanpak die valse hoop geeft op vaste investeringen en resultaten, of ga je voor een methode die erop gericht is om zoveel mogelijk waarde toe te voegen binnen een bepaald tijdsbestek?
Hierbij is het van belang dat het project is ingericht op het behalen van de vooraf gedefinieerde succescriteria. Hierdoor garandeer je dat elk besteed uur wordt gespendeerd aan het halen van je doelen. Dit is een cruciale keuze die je moet maken om succesvol te zijn met it-projecten.
Alles moet in dienst staan van agile
Ik zie regelmatig bedrijven die ‘agile’ doen. Dat werkt niet bij agile – je moet het volledig omarmen. Je moet onzekerheid accepteren en je constant concentreren op het leveren van waarde. Het belangrijkste is dat je de gekozen agile methode op alle vlakken toepast. Dat hoeven niet per se de voorgeschreven regels te zijn, maar de achterliggende filosofie is belangrijk.
Ik ben ervan overtuigd dat het veel beter is om óf een agile óf een watervalaanpak te volgen, dan om van beide onderdelen te nemen en dat te combineren tot een eigen aanpak die zogenaamd past bij je bedrijfscultuur. Deze aanpak noemen we ‘Waterscrummen’. Dit treedt op wanneer organisaties zoeken naar een vals gevoel van controle. Dit zijn een paar wellicht herkenbare symptomen:
-
Het team gebruikt enkele, maar niet alle scrum-ceremonies;
-
Het team ziet de meerwaarde van bepaalde ceremonies niet;
-
De product owner heeft niet het volledige mandaat om te beslissen en gedraagt zich meer als een klassieke projectmanager;
-
Het scrum-team mag niet zelfstandig problemen oplossen, waardoor de beste mensen op zoek gaan naar andere kansen;
-
Er is geen (dedicated) scrum master;
-
Het project kent geen snelle releases in korte cycli, maar blijft veel te lang in ontwikkeling;
-
Er is een te grote afstand tussen het scrum-team en de stakeholders uit de business.
Overwin de uitdaging, word wendbaar
Het kost bloed, zweet en tranen om een organisatie agile te laten denken en handelen. Toch is dit de uitdaging die de organisatie moet overwinnen om te overleven. Het ligt niet in de natuur van mensen om hun werkwijze te veranderen, dat vereist discipline en vastberadenheid. Als je de discipline hebt om deze nieuwe aanpak te volgen en je huurt een ervaren agile coach/scrum master in, dan zul je de voordelen snel zien.
Het begint allemaal met het identificeren van de juiste problemen. Die moeten eerst worden opgelost voordat er kan worden begonnen met de bits en bytes. Dan draait het dus niet om lange onderzoeken en dikke rapporten, maar staan deze vier duidelijke stappen naar succes centraal:
-
Discover. Ontdek waar je vandaag aan toe bent, bespreek de toekomstige organisatiedoelen en bekijk de mogelijke wegen om deze te bereiken.
-
Define. Op basis van een gezamenlijk begrip kijkt het team naar de voor- en nadelen en de prioriteiten op lange en korte termijn. Creëer focus en definieer de volgende stappen.
-
Design. Maak vervolgens een plan en prototype. Valideer of weerleg de aannames om erachter te komen wat werkelijk vereist is.
-
Do. Het pad waar je van droomde is niets zonder executie. Nu gaat het team het waarmaken, de overwinning ligt voor het oprapen.
De belangrijkste vraag blijft: Los je de juiste problemen op, of maak je software waar niemand om gevraagd heeft?
Top-down waterval methode heeft zijn beperkingen maar de bottom-up agile methodiek beloofd gouden bergen terwijl water door de zwaartekracht naar het laagste punt stroomt dus een combinatie van beide middels ‘waterscrummen’ is misschien nog wel de beste practice om efficiënt tot kwalitatieve resultaten te komen. Want waardetoevoeging (aan een business proces?) binnen een bepaald tijdsbestek klinkt voor mij namelijk als Continual Service Improvement van ITIL en 4 genoemde stappen hebben opmerkelijk veel overeenkomst hiermee. Dus waarom iets anders doen als vele onderzoeken en dikke rapporten achteraf bewijzen dat kwalitatieve software niet bepaald wordt door de snelheid van levering maar door governance modellen zoals ITIL?
“It-ers die een gesprekje met de business hebben zijn opeens consultants en schrijven hun uren met een vork. Een nieuwe competentie die makkelijk aan te leren is, net zo makkelijk als het schrijven van blogs. En een empathische vaardigheid om meelevend te knikken zonder je eigenaar van het probleem te laten worden is ook niet lastig aan te leren. Coachend bezig zijn schijnt dat tegenwoordig te heten hoewel het vooral klinkt alsof je langs de lijn staat te roepen.”
Stukje van de vorige reactie van oudlid op een artikel van de auteur
Zoveel methoden, zoveel culturen, zoveel belanghebbenden. Wat moeten die bedrijven nou ? Is de auteur niet ook gewoon een coachend bezig zijnde consultant ? En oudlid die mbt de waterval/agile aanpak naar ITIL verwijst maakt het allemaal ook niet eenduidiger. Wie gaat nu wat hoe oplossen en waarom ? Empatisch knikken zonder eigenaar van het probleem te worden is in ieder geval low hanging fruit waarbij voor de consultant zeer snel business waarde wordt gegenereerd binnen een bepaald tijdbestek.
Volgens mij bestaan er geen softwareontwikkeltrajecten seq. Er bestaan gewoon veranderinitiatieven. Ik durf wel een boute uitspraak te doen, door te stellen dat van de 100 gestarte software ontwikkeltrajecten er 80 niet hadden hoeven plaats te hebben, omdat men bij de daadwerkelijke vraagarticulatie in de organisatie nauwelijks het product of dienst dan wel het proces of de processen die deze product of dienst ondersteunen goed hebben doorvoeld. Veel organisatievraagstukken, hoe groot en klein dan ook, zijn vaak met een eenvoudige aanpassing in een proces of afzwakking of versterking van de product of dienstendefinitie op te lossen. Ook zal op deze manier ook nooit een alternatief voor het product of dienst in gang gezet worden. Mijn tweede stelling is dat in de jaren 90 onterecht (bleek achteraf) de “business” (jeukterm) het wel beter zou weten: ik weet het nu zeker, dat weten ze niet. Veel vakinhoudelijke mensen blijven vanuit de huidige situatie redeneren, en blijven ook lastig in beweging te krijgen, om anders naar hun producten en diensten te kijken en naar hun rol daarin. Ze hebben niet het vermogen (uitzonderingen daargelaten) om verder te kijken dan hun neus lang is. Vaak is baanbehoud een hele sterke stimulator.
Dus de projectmanagement methode is op het niveau van de vraaganalyse helemaal nog niet relevant. Overigens als een verandering relevant is, dan zijn er zowel voor- en nadelen voor beide methoden (waterval en agile). Een one-size-fits-all methode bestaat niet.
Wel eens met de schrijver dat veel beslissers een 0% risico score willen. Die beslissers hebben wij betreft hun langste tijd gehad. Daarom is een business case ook altijd tweeledig: inhoudelijk en financieel. Als je op gezette tijden de business case negatief ziet uitvallen op beide vlakken, trek dan de strekker uit een traject, resoluut. Ik heb veel meer respect voor beslisser die de stekker uit trajecten trekken, dan voor beslissers die 0% risico nastreven.
Verkoop een verlangen naar de eindeloze oceaan in plaats van een gegarandeerde return on investment binnen een contractuele resultaatverplichting en je hebt een ‘zilvervloot’ aan verwachtingen die nooit een haven binnen hoeven te lopen. Een consultant kan empatisch knikken zonder eigenaar van het probleem te worden als alleen maar inspanningsverplichtingen geleverd hoeven te worden van softwareontwikkeling zonder doelbinding.
Betreffende de 4 stappen in de kwaliteitscirkel van Deming had ik ook naar methodieken kunnen wijzen, zo maakt ook de OODA-lus hiervan gebruik. Ik wijs echter op CSI omdat metriek om een verbeteringsinspanning van doelmatigheid gaat op basis van veranderende bedrijfsbehoeften. Na de return on investment van verandering ligt er vaak nog een lange periode van beheer en onderhoud als ik kijk naar de Value on Investment van service lifecycles.