Overal is te lezen en te horen wat de voordelen van agile en Scrum zijn. Over de nadelen hoor en lees je weinig.

Vanwege de (beloofde) voordelen stappen organisaties massaal over op agile. Wie wil er niet een hogere productiviteit, kortere time-to-market, grotere klanttevredenheid, hogere softwarekwaliteit, voorspelbaarheid qua doorlooptijd en kosten, kunnen omgaan met wijzigende requirements en bovendien meer werkplezier voor de projectmedewerkers?

Je zou bijna vergeten dat er ook nadelen kleven aan agile en Scrum. Het is niet alleen maar rozengeur en maneschijn.

Laten we eens 4 belangrijke nadelen onder de loep nemen:

1. Agile werken is niet eenvoudig

Agile en Scrum lijken misschien eenvoudig omdat de ‘spelregels’ eenvoudig zijn. Maar schijn bedriegt. Genoeg organisaties hebben al ondervonden dat het een hele uitdaging is om de agile principes en het scrum framework goed toe te passen.

Agile werken vergt een behoorlijke inleertijd. Je moet een nieuwe werkwijze met nieuwe rollen, producten en technieken aanleren. En belangrijker nog, agile vergt een andere mindset dan in traditionele softwareontwikkeling.

Veel dingen die vroeger vanzelfsprekend waren, gelden niet meer. Bijvoorbeeld planmatig werken, SMART requirements en zorgvuldig documenteren zijn in agile veel minder van belang.

2. Agile werken vraagt veel tijd en commitment van de business

Voor een succesvol agile project is intensieve samenwerking tussen business en ICT vereist. Er dient (bijna) dagelijks contact te zijn tussen de business en het agile team. Ze stemmen veel samen af, sparren onderling en sturen bij waar nodig.

De business heeft een cruciale rol en is verantwoordelijkheid voor de return on investment (ROI). Zij moeten op tijd beslissingen nemen, prioriteiten stellen en feedback geven aan het agile team.

De product owner in Scrum is niet voor niets een fulltime rol. Hij moet de wensen en verwachtingen van de stakeholders managen en zijn visie en het productdoel goed overbrengen op het agile team.

3. De rol van de analist is onduidelijk

De bekende traditionele rollen zoals business / informatie analist, ontwerper, architect, tester en projectleider worden bewust niet gehanteerd in agile. Iedereen is gewoon teamlid.

De leden van het (multidisciplinaire) agile team zijn gezamenlijk verantwoordelijk voor het eindresultaat. Er zijn geen voorgeschreven taken of werkzaamheden voor bepaalde teamleden. In plaats daarvan bepalen de teamleden iedere dag gezamenlijk wie welke werkzaamheden gaat doen.

Het opstellen van requirements is in een agile project niet meer de verantwoordelijkheid van analisten. Het just in time creëren van een gezamenlijk beeld van de requirements is een taak van de product owner en de teamleden samen. Het is zelfs niet vanzelfsprekend dat er analisten nodig zijn op een project.

4. Er is een organisatieverandering nodig

Om de voordelen van agile ten volle te benutten, is het niet genoeg om alleen binnen de ICT-projecten agile te werken. Heel de organisatie van hoger management tot marketing, productontwikkeling en ICT-beheer moet mee in de agile denk- en werkwijze.

Het is eerder een cultuurverandering dan wederom een nieuwe softwareontwikkelmethode. Gelukkig is een geleidelijke overgang aan te bevelen.

Voor een groot deel van de organisaties zijn typische agile voorwaarden als zelfsturende teams (geen projectleider), fully commited (medewerkers niet in meerdere teams), teamverantwoordelijkheid (geen individuele beoordelingen/bonussen), transparantie (geen managementrapportages) een brug te ver.

De meest voorkomende aanpak op dit moment is dan ook een hybride aanpak. Dit is een mengvorm van een waterval en een agile aanpak. Hiermee zijn vaak (iets) betere resultaten te halen dan met een watervalaanpak, maar de grote voordelen van agile zullen uitblijven.

Nu ben ik benieuwd naar je mening. Wegen deze nadelen voor jou op tegen de voordelen van agile? Geef alsjeblieft je mening in het reactieveld hieronder.

Nicole de Swart

Misschien vind je dit ook interessant

