Waarom Puur Agile Softwareontwikkeling niet Altijd de Beste Oplossing is (Softwareprojecten)

en je jouw eigen hybride projectmanagementmethode zou moeten ontwikkelen…

Tegenwoordig lijkt het alsof softwareprojecten enkel onderscheid maken tussen twee zaken: is de manier van werken “agile” of niet. Wanneer er over het over het procesmodel vragen gesteld worden, is de argumentatie vaak dat er met “agile” of “niet agile” wordt gewerkt en dat dus de manier van werken is zoals het is. Kortom, de indruk wordt gewekt dat er maar twee exclusieve soorten projectmanagement in softwareontwikkeling zijn – “agile” (vaak Scrum) of het tegenovergestelde “not agile” (vaak Waterval of V-model).

Hieronder wordt uitgelegd waarom dit niet klopt en waarom het belangrijk is om de methoden te begrijpen om echte toegevoegde waarde te genereren uit project-specifiek management. Tot slot wordt een oplossingsvoorstel (blauwdruk) gepresenteerd dat geschikt zou moeten zijn voor de meeste softwareprojecten (gefaseerde Scrum).

Agile Softwaredevelopment

Reeds vóór de COVID pandemie was agile softwareontwikkeling een veelbesproken onderwerp. Talrijke concepten gebaseerd op wendbaarheid zijn ontstaan. Tot de bekendste behoren Extreme Programming (XP), Scrum, Scrumban en (Biz)DevOps.

Maar wat betekent agile softwaredevelopment eigenlijk?

Wat is agile Softwaredevelopment

Agile softwareontwikkeling werd geïntroduceerd door het Agile Manifesto for Software Development in 2001. Als het manifest aandachtig wordt bestudeerd en de inhoud wordt gecategoriseerd, kunnen de volgende clusters worden herkend:

1. Vaststellen wat er opgelost of vervuld moet worden.
2. Ontdekken wat er ontwikkeld moet worden.
3. Het ontwikkelen van de juiste oplossing door voortdurend waarde te creëren.
4. Zelforganisatie om punten één tot en met drie continu te implementeren.
5. Enkele concrete development content vaststellen.

Het valt op dat deze principes zich niet richten op de feitelijke ontwikkelingsactiviteiten. In plaats daarvan beschrijven ze de stappen vóór het programmeren. Het gaat erom voortdurend te ontdekken wat er opgelost moet worden en bijgevolg wat er ontwikkeld moet worden. Hieruit kan worden afgeleid dat agile ontwikkeling vooral draait om het bepalen en niet om de daadwerkelijke ontwikkeling.

Waarom ligt de focus op onderzoek?

De reden hiervoor wordt duidelijk als we het watervalmodel bekijken. Het watervalmodel is een lineair (niet iteratief) procesmodel. De structuur is gebaseerd op vooraf gedefinieerde fasen die in een bindende volgorde doorlopen moeten worden. In de praktijk wordt het model uitgebreid door terugkoppelingen naar eerdere fasen. Deze sprongen moeten echter geminimaliseerd worden en maken geen deel uit van het eigenlijke concept. Het basisidee van dit concept is dat mogelijke fouten kunnen worden vermeden door nauwkeurig te plannen. Het watervalmodel kan als volgt worden geschetst:

Zoals Mohandas K. Gandhi zou zeggen: “Ik denk dat het een goed idee zou zijn”. Hij wijst erop dat theorie en praktijk werelden van verschil kunnen zijn. Onder de voorwaarde van optimaal planningsvermogen zou deze methode werken. Maar in de praktijk is deze voorwaarde vaak niet aanwezig. Complexiteit, misverstanden of onvoorziene gebeurtenissen kunnen dit lineaire en bindende ontwikkelingsproces tenietdoen. Precies zulke gebeurtenissen komen vaak voor in softwareprojecten. Bovendien vermenigvuldigen fouten zich vaak en leiden ze tot sunk costs of zelfs tot het mislukken van het project. Bovendien werkt de scheiding van verschillende verantwoordelijkheidsgebieden (afdelingen), als gevolg van de strikte opdeling in fasen, het ivorentoren-denken sterk in de hand.

Hieronder volgt een visualisatie van het watervalmodel op een meer praktische manier:

Het wordt duidelijk dat dit model interacties en samenwerkingen mist tussen de verschillende partijen die samenwerken aan de ontwikkeling van een oplossing of product in de verschillende fasen. Dit is waar wendbaarheid om de hoek komt kijken. Om misverstanden, complexiteit en ongeplande gebeurtenissen tegen te gaan, zijn kleine takenpakketten nodig die in korte tijdsintervallen alle relevante gebieden en partijen passeren en daardoor resulteren in directe feedbackloops. Met deze aanpak is het mogelijk om snel te reageren op obstakels van welke aard dan ook. Op deze manier kunnen de juiste oplossingen worden ontwikkeld in een complexe wereld waar voortdurend misverstanden bestaan. Dit zijn dus redenen voor agile softwareontwikkeling.

