NetCare logo

Agile, Scrum en de methode doet het nog steeds niet

http://www.zbc.nu/ict/informatiemanagement-ict/agile-scrum-en-de-methode-doet-het-nog-steeds-niet/

Agile, Scrum en de methode doet het nog steeds niet

 

Het aantal ICT-projecten dat mislukt, is in de afgelopen 30 jaar redelijk constant op 70% blijven liggen. Het is dan natuurlijk een verademing als er ineens een frisse wind gaat waaien. En dat gebeurt, in de vorm van Agile en met name Scrum. Tijd om even stil te staan bij wat Agile is en voor welke problemen het een oplossing is.

In 1982 schreef Jaap van Rees in het maandblad Informatie zijn roemruchte artikel: ‘De Methode doet het niet’. Daarmee zette hij zich doelbewust af tegen het mechanisch toepassen van een methode, in dit geval het SDM van Pandata, dat in die tijd werd gezien als dé methode voor systeemontwikkeling in Nederland. Nadien zagen nog andere methoden het licht, zoals bijvoorbeeld Prince2, ITIL, BiSL, ASL, die door vele organisaties tot de heilige graal werden verklaard, maar die weinig succesvol bleken. Natuurlijk hebben SDM en soortgelijke methoden er aan bijgedragen dat onbetrouwbare ICT-dienstverlening aan klanten meer werd gestructureerd. Je kunt echter ook zeggen, dat de ICT-dienstverlening gebaseerd op ‘het onmogelijk doen we direct; wonderen duren iets langer’ werd omgevormd tot een ’permanente stiptheidsactie’. En dat betekende veel bureaucratie, hoge kosten en weinig klanttevredenheid. Eigenlijk is het verbazingwekkend, dat niemand echt heeft onderkend wat de gemeenschappelijke faalfactor was van al deze methoden. De ICT-dienstverlening werd steeds minder gericht op het realiseren van business doelen, maar werd uitgekleed tot dienstverlening ‘conform to specifications’.

Wel wat ik vroeg maar niet wat ik bedoelde

In de jaren 80 en 90 heb ik namens Pandata en later Capgemini bij diverse klanten de implementatie van SDM mogen begeleiden en ook heb ik veel cursussen gegeven. Toen al was één van mijn statements: ‘SDM betekent eigenlijk alleen: Bezint eer gij begint. Om er een boek van te kunnen maken en dat voor bijna 100 gulden te kunnen verkopen, is er echter nog wat tekst omheen verzonnen’. Pas nu besef ik hoe juist deze typering was. Met de bijbel van SDM in de hand werden in eerste instantie de behoeften van gebruikers verkracht tot iets wat een functioneel ontwerp werd genoemd en de gebruikers moesten maar geloven, dat via allerlei modelleringstechnieken hun behoeften werden afgedekt. En natuurlijk moesten die gebruikers tekenen voor akkoord, want anders gebeurde er vervolgens niets meer. Al gauw deed dan ook de volgende spotprent in allerlei variaties de ronde:

tree-swing

Natuurlijk kenden we als implementatieconsultants deze valkuilen. We hadden er ook workarounds voor. Maar het kwaad was geschiedt. Weliswaar werd het principe van ‘bezint eer gij begint’ ingevoerd, maar de ICT-dienstverlening middels projecten ging kapot aan de bijverschijnselen. En het belangrijkste neveneffect was, dat de klant kreeg wat hij vroeg en dat was vrijwel nooit wat hij bedoelde. De ICT’er beschouwde dat als het probleem van de klant. Hij had toch geleverd wat de klant vroeg? (Zie ook ‘Dit is typisch een antwoord dat alleen een ICT-er kan geven’.) Kwaliteit wordt doorgaans gedefinieerd als het voldoen aan overeengekomen en vanzelfsprekende behoeften. Omdat de meeste ICT’ers weinig snapten van de business, schoten die vanzelfsprekende behoeften er bij in. Zeker toen de ICT-dienstverlening met de opkomst van Prince2 nog eens werd geïnstitutionaliseerd en de ICT al op voorhand werd gedechargeerd, was deze spotprent simpel een weergave van de werkelijkheid. (Zie ook ‘Prince 2 geeft de projectmanager vooraf al decharge’.)

Opkomst Agile aanpak

