CMMI is dood, problemen zijn springlevend

11 juli 2014

De laatste jaren hebben veel organisaties grote investeringen gedaan om hun processen op orde te krijgen. CMM en later CMMI waren daarin een belangrijk hulpmiddel, en veel organisaties hebben duizenden tot soms wel miljoenen euro’s uitgegeven in het streven de verschillende CMMI-niveaus (met niveau 5 als ‘walhalla’) te bereiken.

Nu, vele jaren en bakken geld later, zijn we er in de praktijk nog maar zelden in geslaagd het kunstje goed onder de knie te krijgen. Softwareprojecten zijn nog vaak te duur, te laat of van slechte kwaliteit. Ook de overheid komt nog regelmatig tot de pijnlijke conclusie dat haar investeringen geleid hebben tot dergelijke projecten. De hoorzittingen van de tijdelijke commissie ICT zijn hier een voorbeeld van.

Kortom, we zijn nog steeds druk bezig om een acceptabele balans te vinden tussen functionaliteit, kwaliteit, snelheid en kosten. Daar is de laatste 25 jaar al veel aandacht aan besteed, maar de uitdagingen liggen er, als we eerlijk zijn, nog steeds. CMMI heeft weliswaar veel bijgedragen, maar is tegelijkertijd op het vlak van dossiervorming zwaar uit de bocht gevlogen. Door CMMI is er helaas te veel focus komen te liggen op procesbeschrijvingen, ten koste van procesuitvoering en -verbetering.

Eigen schuld

Misbruik ligt natuurlijk nooit aan het hulpmiddel, maar aan de gebruikers ervan. Echte vaklui geven nooit hun gereedschap de schuld. Uiteindelijk zijn wij zelf de professionals die het werk doen. Tegelijkertijd is het natuurlijk wel zo, dat sommige hulpmiddelen een bepaald misbruik lijken uit te lokken.

Bij CMMI is dat het overdreven focussen op standaardprocessen en documentatie, waardoor het resultaat uit het oog wordt verloren. Een briljant proces garandeert tenslotte geen briljante producten. Bovendien is de praktijk tegenwoordig zo dynamisch dat deze standaardprocessen vaak niet voldoen en er dan lokale oplossingen of aanpassingen nodig zijn. Echter, die ruimte wordt niet aan de teams gegeven omwille van standaardisatie en procescompliancy. Het leidt tot: operatie geslaagd, patiënt overleden.

Vooral het assessmentproces van CMMI (Scampi) leidt tot een overmaat aan dossiervorming en bureaucratie, ook al is dat nooit de bedoeling geweest van het oorspronkelijke model en gedachtegoed van Watts Humphrey (de oorspronkelijke bedenker van CMMI). Daarnaast zitten er in CMMI details die voor een specifieke omgeving simpelweg niet belangrijk of niet van toepassing zijn, maar om het CMMI-level te halen wordt daar dan wel actie op ondernomen. Hoe mooi was het om als CIO te kunnen claimen dat je de organisatie in recordtempo op level 3 hebt gekregen?

Bovendien is CMMI ontstaan in de tijd dat de dynamiek nog niet zo groot was als nu. Daardoor had je tijd om vooraf na te denken en kreeg je genoeg tijd om bevindingen op te pakken. CMMI gaat er impliciet toch op een bepaalde manier vanuit dat je het probleem beter op kunt lossen door vooraf beter na te denken over details en door processen in veel detail vooraf op te zetten. Helaas weet je vooraf het minste. Iteratief op zoek gaan naar goede oplossingen via gecontroleerde experimenten en het verzamelen van data (de hogere CMMI-levels 4 en 5) werkt niet goed bij lange cycli omdat je dan je meetgegevens veel te laat krijgt. En korte cycli en iteratief werken waren geen gemeengoed ten tijde van de brede toepassing van CMMI.

Agile

Velen vinden nu een oplossing in het agile werken, vaak via het toepassen van Scrum. Enerzijds logisch doordat korte cycli je sneller laten leren. Anderzijds doordat de huidige dynamiek en snelheid van de markt vragen dat je meebeweegt. Een plan maken en ervan uitgaan dat er het komende jaar niets verandert, is utopisch en naïef.