Extremistan

Zoals de kritiek op het watervalmodel laat zien, is wendbaarheid (agile) vaak nodig en vereist in softwareprojecten. Bovendien moet men het niet onder stoelen of banken steken dat bedrijven en klanten meestal niet weten wat ze precies willen, of ten onrechte denken te weten wat ze willen. De meningen van klanten kunnen onnauwkeurig of gebrekkig zijn. Daarnaast kan er ook een gebrek zijn aan methodologische competentie in het project; hier biedt de agile-aanpak zich duidelijk aan als remedie.

Deze factoren leiden tot echte (extreme) agility. Als aan het begin van het project niemand weet wat er nodig is of hoe het pad naar het eindproduct (de oplossing) eruitziet, kan er weinig of geen planning zijn. In dit geval moeten de vereisten of ontwikkelingsactiviteiten tijdens de ontwikkeling worden geïdentificeerd. Met andere woorden, pure agile softwareontwikkeling is wat je doet als je niet weet wat je doet. De volgende video illustreert pure agile softwareontwikkeling heel goed door te focussen op dit pijnpunt:

Elk model, of het nu agile of klassiek is, heeft verschillende use cases waarin zijn sterke punten naar voren komen. Het watervalmodel is geschikt voor projecten die een repetitief proces beschrijven. De repetitieve bouw van gezinswoningen is een goed voorbeeld van watervalprojectmanagement. Pure agile is de oplossing voor het realiseren van iets dat in eerste instantie extreem complex of moeilijk te definiëren is. Eigenlijk zijn deze twee use cases twee extreme punten. De meeste projecten vallen echter tussen deze twee uitersten in.

Zoals gezegd aan het begin, lijkt het soms alsof er alleen “agile” en het tegenovergestelde “not agile” is – met andere woorden, slechts twee mogelijkheden, zoals een Booleaans attribuut. Het probleem met dit hokjesdenken is dat, afhankelijk van de methode, ofwel alles rigide gepland wordt, ofwel heel weinig. Ik heb softwareprojecten gezien die het Scrum-model volgen en weigeren om aan langetermijnplanning te doen. Er wordt vaak beweerd dat langetermijnplanning niet past in de agile manier van werken en niet klassiek moet worden ontwikkeld. In deze gevallen wordt de volgende sprint vaak in detail gepland en worden de andere 2-3 sprints ruwweg ontworpen volgens de volgorde van de product backlog items. Toch zouden de meeste bedrijven die op deze manier te werk zijn gegaan, baat hebben gehad bij een langetermijnplanning.

De noodzaak van langetermijnplanning

Dwight Eisenhower zei: “Plannen is alles, het plan is niets.” Wat hij bedoelt is dat plannen vaak al achterhaald zijn op het moment dat ze gemaakt worden. Als plannen zo snel hun betekenis verliezen, waarom zou je dan plannen? Eisenhower benadrukt dat de waarde van planning ligt in het begrip en de denkprocessen die ontstaan bij de mensen die het plan ontwerpen. Het is juist dit diepe begrip dat hen in staat stelt om snel en flexibel te reageren op veranderingen, waarbij ze zich richten op de relevante doelen en kaders. Op dit punt moet ook worden vermeld dat planning geen eenmalige gebeurtenis is. Het is veeleer een continu proces dat steeds opnieuw in gang wordt gezet wanneer er voldoende nieuwe informatie beschikbaar is. Dit planningsproces stelt deelnemers in staat om op een wendbare manier te reageren.

Hoe meer je volgens plan werkt, hoe meer je krijgt wat gepland was, maar waarschijnlijk niet wat nodig is. Natuurlijk betekent deze kritiek op klassiek projectmanagement niet dat langetermijnplanning niet nuttig of onnodig is voor projectsucces. Zonder langetermijnplanning kunnen werken op een agile manier is gewoon onzin. Kortom, als iets gepland kan worden, moet het gedaan worden, maar er moet niet strikt aan vastgehouden worden als nieuwe informatie tot een betere oplossing leidt.