De eerste initiatieven om te breken met dit watervalmodel ontstonden in de jaren negentig. Onder de afkortingen RAD, IAD en DSDM werden nieuwe methoden geïntroduceerd. Omdat echter intussen ook de auditors hun intrede hadden gedaan, voor wie de watervalmethode een perfecte manier was om de kwaliteit (conform to specifications) te toetsen, werden vooral in grotere organisaties de nieuwe, iteratieve methoden geblokkeerd. Ook de overheid, die steeds meer projecten ging aanbesteden, kon niet uit de voeten met zo’n iteratieve aanpak. De nieuwe aanpak kreeg toen dan ook geen voet aan de grond. Veel organisaties investeerden zwaar in de overhead op projecten in de vorm van business analisten, business controllers, portfolio managers en PMO’s. De afstand tussen ontwikkelaars en gebruikers groeide hierdoor alleen maar. Voortschrijdend inzicht bij de gebruikers werd zeker niet gehonoreerd. Terecht vonden de inkopers, want de gebruikers willen toch weten wat ze kopen voor welke prijs. Terecht vonden de auditors, want wat moet je beoordelen als vooraf niet duidelijk is wat de uitkomst zou moeten zijn. Terecht vonden projectmanagers, want het projectresultaat moet vooraf duidelijk zijn om te kunnen sturen en bewaken. Maar zolang gebruikers niet vooraf alles kunnen specificeren wat ze bedoelen en ontwikkelaars niet snappen wat vanzelfsprekende behoeften zijn, zal het aantal projecten dat mislukt met deze aanpak nooit kleiner worden. En daarom werd een jaar of 10 geleden de iteratieve aanpak weer uit de kast getrokken en vooral meer herkenbaar gepositioneerd. Het etiket voor de denkwijze werd Agile en de meest gebruikte methode werd Scrum.

Essenties van Agile en Scrum

Agile en Scrum hebben een aantal uitgangspunten, die zijn vastgelegd in het ‘Manifesto for Agile Software Development’. De belangrijkste zijn:

  • Mensen en hun interactie zijn belangrijker dan processen en tools.
  • Werkende software is belangrijker dan uitgebreide documentatie.
  • Samenwerking met de gebruikers is belangrijker dan contractonderhandelingen.
  • Tegemoet komen aan voortschrijdend inzicht is belangrijker dan werken volgens de planning.

Het ontwikkelingstraject wordt opgedeeld in sprints, waarbij iedere sprint werkende delen van het systeem oplevert.In de duivelsdriehoek staan tijd en budget vast. Slechts de te realiseren requirements kunnen veranderen op basis van voortschrijdend inzicht. Hierbij geldt dat bij een toename van eisen en wensen minder belangrijke requirements minder prioriteit krijgen. Aan het eind van de rit zullen dus de requirements met de laagste prioriteit automatisch afvallen omdat de tijd op is.
De projectleider als persoon bestaat niet meer. Scrum kent drie rollen, die samen verantwoordelijk zijn voor het projectmanagement:

  • de product owner, die het mandaat heeft om de requirements te prioriteren;
  • de Scrum master, met als taak het proces te facilteren;
  • het ontwikkelteam, dat verantwoordelijk is voor het leveren van maximale toegevoegde waarde binnen de randvoorwaarden tijd en geld.

Scrum ‘werkt’ omdat deze methode een aantal conceptuele denkfouten direct in het werkproces heeft opgelost. Belangrijkste voorbeelden:

  • Denkfout 1: Requirements moeten eerst volledig en compleet zijn vastgelegd voordat er ontworpen wordt, en er moeten eerst volledige en complete ontwerpen zijn voordat er gebouwd en getest kan worden. Antwoord Agile: Het verkrijgen van feedback moet nooit worden uitgesteld. Immers, hoe eerder er feedback is, hoe eerder het duidelijk wordt dat er fouten gemaakt zijn, zodat er eerder ingegrepen kan worden en nutteloze inspanningen worden voorkomen.
  • Denkfout 2: Volledig en gedetailleerd documenteren en opschrijven is noodzakelijk en beter dan het maken van ruwe schetsen die vervolgens besproken worden. Antwoord Agile: Het nut van documentatie is het overdragen van concepten en modellen aan mensen. Dergelijke concepten en modellen worden veel sneller en effectiever overgedragen door de concrete uitwerking te zien, erover te discussiëren en vragen te stellen. Uiteindelijk gaat het om het continue leerproces via de resultaten per stap en dus om maximaal voortschrijdend inzicht en niet om het document.
  • Denkfout 3: Wijzigingsverzoeken zijn een verstorende factor en succesvolle projecten moeten daarom hun scope keihard bevriezen en bewaken. Antwoord Agile: De belangrijkste reden achter een wijzigingsverzoek is dat er voortschrijdend inzicht bestaat. Met andere woorden: het idee van een wijzigingsverzoek is dat dit het eindresultaat beter maakt. Dat negeren zou fundamenteel fout zijn. Verzoeken om verandering moeten daarom een centrale plaats krijgen in het werkproces en leiden tot meer klanttevredenheid.