21 reacties

  • Martin Schuurman

    Analisten, archiecten, ontwikkelaars, testers allemaal zijn ze nodig in je team. Alleen op de raakvlakken, en die zijn breed, overlapt men. Echter in een Agile/Scrum team zit nooit iemand stil te wachten tot hij/zij iets over de muur gegooid krijgt.
    Specialismen zijn er dus nog wel degelijk maar dan zonder de “koker” blik.

    Mijder belangrijke zaken krijgen minder aandacht maar dat is juist goed want je doet alleen dat wat echt nodig is.
    Dat er een beetje waterval om de hoek komt kijken zie ik niet als een nadeel maar als een denkwijze die, mist bewust toegepast, zijn voordeel kan hebben.

    Krampachtig vasthouden aan een methode als Agile is net wat Agile niet is. Pas toe wat je nodig hebt en kies bewust en vooral leer in en van het hele proces. Alleen dan groei je als team en worden er mooie zinnige dingen gedaan.

  • Vincent van den Akker

    Interessant en goed artikel.

    Ik wil graag een aanvulling geven op punt 3: het onduidelijk zijn van de rol van de analisten.

    In mijn ervaring is het zo dat de rol van Product Owner vervuld kan worden door de “traditionele rol” van de business-analist. Deze persoon heeft de benodigde domeinkennis en heeft ook voldoende affiniteit met ICT om het Development Team te voorzien van de benodigde business informatie, wat ook de focus moet zijn van de Product Owner.

    In het Development Team is dan weer een goede plaats neergelegd voor de traditionele rol van de informatie-analist. Deze persoon kan de User stories (indien hiervan gebruikt wordt gemaakt) voorzien van de functionele invulling. Scrum stelt dat het Development Team cross-functional moet zijn, maar niet dat elke persoon in het team alle benodigde skills moet bezitten. Uiteraard is het de bedoeling dat ieder Development Team member (dus ook de informatie analist) meer taken uit de Sprint Backlog moet kunnen oppakken, maar in de praktijk zal dit niet altijd mogelijk zijn. Een (traditionele) informatie analist zal bv niet de skills bezitten om (efficiënt) te kunnen programmeren, wat wel benodigd is om een werkend eindproduct op te leveren. De informatie analist zou dan echter wel weer een aantal van de test activiteiten moeten kunnen oppakken, wat wel in de gedachte van Scrum ligt.

    Ik ben echter van mening dat het binnen Scrum veel meer gaat over het delen van de verantwoordelijkheid (binnen het Development Team) en het voorzien van een single-point-of-contact voor zowel de business als het Development Team betreffende businessdoelstellingen (Product Owner), wat leidt tot een andere verdeling van taken dan de traditionele rol van Business- en informatieanalist. Hun takenpakket is binnen Scrum veel uitgebreider en moet meer gefocust zijn op het opleveren van “Potentially releasable product increments” die de meeste waarde toevoegen aan het op te leveren product.

    • R. Civile

      Er zitten vast nog wel enkele hiaten meer in scrum. Waar veel methodieken de plank mis slaan is te denken dat je rollen en verantwoordelijkheden als een soort vloeibare substantie met elkaar moet delen. Dat kan in de iT dus niet. dat is een volkomn lineiare aangelegenheid waarbij rollen en verantwoordelijkheden dan ook leneair op elkaar dienen te worden afgesteld.

      Door die lineairiteit krijg je dan ook heldere transparantie en geen hiaten. Eén van de problemen die je vaak met dynamisch gremia ziet ontstaan is iets wat je ‘aanname’ kunt noemen. Mensen die aannemen dat een ander een bepaald onderdeel, kennis, verantwoordelijkheid draagt waardoor men in de uitvoering van processen zelf overl tegen aan loopt.

      Er is een oudere ‘ thermometer’ zo je wil, die universeel is waarmee je al dat soort dingen voorkomt. Het is geen commercieel verkoop ding maar een ideologische kleine tool waarmee je juist voorkomt dat zaken onderbelicht blijven of zelfs volkomen vergeten. Heb je weinig of geen kennis van automatiseren zitten er maar twee dingen op. Of je zorgt dat je met de essentie en principes van automatiseren bekend raakt of je blijft er vanaf.

      Teveel methodieken die worden gehypt hebben geen enkele kennis en affinitei met automatiseren wat dan de kosten door vertragingen en het implementeren van, om het even welke methodiek, veel duurder maakt dan vooraf bedacht en/of gepresenteerd.

  • Maarten

    Ik vind het verfrissend om een artikel over scrum te lezen dat ingaat op de nadelen. Ook het expliciet benoemen van typische agile voorwaarden is goede zaak. Teveel artikelen/boeken gaan hier aan voorbij. Zoveel organisaties/afdelingen zeggen dat ze agile werken maar in werkelijkheid zie je dan dat deze typische agile voorwaarden ontbreken.

    • R. Civile

      Een andere dooddoener die men vaak graag hanteerd,’ Kijk, scrum is een methodiek die je natuurlijk naar de orgainstatie of entiteit moet aanpassen….’ Ga dan eens iets gebruiken dat je NIET hoeft aan te passen waarbij iedereen meteen weet waar het om gaat zonder peperdure implementatie.

      Heb je geen verstand van het veld of organisatie, dan zijn er maar heel weinig methodieken die willen werken.

  • Rik Manhaeve

    Goede beschrijving maar ik zou deze nadelen geen nadelen noemen maar risico’s (waar je iets aan kan doen). Vooral de Product Owner is een gigantisch risico. De kans bestaat dat men zoekt naar het spreekwoordelijke ‘schaap op vijf poten’. Als het team te technisch gaat in zijn communicatie met de product owner, is het goed mogelijk dat die er niets van begrijpt. Het omgekeerde is ook waar. Naast een gedegen business kennis (details en overzicht) moet die ook kunnen communiceren met vele diverse partners en beschikbaar zijn. De product owner laten omringen door mensen die sterk genoeg staan op technisch vlak kan hier soelaas bieden. Ze nemen niet over van de product owner maar assisteren hem, de product owner blijft verantwoordelijk. Ik zie geregeld bronnen opduiken waar men interactie designers aan de product owner toevoegt (kunnen beoordelen of iets zal werken of niet, begrijpen een aantal technische kanten, zij het niet in de diepte en zijn meestal meer business georiënteerd).

  • Jip Schwering

    Goed verhaal, echter een aantal zaken gaan puur over Scrum (de rolverdeling van product owner en ontwikkelteam) en niet zozeer over Agile. Laten we niet vergeten dat er nog véél meer manieren zijn om agile te werken, waarbij er wel degelijk rollen worden onderkend en er geen ‘product owner’ is.

  • Eric Fassotte

    Als ik een leek moet beschrijven wat ik als Business/Informatie Analist doe, dan zeg ik altijd dat ik een soort tolk ben tussen de gebruikers en de ICT-ers. “Zet gebruikers en ICT-ers samen in een hok. Ze spreken allemaal nederlands, maar begrijpen elkaar niet”. Deze rol zal m.i. zeker ook bij Agile/SCRUM nodig blijven.

    Ik ben er ook van overtuigd, dat niet voor alle projecten een agile manier van werken zinvol is. Gelukkig onderschrijven de agile methoden dit ook. Agile methoden zijn nl. vooral geschikt voor projecten in een dynamische omgeving en/of met veel onzekerheid over de requirements. In veel organisaties zullen ook projecten uitgevoerd worden, waarvoor deze dynamiek en onzekerheid niet geldt. Een hele organisatie (proberen te) veranderen is dan ook niet altijd even zinvol. Je kunt een organisatie ook op meerdere manieren laten denken.

    En last but not least: het succes zit hem nooit in een methode, maar in de mensen. Als de mensen niet de juiste kwalificaties hebben, is een projkect gedoemd minder effectief en efficiënt te zijn, of zelfs te mislukken. Als de methodiek niet goed is, maar de mensen wel, dan vinden de mensen vaak een manier van werken die wel past. Dit vraagt enige vorm van pragmatisch werken. Daarnaast is met elkaar communiceren van groot belang. Belangrijkste is, dat alle neuzen dezelfde kant uitwijzen. Geen politiek of verborgen agenda’s. Openheid en begrip voor elkaar hebben. Elkaar als partners zien i.p.v. “andere partijen”. We werken tenslotte allemaal voor hetzelfde gemeenschappelijke doel: efficiënte en effectieve software, die zo min mogelijk beheer nodig heeft.

  • Nico van Veen

    Goed stuk,

    Scrum is toch voor mij een beetje dat de opdrachtgever niet weet wat hij wil en dat dat dan dankbaar wordt opgepakt door de software leverancier die vervolgens heel veel uren kan schrijven. Als je als opdrachtgever de requirements niet voor ogen hebt, kan je beter daar je tijd en geld aan besteden dan het in de handen van een scrum team leggen.

    Een ander nadeel van Scrum is dat de business lekker wordt gemaakt dat om de zoveel tijd een werkend stuk software wordt opgeleverd. Vooral bij object georiënteerd ontwikkelen, zal dit in het begin van het project niet het geval zijn. Hier is het project dan geen “optelling van” maar het bouwen van het systeem vanaf de fundamenten.
    Iedereen weet dan aan een heipaal niet veel te zien is, maar je hebt hem wel nodig wil het huis later niet scheef zakken.
    Liever een stuk software waar in de beginfase tien keer over is nagedacht over de opbouw, wat dan eerst langzaam lijkt te gaan maar waarbij op het eind grote vaart kan worden gemaakt, dan vanaf het begin onder druk rotzooi produceren wat je later toch weer allemaal mag veranderen.

  • Guy

    Transparantie gelijk stellen aan ‘geen managementinformatie’ vind ik een wel heel erg kort-door-de-bocht benadering. Ik denk dat ik je intentie begrijp, maar transparantie betekent nu juist goed geïnformeerd zijn.

    • Nicole de Swart

      Klopt Guy, transparantie betekent goed geïnformeerd zijn. Dat geldt voor iedereen (niet alleen management) en op ieder moment in het traject. Als je voor die openheid en transparantie zorgt, zoals agile voorstaat, heb je geen managementrapportage nodig, want iedereen (die wil) is volledig geïnfromeerd over onder andere de voortgang.

  • Ar

    Goed stuk.

    Ik mis nog iets over het daadwerkelijke tijdsbeslag. De business moet vaak overtuigd worden en focust dan o: wat kost me dat? Die tijd, hoeveel is dat? Verhoudingsgetallen?

  • Mathijs Groen

    Is Agile werken nou allemaal nou wel zo geweldig? Ik ben er zeer kritisch op, zie eigenlijk alleen grote nadelen. En ik zou graag eens willen weten het antwoord op de vraag: Is Agile nu wel een effectieve manier van “werken”?

    Wegen al die investeringen (mensen trainen, inhuur van externe coaches en ‘gurus’, en Agile-profeten), nu wel op tegen de behaalde winsten?

    Wie reageert?

  • Rene Klein

    Als oude rot in het vak, mis ik documentatie. Hoe vaak ik niet ingehuurd ben om onderhoud te plegen aan een ouder, niet gedocumenteerd systeem. Ik noemde mijzelf weleens een archeoloog.
    Ik vraag me af, hoe bedrijven dit over een jaar of 10 gaan doen. Er wordt verondersteld, dat er doorlopend gewerkt wordt aan een systeem. Dat dachten ze 20-30 jaar geleden ook. Maar op een gegeven moment zijn hele stukken gewoon af en zal er jaren niets aan hoeven gebeuren.

    • Nicole de Swart

      Rene, het blijkt een hardnekkig misverstand te zijn dat agile een documentatie niet samengaan. Er is niets op tegen om de gewenste systeemdocumentatie op te nemen in de ‘definition of done’. Het is alleen geen vanzelfsprekendheid meer, maar een bewuste keuze (inclusief inzicht in de kosten).
      Samen met Rini van Solingen heb ik er een artikel overgeschreven zie daarvoor http://www.reaco.nl/blog/de-schone-schijn-van-documentatie/

      • Rene Klein

        Hoi Nicole. agile ‘predikt’ niet te detaillistisch te documenteren. Waar leg je de grens. Ik was Acceptester. Een raakvlaksysteem moest berichten van klanten voor ons tonen om verwerkt te worden. Ik testte zo’n inkomend bericht, ik zag niets verschijnen. Ik stelde dat het zoals het mooi gezegd wordt, ‘het voldeed niet aan de verwachting’.
        De opleverdatum begon gevaar te lopen, het raakvlaksysteem snapte maar niet waarom ik zo moeilijk deed. De meeste berichtsoorten gingen wel goed, behalve die ene. Ze konden niets vinden. Na 2 weken hadden ze eindelijk gevonden, waarom dit zo was, er was ooit een keer mondeling afgesproken, dat het ene berichtsoort een delay had van een week. Het was dus wel goed, alleen was nergens zo detaillistisch vastgelegd, welke uitzonderingen er zijn.
        Dit is één van veel voorbeelden. Agile gaat volgens mij, teveel uit van (1) een goede samenwerking, (2) een doorlopende project waar kennis in het hoofd zit van het scrumteam.
        Overigens ben ik geen tegenstander van Agile, maar ik denk wel, dat de agile/ scrum hype erg doorslaat.

        • Nicole de Swart

          Mooi praktijk voorbeeld, Rene. De praktijk is inderdaad weerbarstiger dan de theorie. In een hybride omgeving (deels agile, deels waterval) kun je er niet van uit gaan dat de agile practices vlekkeloos werken. Je zult dingen moeten toevoegen om bijvoorbeeld de gebrekkige samenwerking op te vangen. Dat kan onder andere met meer documentatie.

  • Steven Deneir

    Als Professional Scrum Trainer is deze titel natuurlijk een immense trigger;-) En dan start ik graag een open conversatie.
    Volledig akkoord dat agile werken een behoorlijke inleertijd vergt. Vooral inderdaad omdat het een belangrijke mindset shift meebrengt. Dat het niet eenvoudig is; juist. Maar is dat een nadeel…? Mijn zoon is aan het studeren voor zijn rijexamen. Hij zei gisteren dat het niet eenvoudig is. Is het daarom een nadeel…?

    Waar ik niet mee akkoord ga: “Veel dingen die vroeger vanzelfsprekend waren, gelden niet meer. Bijvoorbeeld planmatig werken, SMART requirements en zorgvuldig documenteren zijn in agile veel minder van belang.” Er zit enorm veel plannen in Scrum. Weliswaar opnieuw met de “juiste” mindset: een visie afstemmen is plannen. Akkoord komen over het doel voor de komende x weken is plannen. Afspreken wat dit doel allemaal omvat is plannen. Hoe dit allemaal samen als 1 team te bereiken is plannen. De Daily Scrum is een event waarin het team de komende 24 uur overlegt; is plannen. De Sprint Review waar het team een forecast zou moeten geven naar de stakeholders is plannen.
    SMART requirements: een Scrum Team dat de requirements niet begrijpt heeft een stevig probleem. Dus als een team daar niet het nodige belang aan hecht zitten ze met een groot probleem. Zorgvuldig documenteren staat explicit in de agile values: “Working software over comprehensive documentation”. Veel lezers zien het woordje “over” niet. Dit betekent dat er wel degelijk “comprehensive documentation” moet zijn. Alleen betekent dit “de documentatie die nodig is”. Voor alle stakeholders: toekomstig onderhoud, gebruikers, noem maar op.

    “Agile werken vraagt veel tijd en commitment van de business.” Samen werken is cruciaal. Samen. Daarnaast is het een product/service voor de business. Waarom zouden zij dan niet de juiste beslissingen moeten nemen. Ik heb naast Scrum en agile ook een project-achtergrond. Waar andere rollen die beslissingen nemen. En dan krijgt het team achteraf – veel te laat – te horen dat het toch niet is wat de business nodig heeft. Het team/de project manager krijgen dan verwijten dat zij het niet goed hebben gedaan. Terwijl dit beslissingen zijn die niet bij hen moeten liggen. Ik bouw een vijver. Mijn vijver. Moet ik dan cruciale beslissingen zoals grote, diepte, soorten vissen, die allemaal een impact hebben op de filter bij de tuinman leggen? Hoe de vijver te bouwen laat ik heel graag aan hem over. De ander zaken beslis ik toch? Als business. Een nadeel? Of iets wat we niet gewoon zijn en meer tijd neemt dan we hoopten?

    “De rol van de analist is onduidelijk”. Of andere team rollen. Iedereen is “gewoon” teamlid. “Het is niet vanzelfsprekend dat er analisten nodig zijn. “ En deze volledige paragraaf.
    Een team heeft alle skills nodig om hun doelstellingen te bereiken. Alle skills. Inclusief alle skills die verwacht worden van alle genoemde rollen. Dus het is heel vanzelfsprekend dat die personen nodig zijn. Het grote verschil ligt erin dat agile verwacht dat iedereen echt samen werkt. En wat we zien met alle titels en rollen is dat die samenwerken tegenwerkt: ik ben analyst, dus ik ga geen test-scenarios uitwerken. Dat is voor de tester. Really? Ik ben tester, dus ik ga geen analysewerk doen. Really? Ik ben software ontwikkelaar, dus ik hoef niet te testen. Really? Beste analyst, ontwerper, architect, projectleider, jullie hebben allemaal super belangrijke skills die ons team nodig heeft. Staan jullie open om samen te werken naar dit doel, jullie skills optimaal in te zetten, en ook anderen te helpen en dus samen te werken aan verschillende taken? Wil je ook sommige skills leren van anderen? Ja? Super welkom in het team! Dus opnieuw idem als het allereerste punt: het is een mindset shift.

    “Er is een organisatieverandering nodig”. Jep. Volledig akkoord. En al helemaal met “het is niet genoeg om alleen binnen ICT agile te werken” want dan mist het team broodnodige skills.
    Waarom zou dit “een brug te ver zijn”? Omdat ze de verkeerde begeleiding krijgen. Waarom kan dit niet stapsgewijs, en eerst een eerste brug nemen, dan een volgende, en nog een. Weet de organisatie waarom agile voor hen waardevol is? En staan ze open om in die richting te werken? Dan is het een evolutie. Geen revolutie. Bedrijven die niet gaan veranderen, en niet agile gaan zijn, zullen binnen x tijd uit de markt liggen. Sommigen gaan langer overleven dan andere door hun cash. Maar ze gaan er uit.

    Ga ik akkoord met de opgesomde nadelen. Nee. Dit zijn geen nadelen; het zijn vereiste stappen en inzichten die een organisatie krijgt als ze professioneel omgaan met Scrum of andere agile frameworks. En dan kunnen ze een bewuste beslissing maken of ze dit al dan niet willen.
    Ga ik akkoord dat de organisatie een mindset shift moet doen. Volledig!

    • Nicole de Swart

      Wat een uitgebreide reactie, Steven. Dank dat je daar de tijd voor genomen hebt. Ja, voor agile werken is inderdaad een mindset shift nodig. Of dat een nadeel is? Dat wordt in veel organisaties wel zo ervaren, heb ik gemerkt. Agile gaan werken en een agile organisatie worden heeft veel consequenties, er moet heel wat veranderen. Niet alle organisaties willen dat (of realiseren zich dat).
      Inhoudelijk zijn we het eens, denk ik. We duiden en verwoorden het alleen anders.

  • Julius

    Nabrandertje: als ICT-er ben ik verantwoordelijk voor het ‘up and running’ houden van systemen. Al dan niet bedrijfskritisch. Maar ook voor het oplossen van functionele en operationele problemen. Dat kan ook inhouden dat ik adhoc iets moet updaten of upgraden om te kunnen garanderen dat de systemen blijven werken. Maar blijkbaar is er daar geen ruimte meer voor als alle capaciteit reeds vooraf is geboekt (tijdens zogenaamde ‘PI-dagen’). Ook dat is blijkbaar ‘agile-werken’. Alle beschikbare capaciteit wordt vooraf geclaimed. Ook al blijkt deze, achteraf gezien, niet nodig te zijn of is er achteraf een gewijzigd inzicht op de uit te voeren activiteiten (kan ook later). Een en ander heeft weer te maken met de prioriteitenstelling binnen de organisatie. Eindconclusie: uiteindelijk geclaimde capaciteit blijft onbenut en gaat verloren. Dit ten koste van andere (noodzakelijke) activiteiten. Dat is verloren kapitaal: qua mens, tijd en geld. Hoe ‘fr’-agile en ‘verkruimeld’ willen wij een organisatie maken bij het uitvoeren en het nemen van haar dagelijkse werkzaamheden en verantwoordelijkheden?

    • Francois

      @ Julius: dat is dan een mooi voorbeeld van het verkeerd gebruik van Scrum/ Agile. Daarom schrijft SAFE ook voor om eens in de zoveel tijd een sprint te wijden aan maintenance en het op orde brengen van je documentatie en infrastructuur. DevOps zou er juist voor moeten zorgen dat je de juiste afweging maakt tussen beheer en ontwikkeling. Het punt bij Scrum en allerlei andere methodes die beloven het eeuwige probleem van ’te duur’, ’te weinig functionaliteit’ en ‘niet geleverd wat ik had verwacht’ op te lossen, is dat alle methodes snel dogmatisch worden toegepast.

Geef een reactie