Expert in requirements

Agile kent ook deze 4 nadelen

Nadeel in de hand

Overal is te lezen en te horen wat de voordelen van agile en Scrum zijn. Die voordelen zijn zo groot dat organisaties massaal overstappen op een agile werkwijze. 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. Het is niet eenvoudig

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

Agile werken vergt een behoorlijke inleertijd. Dat komt omdat je niet alleen een nieuwe werkwijze met nieuwe technieken moet aanleren, maar vooral omdat agile een andere mindset vergt 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. Het vraagt veel tijd en commitment van de business

Gezamenlijk commitment

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 ontwikkelteam om af te stemmen, te sparren en bij te sturen. De business heeft een cruciale rol en is verantwoordelijkheid voor de ROI. Zij moeten op tijd beslissingen nemen, prioriteiten stellen en feedback geven aan het ontwikkelteam.

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 overbrengen op het ontwikkelteam.

3. De rol van de analist is onduidelijk

De bekende traditionele rollen zoals analist, ontwerper, architect, tester en projectleider worden bewust niet gehanteerd in agile. Iedereen is gewoon teamlid en als (multidisciplinaire) ontwikkelteam gezamenlijk verantwoordelijk voor het resultaat. 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 het ontwikkelteam samen. Het is zelfs niet vanzelfsprekend dat er analisten nodig zijn op een project.

4. Er is een organisatieverandering nodig

‘Change’ in de steigers

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, die een mengvorm van waterval en agile is. 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.

Succes met de requirements,

Nicole de Swart

PS Vond je dit artikel interessant? Deel het dan op Twitter, LinkedIn, Facebook of Google+ door op onderstaande knoppen te klikken.


Reacties (16)

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.
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.
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?
Mathijs Groen
by the way: jammer dat hier niet gereageerd kan worden op één specifieke reactie in de thread... @Nicole, misschien kun je dat verbeteren?
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.

Geef een reactie

Gratis preview Handboek Requirements

Cover ‘Handboek Requirements’

Lees alvast 5 hoofdstukken uit het compleet vernieuwde boek

Nicole de Swart

Nicole de Swart

Volg Nicole op:

Gratis video met tips voor user stories

Masterclass ‘Vervolmaken van je user stories’

Ontdek hoe je 5 door analisten veel gemaakte fouten omzeilt