Moet iedereen nu altijd voor Agile kiezen?

Elk van de methoden SDM, Prince2 en ITIL had aantal goede en zeer bruikbare ideeën, die we nog steeds toepassen. De methoden ging echter ten onder aan de verbeteraars die zo nodig de denkwijze achter de methoden uiteen moesten rafelen tot een gedetailleerde werkwijze, die generiek geldig zou zijn en die slaafs gevolgd kon worden. Dit probleem kent ook Agile. Is Scrum dan nog een methodiek die slechts op hoofdlijnen het ‘wat’ beschrijft, RUP is intussen uitgegroeid tot een serieuze boekenkast. Er worden trainingen in de methode gegeven (uiteraard door consultants) en je kunt zelfs via een examen gecertificeerd worden. Als vervolgens bedrijven gaan eisen, dat iedereen gecertificeerd moet worden, dan is de methode weer een kunstje geworden, dat slaafs gevolgd moet worden. De essentie van Agile is echter: ‘Honoreer voortschrijdend inzicht door beter te prioriteren’ en ‘Richt je op ‘fitness for use’ in plaats van op ‘conform to specifications’’. Deze essenties zijn ook veel breder toepasbaar dan voor alleen software ontwikkeling. Want laten we wel wezen, zuivere software ontwikkelingsprojecten vinden tegenwoordig alleen nog plaats bij gespecialiseerde softwareleveranciers en slechts zelden bij gewone organisaties. (Zie ook ‘Wie verlost bedrijven van hun ICT-ers’.) Cruciaal is wel altijd de invulling van de rol van product owner. Het gaat om de invulling, dus om de persoon, die deze rol invult. Er is niet sprake van trucjes, maar vooral van snappen wat de organisatie nodig heeft om haar business doelstellingen te realiseren. Ook de Scrum master moet begrijpen dat het ontwikkelteam ‘fitness for use’ moet leveren en dat hij niet weg komt met trucjes. (Zie ook ‘Foute antwoorden zijn jammer maar foute vragen zijn erger’.) Als een goede product owner of een goede scrum master ontbreken dan is ook een Agile project ten dode opgeschreven en geldt ook nu nog steeds: ‘De methode doet het niet’.

Bronnen:
Rini van Solingen en Eelco Rustenburg, ‘Kan Scrum fixed price?’ In: Automatisering Gids . 11 juni 2010.
Bart Jacobs, Agile en Scrum Essentials”‘ . Inspearit  hand-out.
  • Dorus Kanen (Werknemer niet meer in dienst bij NetCare)
    Dorus Kanen

    Ik vond het een leuk artikel dus ik een bookmark gemaakt (op publiek niveau).

    • Gerard Kanters
      Gerard Kanters

      Absoluut, na het artikel te hebben gelezen vroeg ik me af hoe het komt dat dergelijke methodes met wel goede uitgangspunten toch ten onder kunnen gaan. En dat zit misschien wel in het feit dat bedrijven proces optimalisatie nastreven en proberen kwaliteits waarborging in te brengen. Het eerste leidt tot formalisering en detaillering wat dus de grondgedachte eruit kan halen en de tweede tot die eisen van certificering en en het slaafse volgen van een methodiek. 

      Nog een reden dat bedrijven en de overheid nu eens in het informatie tijdperk zouden moeten stappen en uit het industriele tijdperk (al is het alleen maar tav ICT zelf). Dat zal de slagingskans van ICT projecten waarschijnlijk flink verhogen.