Waarom komen softwareprocesverbeteringen in de praktijk zo slecht van de grond? Een belangrijke oorzaak is de gehanteerde aanpak. Die past veelal niet bij de uitgangssituatie van de organisatie, aldus een adviseur procesverbetering. Hij schetst een methode die gebruik maakt van CMM, en waarbij belangrijke plaatsen zijn weggelegd voor een betrokken management en teamworkshops.
Zelden haalt een project de doelstelling: betrouwbare software, op tijd en binnen budget. Veel initiatieven vinden plaats om de prestaties te verbeteren. Na de eerdere focus op methoden, technieken en tools, staat sinds een aantal jaren het proces in de aandacht. Software Process Improvement (SPI) wordt gezien als een van de structurele oplossingen in de strijd tegen de softwarecrisis. Een van de belangrijkste wapens in deze strijd vormt het Capability Maturity Model voor Software (SW-CMM), ontwikkeld door het Software Engineering Institute (SEI). Het SW-CMM kent verschillende volwassenheidsniveaus voor processen, oplopend van niveau 1 (onvolwassen) tot niveau 5 (zeer volwassen) en is een van de meest gebruikte modellen om de procesverbetering binnen softwareorganisaties vorm te geven.
Het daadwerkelijke resultaat van de inspanningen voor procesverbetering voldoet echter vaak niet aan de verwachtingen. Van de software organisaties in Nederland heeft de overgrote meerderheid de intentie om de processen te verbeteren. Naar schatting 20 tot 30 procent is hiermee structureel aan de slag. Het aantal organisaties dat daadwerkelijk op volwassenheidsniveau- 2 of hoger van het SW-CMM opereert, is nog steeds op de vingers van twee handen te tellen.
Ondanks een oprechte intentie blijkt dat de procesverbeteringen in de praktijk vaak niet van de grond komen. Een van de belangrijkste oorzaken hiervan is gelegen in de gehanteerde aanpak.
Standaard SPI-recept
Organisaties die iets aan SPI doen, gaan vaak te werk volgens een standaard recept. Hierbij komt een aantal elementen altijd terug. Er worden één of meerdere modellen gekozen als leidraad voor de procesverbeteringen. De laatste jaren is vooral het CMM erg in opkomst, maar ook de ISO-normen worden veelvuldig gebruikt. Daarnaast zijn altijd wel enkele managementconcepten in de mode waarvan de organisatie een graantje mee probeert te pikken. Total Quality Management (TQM) is hiervan een goed voorbeeld.
Na keuze voor het model (‘we gaan CMM invoeren’) volgt een standaard projectaanpak zoals die in de literatuur wordt beschreven. Het verbetertraject wordt als een organisatiebreed project opgezet. Er wordt een projectplan opgesteld, het doel wordt geformuleerd, mijlpalen worden gedefinieerd. Vaak wordt het doel verwoord als ‘het voldoen aan CMM niveau 2’. Een structuur van stuurgroepen en werkgroepen wordt in het leven geroepen. Elke werkgroep gaat organisatiebreed aan de slag met een deelproces.
Deze werkwijze wordt veelvuldig gepredikt in de literatuur en op seminars. Ook het SEI beschrijft een dergelijke werkwijze in het door hen ontwikkelde Ideal-model. Met dit model wordt een methode van verbeteren beschreven. In Ideal-terminologie worden onder andere een Management Steering Committee (MSC), een Software Engineering Process Group (SEPG) en Technical Work Groups (TWG) in het leven geroepen.
Veelvuldig wordt gebruik gemaakt van de diensten van interne of externe consultants. Zij geven adviezen en verzorgen trainingen. Eventueel nemen zij ook de rol van SPI-projectleider op zich.
Doemscenario
In de praktijk blijkt de beschreven werkwijze lang niet altijd tot het gewenste resultaat te leiden. Het vermogen om goede ideeën om te zetten in daadwerkelijke verbeteringen ontbreekt. Wat we zien is dat men vol goede moed begint, maar dat het project na enige tijd stilvalt door gebrek aan betrokkenheid op alle niveaus. In dit doemscenario vallen enkele aspecten op.
Uit de formulering van de te bereiken doelen is vaak niet af te leiden wat realisatie hiervan concreet betekent. Niet zelden wordt het middel verheven tot doel (‘we gaan CMM niveau-2 invoeren’). Hierin schuilt ook het gevaar van verbeteren door het afvinken van checklists. Het is moeilijk mensen echt te mobiliseren voor iets wat niet direct vertaald kan worden naar verbeteringen in de eigen werksituatie. Dit geldt zowel voor het management als voor de software-engineers.
Als geprobeerd wordt een verbetering daadwerkelijk in te voeren, stuit men vaak op weerstand vanuit de organisatie. De verbetering sluit niet goed aan op de huidige werkwijze; de stap is te groot. De werkgroep heeft een ideale situatie uitgewerkt zonder rekening te houden met de (on)mogelijkheden van de huidige stand van zaken. Ook het ‘not-invented-here’ syndroom komt nogal eens voor, omdat lang niet iedereen betrokken is bij de totstandkoming van de verbeteringen.
Toezegging (‘making and breaking the rules’) wordt pas verkregen als degene die tosstemming moet geven de vraag kan beantwoorden: Wat levert het me op? Op managementniveau betekent dit dat een SPI-project gerechtvaardigd dient te worden door een vooruitzicht op betere bedrijfsresultaten. De specifieke relatie van het SPI-project met het bedrijfsresultaat is vooraf echter moeilijk zichtbaar te maken. Als kapstok hiervoor wordt grif gebruik gemaakt van de cijfers die grote organisaties hierover hebben gepubliceerd. Als na enige tijd de relatie met de eigen bedrijfsresultaten niet zichtbaar gemaakt kan worden, verdwijnt SPI van de prioriteitenlijst van de manager (‘SPI is wel nuttig, als het maar niet teveel tijd en geld kost’). Het ontbreken van echte betrokkenheid van het management stuurt vervolgens de prioriteiten van iedereen binnen de organisatie.
Softwareontwikkelaars willen in eerste instantie graag meewerken om de procesvolwassenheid naar een hoger niveau te tillen. Vol enthousiasme gaat men aan de slag in diverse werkgroepen die buiten het eigen project functioneren. Deelname hieraan is meestal een parttime aangelegenheid. De eigen werksituatie blijft ondertussen ongewijzigd. Als na enige tijd de verbeteringen waar ze aan hebben meegewerkt niet kunnen worden ingevoerd, gaat de animo er snel af. De operationele projectdruk is groot, en dus kunnen ze hun tijd wel beter besteden.
Mede door gebrek aan enthousiasme en visie vanuit de top, zien het middenmanagement en de software-engineers SPI als iets dat naast de toch al zeer drukke werkzaamheden moet plaatsvinden. Inspanning voor het SPI-project wordt niet meegenomen in de algehele beoordeling van de medewerkers. Verantwoordelijkheidsgevoel, enthousiasme en initiatief voor SPI activiteiten verschuiven daardoor grotendeels naar stafafdelingen of externe consultants. In de projecten wordt dan ook geen kennis en ervaring met betrekking tot procesverbetering opgebouwd, terwijl daar juist de verbeteringen moeten worden ingevoerd.
Oorzaken voor mislukking
Het zal duidelijk zijn dat het hiervoor beschreven scenario hoogstwaarschijnlijk zal leiden tot mislukking van het SPI-traject. Waarom gaat het dan verkeerd? De gehanteerde aanpak wordt immers veelvuldig beschreven in de literatuur, en ook met het CMM als model is weinig mis. Het antwoord hierop is simpel: de gehanteerde aanpak past niet bij de uitgangssituatie van de organisatie.
Het overgrote deel van de organisaties gaat een SPI traject in vanuit een situatie waarbij de huidige processen onvolwassen zijn. In CMM-termen zitten de meeste organisatie op niveau-1 en willen ze naar niveau-2. In een niveau-1 organisatie kunnen projecten niet efficiënt worden uitgevoerd. De organisatie leert moeilijk en is vooral bezig met brandjes blussen. In het algemeen heeft men weinig tot geen ervaring met succesvolle procesverbetering. Je kunt je dus serieus afvragen of een onvolwassen organisatie in staat zou zijn om een groots opgezet SPI-project tot een goed einde te brengen. In de CMM-filosofie wordt hiermee rekening gehouden: pas op niveau-3 worden organisatiebrede verbeteringen doorgevoerd. Op lagere niveaus vinden verbeteringen lokaal binnen de projecten plaats. Vaak wordt dit gezien als een sub-optimale oplossing: het wiel zal waarschijnlijk meerdere keren in verschillende projecten worden uitgevonden. Daarom starten veel organisaties toch een SPI-project waarbij centraal verbeteringen worden doorgevoerd. Met andere woorden: veel organisaties hanteren een niveau-3 aanpak om niveau-2 problemen te lijf te gaan.
Procesverbetering is een leerproces op zichzelf. In de gehanteerde aanpak wordt hiermee vaak geen rekening gehouden. Impliciet wordt verondersteld of als randvoorwaarde aangegeven dat men weet wat procesmatig werken inhoudt, dat men verbeteren ziet als onderdeel van de dagelijkse werkzaamheden en dat degenen die verantwoordelijk zijn zich ook verantwoordelijk voelen. Juist in een organisatie met lage procesvolwassenheid zal men hierin moeten groeien.
Het beeld dat naar voren komt is dat de aanpak van procesverbetering samenhangt met de procesvolwassenheid van een organisatie. In de beschikbare SPI-literatuur wordt hierover weinig geschreven. Vrijwel alle literatuur gaat uit van een variant van de beschreven organisatiebrede projectaanpak. Een belangrijke oorzaak hiervoor ligt in de oorsprong van de beschikbare informatie. Vaak komen SPI-publicaties van grote organisaties die zelf al een bepaalde mate van procesvolwassenheid (niet specifiek op software-gebied) hebben. Verder zijn de gebruikte veranderingsmodellen vaak niet speciaal voor SPI ontwikkeld. Bijvoorbeeld het door het SEI ontwikkelde Ideal-model is zwaar beïnvloed door ervaringen met technology transfers bij Bell Labs en minder door specifieke SPI-ervaringen.
Alternatieve SPI-aanpak
De standaard SPI-aanpak werkt dus vaak niet in organisaties met een lage procesvolwassenheid. Toch zijn er wel degelijk gereedschappen beschikbaar ook in deze organisaties een SPI traject tot een succes te maken. Het zijn geen revolutionaire nieuwe concepten: ze worden in andere context veelvuldig toegepast. Het belangrijkste element vormt de expliciete keuze voor lokaal verbeteren in de projecten. Ondersteunende instrumenten zijn in dit geval het houden van teamworkshops en het hanteren van timeboxing.
Bij de keuze voor lokaal verbeteren in de projecten – als tegenhanger van het organisatiebreed verbeteren – worden geen speciale projectstructuren opgezet voor het verbetertraject. In plaats daarvan maakt men gebruik van de bestaande organisatiestructuur. De stuurgroepfunctie wordt uitgeoefend door het management, de werkgroepfunctie door de verschillende bestaande teams. Elk team gaat dus aan de slag met de problematiek in het eigen project.
Deze werkwijze heeft enkele belangrijke voordelen. De verantwoordelijkheid voor procesverbetering wordt daar gelegd waar deze thuishoort: bij het management en in de teams. De rol van de stafafdelingen en externe consultants wordt meer faciliterend. De rol van het management is die van het ontwikkelen van visie en het geven van duidelijke kaders. De teams werken zelf aan de oplossing van de eigen problematiek. Dit verhoogt de betrokkenheid en verkleint de kans dat een oplossing niet aansluit bij de praktijk. Een ander voordeel is dat er minder communicatielijnen zijn, wat de kans op communicatiestoornissen aanzienlijk kleiner maakt. In de teams kan kennis en ervaring op het gebied van procesverbetering worden opgebouwd.
Om de teams daadwerkelijk aan het werk te zetten, wordt gebruik gemaakt van ééndaagse teamworkshops. Hierbij gaan de teams aan de slag met de processen zoals die in de eigen werksituatie worden toegepast. Uitgaande van een herkenbaar weergegeven ideale situatie (bijvoorbeeld CMM niveau-2) kijkt men waar de eigen processen nog te verbeteren zijn. Aan het eind van de workshop zijn concrete actieplannen beschikbaar; de volgende dag kan al begonnen worden met de uitvoering hiervan.
Het grootste voordeel van het gebruik van deze teamworkshops is de aansluiting bij de praktijksituatie. Het concrete karakter van de actieplannen maakt het mogelijk meteen aan de slag te gaan. De verbeteringen hebben de juiste focus: het gaat uiteindelijk om het verkrijgen van betere teamresultaten. Om deze focus op het vizier te houden is het essentieel niet teveel theorie de revue te laten passeren. Theorie is alleen nodig om een universele kapstok te hebben waaraan alle verbeteringen kunnen worden opgehangen. Zo kan het CMM structuur geven aan de verbeteringen. Een korte behandeling van de essentie van de gekozen modellen in de workshop is hiervoor voldoende. Op deze manier kan de discussie zich richten op de verbeteringen in plaats van op de modellen. Het motto is dan ook: doen in plaats van praten!
Een vorm van timeboxing leent zich goed als hulpmiddel bij het behalen van concrete resultaten met behulp van de workshops. Kernpunt hierin is dat iedere vier à zes weken opnieuw een planning wordt gemaakt voor verbeteringen in de komende periode. De verbeterpunten gelden als korte-termijn doel. Elk verbeterpunt draagt bij aan een geformuleerd lange-termijn doel. Zo wordt de juiste richting aan de verbeteringen gegeven. In een CMM-verbetertraject zullen deze lange-termijn doelen na verloop van tijd evolueren naar de doelen zoals die in CMM worden beschreven. Voor iedere nieuwe timebox wordt de vraag beantwoord wat de komende timebox-periode gedaan kan worden om naar de korte termijn doelen toe te werken. Het resultaat hiervan is een lijst met concrete acties.
Voordeel van deze werkwijze is dat er geen gat ontstaat tussen de vele goede ideeën en de invoering hiervan. Er worden kleine concrete stappen genomen, waarvan iedereen op korte termijn het resultaat kan zien. Omdat op regelmatige basis de plannen worden bijgesteld, blijven de procesverbeteringen leven binnen het team en blijven de plannen ook realistisch. Op deze manier wordt procesverbeteren steeds meer routine. Tevens geeft het cyclische karakter een team de gelegenheid om te leren. De plannen zullen met iedere iteratieslag realistischer worden.
Weinig ervaring
In de beschreven aanpak wordt teruggegaan naar een basale wijze van procesverbetering. Het CMM wordt teruggebracht tot wat het eigenlijk is: een gezamenlijk gesprekskader en een meetlat in plaats van een doel op zich. Via een no-nonsense benadering wordt heel concreet naar resultaat gewerkt. Verschillende organisaties hebben deze SPI-werkwijze reeds succesvol toegepast. Op basis hiervan heeft AAS de beschreven concepten gecombineerd tot een complete SPI-methodiek.
Deze bevat geen nieuwe revolutionaire concepten. In de algemene literatuur zijn alle besproken zaken terug te vinden. Bij SPI-trajecten worden deze concepten nog zelden op deze manier toegepast. De belangrijkste reden hiervoor is dat SPI nog een jonge tak van sport is. De ervaring met het gebruik van verschillende hulpmiddelen en tools is beperkt. Het aantal organisaties dat hierover publiceert is zo mogelijk nog beperkter. Juist deze organisaties bepleiten vaak een centrale projectaanpak. Redelijkerwijs mag verwacht worden dat SPI de komende jaren meer en meer volwassen zal worden. De beschikbare hulpmiddelen en tools zullen meer divers en uitgekristalliseerd zijn. Het algemeen besef dat er meerdere wegen naar procesvolwassenheid leiden zal niet lang meer op zich laten wachten. Succes met SPI kan dus inderdaad een keuze zijn.
M.A.G. van Zelst, adviseur Alert Automation Services
Literatuur
Mastenbroek, W.: Verandermanagement, Holland Business Publications, Heemstede, 1997
SEI: The Capability Maturity Model, Guidelines for Improving the Software Process, Addison Wesley, Boston, 1995
Curtis, B.: The pitfalls of level 3 approaches to level 2 problems, SPI ’99 keynote presentation, Barcelona, 1999
