In de afgelopen jaren zijn we enthousiast aan de gang gegaan met Agile. Nu vijf jaar verder heb ik driehonderd agile projecten onder de loep genomen. Projecten die tot grote successen hebben geleid, maar ook gigantisch hebben gefaald. Op basis daarvan heb ik in deel 1 de misvattingen en valkuilen op een rij gezet. Deze keer is het tijd voor de voordelen en succesfactoren. Een ‘hosanna’ Agile-project is binnen handbereik.
De actuele status van een Scrum-project is vaak in één oogopslag te zien, dankzij ‘burndown charts’, Scrum-borden met user stories, taken en kolommen. Deze laten zien of een user story bijvoorbeeld ‘in progress’ of al ‘done’ is. In het algemeen kun je zeggen dat Agile projecten transparanter zijn, En door de korte iteraties, de nabijheid van de stakeholders – via de ‘product owner’ – en de nauwe samenwerking in het scrum-team kunnen prioriteiten makkelijker worden bijgestuurd. Daarmee is de organisatie in staat sneller te reageren op veranderingen.
De kwaliteit van producten is beter. Iedere it-professional kent ongetwijfeld het figuur met de schommel. Dat laat zien hoe de uiteindelijk afwijkende wens van de klant gerealiseerd wordt. Onderzoeken laten zien dat in traditionele omgevingen van de oorspronkelijk honderd gedefinieerde requirements er vijftig worden gerealiseerd. De klant gebruikt uiteindelijk maar 25 functies. Dat is nogal wat ’waste’, volgens ‘lean’-begrippen. De klant maakt nu deel uit van het Scrum-project. En zit dus dicht op het ontwikkelteam. De gebruiker of opdrachtgever ziet snel genoeg wanneer sprake is van afwijkingen. Het herstel is zo gepiept. Dat geldt ook voor nieuwe inzichten die gaandeweg worden ontwikkeld. Het verkorten van de ‘time-to-market’ in een Agile-project met 10 tot 60 procent is ook een groot voordeel van Agile. Kortom, de juiste producten worden ook nog eens sneller opgeleverd.
Vaak leven ‘uitgebluste’ it’ers helemaal op als ze in een Agile-project gaan werken. Of dat nu komt door het verlaten van een jarenlange ‘sleur’, of door het werken in een team aan een gezamenlijk doelstelling, of doordat het team meer verantwoordelijkheid heeft. Feit is, dat in Agile-projecten medewerkers vaak gemotiveerder zijn. Ze zijn ook gewoon ‘blijer’. Een niet te onderschatten emotie voor het behalen van goede resultaten.
Succesfactoren
Ja, managers, nu komt het er op aan. In het verleden was het zo dat teamleden beslissingen van de manager vertrouwden en opvolgden. Bij een Agile-aanpak moet de manager beslissingen van het Agile-team accepteren. Het is de manager die de mensen in het team moet vertrouwen en aan hen zoveel mogelijk vrijheden en bevoegdheden moet geven. Om écht succesvol te kunnen zijn met de invoering van een Agile-aanpak is bedrijfsbrede commitment nodig. De invoering vereist meestal een cultuuromslag of minimaal een cultuuraanpassing. Daardoor is het bijvoorbeeld heel gebruikelijk dat mensen het bedrijf verlaten als ze niet in staat zijn te werken in een Agile-omgeving.
Ook voor de teamleden komt het er nu op aan. Succes wordt alleen bereikt als het team daadwerkelijk als team acteert. Dus niet werken in silo’s van ontwerpers, programmeurs, testers en gebruikers. Maar allemaal samen. Verder moeten alle ontwikkelprocessen worden geïntegreerd. Dus bijvoorbeeld geen losstaand ontwikkel- en testproces, maar volledig geïntegreerd gelijktijdig ontwerpen, programmeren en testen. Deze integratie geldt ook voor alle teamleden en activiteiten. Iemand in een programmeursrol moet bereid zijn andere activiteiten op te pakken, bijvoorbeeld testactviteiten. Iemand in de testrol moet ook bereid zijn bijvoorbeeld testautomatiseringsactiviteiten op te pakken of de opdrachtgever te helpen bij het opstellen van de user stories. Dit alles is uiteraard afhankelijk van de kennis en kunde van de desbetreffende persoon. In het algemeen kun je zeggen dat ieder teamlid één discipline uitstekend beheerst en verder bereid is een tweede of derde bij te leren. Teamleden in een Agile-team zijn multidisciplinair.
Het blijkt wel dat de invoering van een Agile-aanpak nogal wat voeten in de aarde heeft. Veel organisaties worstelen daar nog altijd mee. Om maar niet te zwijgen van de bedrijven die maar wat aan modderen. Weerstand tegen de verandering is nog altijd aan de orde. Zeker bij veel managers. Zorg dan ook voor een goede begeleiding bij de invoering van een Agile-aanpak. Bijvoorbeeld in de persoon van een veranderingsmanager of Scrum-coach. Dat is een bepalende succesfactor.
De invoering van een Agile-aanpak is een leertraject en gaat gepaard met vallen en opstaan. De ene keer is de invoering sneller succesvol dan de andere keer. Het is belangrijk om telkens te leren van de gemaakte fouten. En die in een volgende iteratie weer te verbeteren. Dus niet te snel opgeven. Wees ook niet bang fouten te maken. Want hier geldt, ‘fail to succeed’!
Thomas Edison heeft ooit gezegd, ‘I haven’t failed. I’ve just found 10.000 ways that won’t work.’
Met alle misvattingen, valkuilen, voordelen en sucessen op een rij draagt dat weer een beetje bij aan de kans op een hosanna-project. Of nog beter, start direct een hosanna Agile-project. Dan is er geen poging 10.001 nodig!
Leo van der Aalst, senior testing consultant bij Sogeti Sogeti en lector software quality & testing aan de Fontys Hogeschool
@Kossen: je hebt gelijk. Agile is een filosofie en Scrum een methode.
De agile filosofie en in het bijzonder de Scrum methodiek heeft 2 aspecten: enerzijds gaat het over samenwerken en onderlinge communicatie (overleg, al dan geen documentatie) en anderzijds over processen en resultaten. Dat eerste deel is vooral gericht op de ontwikkelaars (en eindgebruikers), ook om het werk aantrekkelijker te maken voor programmeurs en testers. Die krijgen immers een grotere rol, sterker nog: er wordt geen specifiek onderscheid in gemaakt tussen de rollen. Het tweede deel is interessanter voor het management en de opdrachtgever. Zo wordt het voor hen aantrekkelijk gemaakt om mee te gaan in de agile filosofie, want zij hebben het gevoel meer grip te krijgen op wat er gebeurt.
De initiator(en) om agile te gaan werken, is daarom niet per se de manager, maar kan net zo goed vanuit de IT-er zelf komen. En inderdaad kan het zijn dat als het management voor agile kiest, zij het proces en de resultaten wil benadrukken. Een programmeur die zijn rol wil verbreden en niet alleen de uitvoerder wil zijn van een functioneel detailontwerp, zal de nauwere samenwerking met de verschillende teamleden propageren. Tegelijk zijn er ook managers en IT-ers die niets van agile of scrum willen hebben. De manager niet omdat op een agile manier van werken te weinig inzicht geeft wat er straks over een half jaar wordt opgeleverd, en de IT-er die liever niet samenwerkt met anderen want die anderen zijn lastig, eigenwijs en snappen er niets van. Kortom voor- en tegenstanders van agile kunnen vanuit alle hoeken komen.
@HansJansen Ik denk dat iedereen voor samenwerken en onderlinge communicatie zal zijn. Denk ook dat iedere uitvoerende (beheerder, programmeur, tester, gebruiker) meer eigen verantwoordelijkheid en ruimte voor initiatief op prijs stelt. Op mijn cv had een tijd lang als functie analist-ontwerper-programmeur staan. Naar mijn mening ook onlosmakelijk met elkaar verbonden. Ik denk dat het niet meer bestaat. Maar ik zie ook dat de status van deze uitvoerende banen er niet hoger op is geworden in de tijd. Er zijn hier zelfs meningen te lezen die dit eenvoudig repetitief werk noemen. Hoe minder belemmeringen zijn voor een gebruiker-ontwikkelaar-beheerder om met elkaar samen te werken hoe beter denk ik.
Het is eerder een organisatorisch probleem. Dat kan al binnen een eigen organisatie zijn met verschillende afdelingen en het feit dat er bij een project zeer veel rollen zijn die allemaal wat in melk te brokkelen te hebben. Om nog maar te zwijgen van trends als uitbesteden, aanbesteden, outsourcing, offshoring en noem het maar op. Daarmee worden de formele barrieres tussen die uitvoerende alleen nog maar groter en staat er veel tussen. Dat is naar mijn mening ook de reden ook het ontstaan van dit soort procesbegeleidingsmethoden maar ook een trend als devops. Het probleem zit in de organisatie van projecten.
In het vorige stuk van de schrijver kwam de documentatie ook al aan de orde, scrum en agile is geen vrijbrief om het zonder documentatie te doen stelde hij. Terecht. Ook al zet het manifesto je op het verkeerde been wat dat betreft. Dat je voor de website van de lokale groentenboer niet documenteert kan ik begrijpen maar voor grote organisaties ontkom je er niet aan. Dan is er helemaal niets mis met requirements, functionele specs of technisch ontwerp. En dan niet verstopt in de grote scrum todo lijst. En ja, zelfs die documentatie kan agile zijn. Want voortschrijdend inzicht geldt op meer vlakken. Denk dan ook dat je uitstekend agile (ruimte voor onzekerheid) kan werken zonder een of andere procesbegeleidingsmethode. Maar dan kom ik ook terug op mijn eerder reactie, die methodes gaan over controle en niet over de inhoud. Integendendeel, ze brengen verwarring.
@Kossen
“Vertrouwen is goed, controle is beter”, zo wordt ongetwijfeld nog veel gedacht. Overigens merk ik in de praktijk dat het in het begin veelal laissez faire is, en pas als het spannend wordt (te late levering dreigt, budgetoverschrijdingen), plotsklaps wordt omgeschakeld naar controle.
Daarnaast is het begrijpelijk dat professionals met een duidelijke staat van dienst een broertje dood hebben aan verticale sturing. Ze weten beter wie dan ook wat ze moeten doen, en dus commiteren zich niet aan van te voren vastgelegde procedures, die eerder als knellend en beperkend worden ervaren.
De vraag is of scrum beschouwt moet worden als een ‘dwingend’ verticaal processturingsinstrument (met strakke deadlines, daily scrums) of dat het om een afsprakenset gaat tussen teamleden, waarbij de samenwerking en communicatie tot op zekere hoogte meer gereguleerd wordt. Want iedereen kan wel zeggen: we zijn voor samenwerking en communicatie, maar in hoeverre doen ze dit wel goed, denken ze daar uberhaupt over na en wat zijn de consequenties voor het werk. Ik zie in de praktijk dat juist die samenwerking en communicatie vaak heel moeizaam verloopt, en dat dat juist een van de redenen is dat ICT projecten uit de pas lopen. Scrum of een andere agile methode is daarbij niet dé oplossing, maar kan wel enigzins de samenwerking en communicatie versterken. Er is uiteraard meer voor nodig, maar dat vind ik juist de kracht van scrum.
Agile past gewoon in het rijtje van methodieken (of filosofieën) in de evolutie van software ontwikkeling. Het is een stap in de goede richting.
De menselijke geest is nou eenmaal te beperkt om een complex systeem te overzien en dan is het iteratief opbouwen een zeer natuurlijke manier van oplossen.
Een mogelijke volgende iteratie van software ontwikkeling lijkt me dat we AI gaan gebruiken om complexe software te laten ontwerpen. Een natte droom van de managers want die zal dan minder code kloppers nodig hebben.