Maar ook agile is niet heilig. Scrum is niet de heilige graal die al je problemen oplost. We zien in de praktijk veel organisaties die Scrum maar half doen waardoor het niet werkt. En ook hier wordt dan de schuld aan het hulpmiddel gegeven. Agile werken is lastig en we zien in de praktijk veel organisaties die een waterval ‘omScrummen’, maar het blijft een waterval. Kenmerken hiervan zijn dat er nog steeds gestuurd wordt op een eindresultaat. Aan het einde is het klaar. Echter, dit staat haaks op de basisideeën van Agility: wendbaarheid. De enige manier om echt wendbaar te zijn is te zorgen dat alles wat je doet direct af is. Helaas lukt het veel organisaties niet om dat voor elkaar te krijgen en heeft men de illusie dat het volgen van de Scrum-rituelen je wendbaar maakt. Wat uiteraard onzin is.

Daarnaast zien we in de praktijk veel organisaties die hun waarde leveren in een keten. Diezelfde organisaties zien we tegelijkertijd hun Scrum-teams inrichten per schakel. Het gevolg is dat het nog steeds lang duurt voordat over de keten verbeteringen echt merkbaar worden, en dat de complexiteit van de keten dus niet vermindert, maar juist bestendigt. Waar CMMI het creëren van heel veel documentatie uitlokt, lokt Scrum de focus op individuele teams uit, en wordt de keten daardoor uit het oog verloren. Met alle gevolgen voor tijd, kwaliteit en kosten.

Organisaties kunnen het niet laten om in projecten te blijven denken en steeds wisselende teams in deeltijdbezetting aan een probleem te laten werken. Ze maken niet de stap naar stabiele cross-functionele teams waar het werk naartoe stroomt. En daarnaast zien we in de praktijk dat als reactie op de veel te vergaande governance bij CMMI, dit bij agile vaak gecompenseerd wordt door helemaal geen governance. Met alle negatieve gevolgen van dien.

Technologie

Zowel Scrum als CMMI kijken eigenlijk alleen maar naar ‘people’ en ‘processen’. Het is bijzonder te zien dat beide de technische dimensie grotendeels negeren. En dat is vreemd, want ons vak is juist technologie. Waarom laten we dat buiten beschouwing? Het is dan ook niet verwonderlijk dat de laatste tijd de term DevOps steeds meer gebruikt wordt, omdat deze beweging heel gericht bezig is om ook de technologiecomponent aandacht te geven, en de hele ontwikkelketen vergaand te automatiseren. Extreme programming (XP) krijgt daarmee ook weer de aandacht die het verdient. Test Driven Development, Continuous Integration en Pair Programming zijn namelijk essentieel. Software-ontwikkeling is immers een technisch vak.

Samenvattend hebben we, ondanks alle goede bedoelingen, de afgelopen jaren geleerd dat CMMI meestal niet de oplossing is in de huidige dynamische tijd waarin we complexe problemen aan het oplossen zijn. Scrum werkt in dergelijke situaties beter, mits juist toegepast. Dat juist toepassen is lastig omdat het in eerste instantie pijn doet, en wij in veel organisaties juist pijn proberen te maskeren.

Uiteindelijk zijn het de mensen die het hem doen. Een hamer slaat de ruit niet kapot. Dat doet de persoon die de hamer vasthoudt. De originele intentie van Watts Humphrey met Project Planning in CMMI was juist om de planning in de handen van ontwikkelaars te leggen. Helaas was de implementatie in de praktijk dat men voor planning projectmanagers ging neerzetten. Scrum beschrijft precies wat Humphrey oorspronkelijk wilde bereiken. Maar ook nu al worden basisprincipes van Scrum in de praktijk met voeten getreden. Met als resultaat nog steeds dezelfde problemen: te duur, te laat en niet goed. Het lijkt een kwestie van tijd totdat Jeff Sutherland en Ken Schwaber (de bedenkers van Scrum) daar de schuld van zullen krijgen.

Vijf acties

  1. Kijk naar de keten. Leer van CMMI om het geheel te optimaliseren, niet alleen de delen.
  2. Maak heldere werkafspraken. Ook bij Scrum moet je governance inrichten. Maak geen dikke handboeken, maar hang werkafspraken op de muur.
  3. Richt de technische kant in. Een volledig set ontwikkeltools, automatisch testen en continuous deployment vragen aandacht en investering. Scrum is meer dan rollen, gele briefjes en stand-ups.
  4. Hou zicht op het waarom. Focus op het bereiken van echte doelen: tevreden klanten en gebruikers, door tijdig, voor niet te veel geld, problemen goed weg te nemen. Wees alert dat de methode nooit een doel wordt. Dat hebben we van CMMI kunnen leren en die les moeten we bij Scrum niet vergeten.
  5. Gebruik je verstand. Als het ongemakkelijk voelt en niemand snapt het nut, doe het dan niet. A fool with a tool, is still a fool.
 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Login

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Activeer dan nu je account!