Oplossingen die niet kunnen worden ingeschat of gepland, vereisen pure agile softwareontwikkeling. Daarom rijst de vraag waarom de meeste IT-projecten die niet puur agile zijn, geen beginnende gedetailleerde planning hebben. Natuurlijk is er het blind volgen van richtlijnen zoals in Scrum etc., wat een gedetailleerde planning aan het begin van een project kan voorkomen. Toch is het voordeel van doordachte planning zo evident dat dit niet echt de reden mag zijn om het te verwaarlozen. Soms lijkt het alsof pure agile softwareontwikkeling slechts een noodoplossing is voor andere problemen in de meeste bedrijven.

Omdat Dwight Eisenhower al genoemd is, volgt hier een kort voorbeeld van zo’n workaround met behulp van de Eisenhower-matrix. De Eisenhower-matrix maakt in een tabel met vier velden onderscheid tussen belangrijke en dringende taken. Wat dringend is, is zelden belangrijk, en omgekeerd. Bovendien is er in de meeste bedrijven sprake van overwerk. Dit geeft aan dat er meer te doen is dan binnen de reguliere werkuren kan worden bereikt. Dit suggereert dat de focus in de meeste bedrijven ligt op dringende taken, zoals dagelijkse activiteiten, deadlines of ongeplande taken. Bovendien is het normaal dat mensen minder om de toekomst en meer om het heden geven. Bijgevolg is er in de meeste bedrijven weinig tijd voor belangrijke en niet-urgente taken, zoals echte planning.

Als er geen tijd is voor doordachte planning, is pure agile softwareontwikkeling een geschikte (passieve) maar niet optimale oplossing.

Dit is echter maar één voorbeeld van hoe pure agile softwareontwikkeling gebruikt kan worden als uitweg voor een heel ander probleem. Een andere mogelijke en veel voorkomende reden is het misverstand van het management over het eigenlijke doel van planning. Als het plan te allen tijde gevolgd moet worden en wijzigingen moeilijk zijn af te dwingen, dan is het beter om geen plan te maken om uitputtende geschillen te voorkomen. Kortom, als de echte toegevoegde waarde van planning niet kan worden waargemaakt, is het niet nodig om te plannen.

Gefaseerde Scrum – Een mogelijke oplossing voor de meeste softwareprojecten

Om een praktische en geschikte methodologie voor het softwareontwikkelingsproces te creëren, moeten de voordelen van de verschillende benaderingen worden gecombineerd. Hoe meer procesmodellen bekend zijn en begrepen worden, hoe beter een geschikte projectmanagementmethode voor het individuele en unieke project kan worden gevonden. Wanneer deze theoretische kennis wordt gecombineerd met voldoende praktijkervaring, kan echt projectmanagement ontstaan. Het laatste ingrediënt is inzicht in de heersende randvoorwaarden die richting moeten geven aan projectmanagement. Net zoals met elke persoon afzonderlijk moet worden omgegaan, moet ook met elke bedrijfscultuur anders worden omgegaan.

Laten we eens uitgaan van een omgeving waarin de waarden van dienend leiderschap worden geleefd, de mensen die betrokken zijn bij het project voldoende ervaring hebben en de doelen en functionaliteiten van de gewenste softwareoplossing grotendeels bekend zijn. Hoe moet dit project worden gemanaged?

Om een dergelijk project tot een succes te maken, is de Phased Scrum methode in combinatie met Management by Objectives (MbO) technieken een goede keuze. In deze methode zijn er grotere fasen waarin een licht aangepaste Scrum wordt gebruikt. In principe wordt Scrum gebruikt als een submethode binnen de geplande fasen. Afgezien van de initiële planningsfase zijn de fasen niet vergelijkbaar met de fasen van het watervalmodel. Dit komt omdat de fasen worden gegenereerd door een logische aggregatie van requirements en dus niets gemeen hebben met de abstracte fasen van het watervalmodel. Omdat de fasen worden gevormd uit geaggregeerde eisen, kunnen ze verschillende looptijden hebben en zijn ze altijd projectspecifiek. In tegenstelling tot het watervalmodel zijn de geplande fasen niet in steen gebeiteld. Het doel is niet om ze voortdurend te veranderen. Om de echte voordelen van planning te realiseren, moeten ze echter gemakkelijk kunnen worden aangepast aan nieuwe informatie.

Eerste planningsfase

Om de vruchten van het planningsproces te plukken, moet er worden gepland. En niet zomaar een beetje, maar alles moet doordacht zijn. Zeker, er zullen fouten zijn die later aan het licht komen, maar dat is niet het belangrijkste. Waar het om gaat is om breed en diep na te denken over wat er moet gebeuren. Er is geen kortere weg als de voordelen van het planningsproces effect moeten hebben. Anders neemt het risico om toe te geven aan het Dunning-Kruger-effect aanzienlijk toe. Als alles goed doordacht is, treedt dit effect niet alleen niet op, maar blijft men ook veel succesvoller in het omgaan met nieuwe inzichten en het aanpassen van de huidige staat van planning.

