Aanpak voor het kiezen van de juiste software ontwikkelmethode

Veel organisaties kiezen voor nieuwe, agile software ontwikkelmethoden. Zij willen daarmee de slagingskans van hun projecten vergroten. Gevraagd naar de aannames hierachter komen betrokkenen vaak niet verder dan ‘omdat iedereen dat nu eenmaal doet’. Dat is zonde, stelt Joop Rasser, als Programmamanager verbonden aan Verdonck, Klooster & Associates. In dit artikel gaat hij in op hoe IT-managers tot de juiste keuze voor een ontwikkelmethode kunnen komen.

Met een dergelijke platte keuze voor agile wordt voorbijgaan aan de vraag of de desbetreffende methode wel aansluit bij het probleemgebied, de karakteristieken en de waarden van de eigen organisatie, zoals organisatievorm, cultuur en de wijze van aansturing van medewerkers. Een organisatie kan in de praktijk veel voordeel halen door een ontwikkelmethode te kiezen die goed bij de eigen karakteristieken en waarden past.

Om te kunnen komen tot een goede keuze wordt regelmatig gebruik gemaakt van twee van de bekendste methoden, te weten klassieke waterval en Agile Scrum. Daarna is de aard van het probleemgebied en de te selecteren oplossing van belang. Om tot slot te eindigen met de projectie van twee stereotype organisaties op deze methoden en vast te stellen wat dit betekent voor de aansturing van medewerkers in organisaties.

Software ontwikkelmethoden
De klassieke software ontwikkelmethode waterval komt uit de jaren tachtig, toen het ontwikkelen van software een grote vlucht nam. De waterval methode was tot voor kort de meest gebruikte software ontwikkelmethode. Deze methode zorgt ervoor dat de ontwikkeling van een informatiesysteem regelmatig vloeiend (naar beneden) verloopt (als een waterval).

Voor de ontwikkeling van het nieuwe systeem wordt een aantal fasen doorlopen, namelijk die van definitiestudie/analyse, basisontwerp, technisch ontwerp/ detailontwerp, bouw, testen, integratie en beheer en onderhoud. Karakteristiek voor deze methode is een duidelijke hiërarchische structuur van globaal naar gedetailleerd, waarin documentatie een zeer belangrijke rol heeft. De methode was met name bij stuurgroepen zeer populair vanwege het feit dat het exact voorschrijft wanneer welke processtappen worden gezet, in een strikt geplande volgorde. Het geeft op basis van deze documentatie veel houvast voor de besturing van het project.

De Agile software ontwikkelmethode Scrum is halverwege de jaren negentig ontstaan door de behoefte van organisaties om beter te kunnen anticiperen op veranderingen in hun omgeving. Traditionele software ontwikkelmethoden als de waterval methode werden ervaren als te traag en zouden de creativiteit en effectiviteit van software ontwikkelaars belemmeren. De kracht van Agile schuilt in het feit dat de methode er op gericht is om zich snel aan te passen aan de veranderende werkelijkheid. De karakteristieken voor deze methode worden beschreven door het zogenaamde Agile manifest waarin de totstandkoming van het werkende product, de interactie van het projectteam en de samenwerking met de gebruiker centraal staat.

Probleemgebied en oplossing
Van belang bij het kiezen voor een software ontwikkelmethode is de bewustwording van het probleem dat moet worden opgelost alsmede de mogelijke oplossing. Dit bepaalt in grote mate het succes van het te voeren project. De afbeelding maakt duidelijk dat de bekendheid met het probleemgebied van belang is voor de keuze en mogelijk voor handen zijnde oplossingen.

Zo is het oplossen van problemen rond de processen van een personeelsinformatie-systeem tegenwoordig niet meer bijzonder waardoor voor dit bekende probleem een veelheid aan standaardpakketten (bekende oplossing) voor handen is. De klassieke software ontwikkelmethode waterval biedt zodoende een goede oplossing. Wanneer de personeelsproblematiek echter dusdanig complex blijkt te zijn dat dit om een nieuw soort oplossing vraagt, is het verstandig te werken met behulp van de software ontwikkelmethode Agile Scrum.

Ontwikkelmethode en organisatie
Als je de karakteristieken van deze twee meest gekozen software ontwikkelmethoden waterval en Agile Scrum loslaat op de karakteristieken van twee stereotypeondernemingen dan kun je inzichtelijk maken wat de invoering van een software ontwikkelmethode betekent voor een organisatie alsook de aansturing van de medewerkers. De volgende stereotype ondernemingen worden in dit voorbeeld gehanteerd:

• de meer kleinschalige organisatie met een platte hiërarchische structuur en korte lijnen (Rijnlandsmodel);
• de grote beursgenoteerde danwel overheidsorganisatie met duidelijke hiërarchische aansturing (Angelsaksische model).

In onderstaande tabellen zijn de karakteristieken van deze organisatiemodellen op de reeds beschreven ontwikkelmethode klassiek waterval en Agile Scrum geprojecteerd. Hierdoor valt beter te begrijpen wat de gevolgen van de keuze voor een methode zijn voor een organisatie en de aansturing van de medewerkers.

Kleinschalige organisatie
Zoals blijkt uit bovenstaande tabel zijn kleinschalige organisaties goed in staat om de methode Agile Scrum toe te passen. Dit komt doordat de structuur, cultuur, sturing en organisatie overeenkomen. Wanneer deze organisaties gaan werken volgens de methode waterval ontstaan er duidelijke aandachtsgebieden. Immers, medewerkers die een platte organisatie gewend zijn met korte communicatielijnen komen terecht in een meer hiërarchische projectorganisatie waarbij het takenpakket van de betrokken teams, werkgroepen en stuurgroep duidelijk is afgebakend. Dit doet afbreuk aan het zelfsturend vermogen en de korte lijnen binnen deze organisatie.

Bureaucratische organisatie
Zoals blijkt uit bovenstaande tabel zijn grotere bureaucratische organisaties eerder geneigd om de waterval methode toe te passen. Dit komt doordat de gefragmenteerde organisatievorm, de wijze van aansturen, de cultuur en de structuur eerder vragen om een ontwerpgerichte benadering. Wanneer deze organisaties gaan werken volgens de Agile Scrum methode is dat relatief eenvoudig voor duidelijke afgebakende aandachtsgebieden zoals productontwikkeling. Voor gebieden met een hoge complexiteit en gefragmenteerde afhankelijkheden is de balans tussen ontwerpgericht werken en Agile teamwork complex. Cultuur en routines zijn daarbij een extra complicerende factor. Immers, managers en medewerkers die een hiërarchische organisatie gewend zijn, komen terecht in een omgeving van kleine gelijkwaardige zelfsturende teams waarbij het zelfinitiatief en de veranderbereidheid centraal staan. Deze medewerkers moeten hierin gecoached worden. Het management zal anders gaan opereren: meer kaderstellend, minder inhoudelijk. Het projectteam zal zich anders verantwoorden: meer op basis van waarde en minder op basis van budget en formatie.

Bovenstaande tabellen laten zien dat de aspecten sturing, structuur en cultuur van een organisatie duidelijke consequenties hebben voor en een rol spelen in de te kiezen software ontwikkelmethode. Al was het alleen maar om duidelijk te maken op welke aandachtsgebieden coaching en begeleiding van de medewerkers nodig is!

Joop Rasser heeft sinds 1990 tientallen projecten begeleid, veelal op het gebied van software ontwikkeling. De laatste jaren richt Rasser projecten in op een Agile wijze, vaak conform Scrum.Ook helpt en adviseert hij organisaties bij de inrichting van project- en programmamanagement.