Om deze initiële planning af te ronden, kan de work-breakdown structuur worden gebruikt. De Project Management Body of Knowledge (PMBOK 5) definieert de work-breakdown structuur als een “hiërarchische decompositie van de totale hoeveelheid werk die door het projectteam moet worden uitgevoerd om de projectdoelen te bereiken en de vereiste deliverables te produceren”. Het basisconcept bestaat uit een reeks recursieve stappen waarin delen van een idee worden opgesplitst in kleinere stukken totdat de omvang van het werk of beheersbare delen zijn vastgelegd. Het resultaat is een boomstructuur die een uitsplitsing laat zien van de inspanning die nodig is om een doel te bereiken. Hiërarchische decompositie kan gebaseerd zijn op een functionele of objectgeoriënteerde kijk.

Bij het creëren van elk structureel element moeten onder andere de volgende vragen worden gesteld:

1. Lost het component een probleem op dat opgelost moet worden?
2. Zijn er afhankelijkheden van andere componenten?
3. Is de opstelling van het component correct?
4. Uit welke onderdelen bestaat het component?
5. Is er voldoende kennis om de haalbaarheid van het component te beoordelen?

Tijdens dit eerste planningsproces kan het planningsteam op onderwerpen stuiten die ze niet volledig kunnen beoordelen. In dit geval wordt al in een vroeg stadium vastgesteld waar er een gebrek is aan noodzakelijke kennis of ervaring voor de uitvoering van het project. Afhankelijk van de relevantie van de leemte in de planning en de beschikbaarheid van middelen om deze op te vullen, moet in een vroeg stadium de (economische) haalbaarheid worden beoordeeld. In principe moet elk nieuw idee op deze manier worden gecontroleerd, met uitzondering van enkele zuivere O&O-projecten.

Op basis van de (initiële) boomstructuur kunnen vervolgens de fasen worden gevormd waarin volgens Scrum wordt gewerkt. Om deze fasen te ontwerpen, moet voor elk beheersbaar element onderaan de work breakdown structure rekening worden gehouden met de vereiste vaardigheden, middelen, inspanningen en tijden en de afhankelijkheden tussen deze elementen.

Gefaseerde-uitvoering op basis van Scrum

Nadat de eerste planningsfase is afgerond en het projectplan is opgesteld, begint de implementatie. Het is mogelijk om elke fase achtereenvolgens uit te voeren. Als de afhankelijkheden en de inkapseling van de fase-inhoud het toelaten zonder al te veel risico te nemen, kunnen meerdere fasen ook tegelijkertijd worden uitgevoerd.

Scrum wordt gebruikt voor het realiseren van fasen. We zullen hier niet uitleggen hoe Scrum werkt. Niettemin moet de focus liggen op samenwerking tussen afdelingen, het vroegtijdig ontdekken van uitdagingen van welke aard dan ook en het continu leveren van gevalideerde toegevoegde waarde. Het is echter geen pure agile softwareontwikkeling, aangezien alle vereisten en implementatieplannen steeds op een (redelijk) diep niveau worden uitgewerkt. Alleen nieuwe informatie kan leiden tot een herstructurering van de planningsaanpak.

Conclusie

Softwareontwikkeling gaat meestal niet over het schrijven van broncode op zich. Het gaat in wezen om het uitzoeken wat je moet doen, hoe je het moet doen en hoe je het op een uitbreidbare en efficiënte manier kunt implementeren. Daarom is het zinvol om hier goed over na te denken voordat je de eerste regel broncode schrijft. Daarom is de eerste planningsfase belangrijk voor de meeste projecten. Natuurlijk is het niet nodig om van de eerste tot de laatste stap vast te houden aan het oorspronkelijke plan. In plaats daarvan moet het plan worden aangepast in het licht van nieuwe bevindingen, zodat optimale oplossingen kunnen worden ontwikkeld (rolling planning).

Bij het realiseren van logisch gebundelde takenpakketten (fasen) moet de ontwikkeling heel dicht bij Scrum of vergelijkbare methodologieën liggen om de complexiteit ervan aan te kunnen. In principe worden veel subprojecten gecreëerd en gepland vanuit één project. De resultaten van elk subproject beïnvloeden elkaar en deze worden van elkaar ingekapseld zodat de beste oplossing flexibel als geheel kan worden ontwikkeld. Het is een agility-georiënteerde “verdeel en heers” methodologie. In zekere zin wordt het Scaled Agile Framework (SAFe) toegepast op slechts één project, met als sleutel tot succes een diepe en brede continue planning. Tot slot nog een boekentip: Project Phoenix: De roman over IT en DevOps.