Categorie: Agile & Methodieken

Volwassen zijn. Dat is zoiets als het bereiken van een zekere rijpheid of leeftijd. Maar het gaat ook over ervaring, bijvoorbeeld met het inschatten van werk: volwassen worden als agile team vergt dat je ook goed in staat bent het werk te plannen. Bij projecten gaat dat vaak in dikke plannen en gedetailleerde planningen met wel honderden activiteiten. Agile teams plannen heel anders. Maar zijn de resultaten nu echt beter voorspelbaar? Laten we eens kijken hoe dat plannen in de praktijk gaat.
Met projecten gaat het ongeveer zo…Als het project wordt opgestart neemt de projectmanager zijn of haar schattingen van het werk en de benodigde capaciteit als basis voor het projectplan. Vaak geldt die inschatting voor de hele duur van het project en in het geval van langdurige projecten wordt vaak per projectfase een plan gemaakt. Tijdens het opstellen van het plan zijn er veel onzekerheden, we plannen immers vaak meer dan een jaar vooruit. Zoals algemeen bekend blijken al die schattingen in de praktijk nogal eens te optimistisch te zijn geweest. Met als gevolg dat een groot percentage van de projecten (zo’n zeventig procent) te laat wordt opgeleverd. “Even geduld alstublieft…”. Juiste schattingen van het werk en de benodigde capaciteit blijken bij projecten vaak in een puberale fase te blijven hangen.
Met agile teams gaat schatten ongeveer zo …Agile teams doen niet aan lange termijn beloften. Kort voor de start van een zogenaamde sprint, die doorgaans twee of drie weken duurt, wordt een planning gemaakt: het team pakt de hoeveelheid werk op waarvan het team verwacht dat zij die in die sprint kan afmaken. Omdat het maar over 2 of 3 weken gaat zijn de omstandigheden en de beschikbare capaciteit beter bekend. Binnen organisaties die bijvoorbeeld met het SAFe scaling-model werken, plannen teams de capaciteit per kwartaal; het gaat om zogenoemde ‘epics’ of ‘features’. In die situatie wordt verder vooruit gepland om de stakeholders meer zicht te bieden op wat er in een kwartaal zal worden opgeleverd.
De praktijk van de agile teamsAgile teams geven geen echt hard commitment voor het realiseren van al die epics en features in dat kwartaal. Als het niet lukt krijg je als stakeholder minder opgeleverd. De agile teams bepalen ook in het geval van die kwartaalplanningen nog steeds per sprint wat zij oppakken, uiteraard op basis van de prioriteiten die de Product Owner aangeeft. Aan het eind van het kwartaal blijkt wat er daadwerkelijk opgeleverd is. In de praktijk constateer ik echter dat teams aan het einde van het kwartaal regelmatig veel minder hebben opgeleverd dan zij hadden ‘aangenomen’. Met als gevolg teleurgestelde stakeholders. Wat zijn de meest voorkomende oorzaken dat het niet lukt?
Uitdagingen om echte volwassenheid te bereikenDe wereld is niet perfect, ook de agile wereld niet. Het werk blijkt complexer dan tevoren ingeschat, mensen vertrekken onverwacht uit het team en het inwerken van nieuwe medewerkers duurt langer dan verwacht (soms wel zes tot negen maanden). Er is sprake van ‘zij-instroom’: werk dat aan het begin van het kwartaal niet gepland was. Of er zijn verstoringen van de applicaties die met hoge prioriteit moeten worden opgelost. Ook kan het reguliere onderhoud van het systeem meer tijd vergen dan verwacht; denk bijvoorbeeld aan de overgang naar nieuwe versies van de software of van de tools waar men mee werkt, met alle testwerkzaamheden die daarbij komen kijken. En dan is er natuurlijk ook nog tijd nodig voor trainingen en voor zaken als vakgroep- en afdelingsbijeenkomsten.
Stel de vraag aan Product Owners hoeveel uren de teamleden nodig hebben voor hun reguliere werkzaamheden, bijvoorbeeld op het gebied van beheer, opleidingen en andere bijeenkomsten. Minder volwassen teams kunnen daar niet direct antwoord op geven. Hoe kan je dan de beschikbare capaciteit voor alle veranderactiviteiten inschatten? Goed zicht op al het werk, ook die andere activiteiten, is echt nodig om een volwassen team te worden.
Tips om volwassenheid in verandertrajecten te bereikenGoed leren en continu verbeteren is heel erg agile, dus daarom heb ik de volgende 3 tips:
1. Durf verder vooruit te kijken, dat voorkomt veel verrassingen. Probeer als Product Owner een roadmap voor het komende jaar te maken. Aanpassen kan altijd. (Teams blijven flexibel).
2. Laat Product Owners elk kwartaal, voorafgaand aan de planning sessie met hun team, vaststellen hoeveel tijd er nodig is voor alle andere activiteiten, zoals opleidingen, vergaderen en vooral de beheerwerkzaamheden. (Fundamenten moeten er altijd zijn en mogen niet verzwakken)
3. Laat Product Owners met hun teams na ieder kwartaal ook hun inzichten bespreken hoe de verhouding tussen beheer en ontwikkeling daadwerkelijk is geweest en wat dat voor de komende periode betekent. (Continue leren en planningen bijstellen)
Voordeel voor de teams is dat een beter zicht op de beschikbare ruimte voorkomt dat ze te veel hooi op hun vork nemen. Dat voorkomt weer teleurstellingen bij hun stakeholders en maakt de beschikbare capaciteit transparant; dat is toch heel agile.
Kinderlijk eenvoudig toch, of niet..?
Is jouw projectorganisatie onvolwassen, groeiende of volwassen?Ik ben benieuwd tegen welke uitdagingen jij in jouw organisatie aanloopt. Graag ga ik erover in gesprek om van elkaar te leren.
Remco Reitsma– ProjectReports – Tel: 06 – 53 24 77 43 – [email protected]

Dat aanstormende mannetje is een teammanager. Laten we hem gemakshalve ‘Peter’ noemen. Jarenlang werkt hij voor een traditioneel ingerichte organisatie, maar nu is agile werken omarmd door de directie. Hij probeert met alle macht de deur van de vergaderruimte in te beuken. Hoewel hij niet meer welkom is probeert hij toch de meetings van verschillende agile teams te verstoren. Wat is er aan de hand?

De veranderende rol van Peter

Peter had in het verleden macht. Hij was vanuit het team als manager benoemd. Plotseling had hij het voor het zeggen. Hij ging controleren, legde de opdrachten voor het team vast, was bepalend voor de te voeren strategie en had de eindverantwoordelijkheid om belangrijke beslissingen te nemen. Hij was trots en had status, omdat hij behoorlijk was geklommen op de hiërarchische ladder. Misschien kon hij wel directeur worden. En toen was alles ineens anders…

Voor Peter is het ‘zij tegen mij’ geworden

De medewerkers die hij eerst zag als ‘zijn mensen’ werken nu in agile teams. Hij moet erg wennen aan het idee dat er nu Scrum Masters zijn die het proces ondersteunen en het team begeleiden. Peter wordt door hen weggehouden, want het is de bedoeling dat de agile teamleden ongestoord hun werk kunnen doen. Zijn macht, zijn invloed en zijn verantwoordelijke rol is verdwenen. Als teammanager levert hij alleen maar zijn goed gekwalificeerde mensen, maar is niet meer verantwoordelijk voor de inhoud. Soms voelt hij zich bijna de eenzame eigenaar van een detacheringsbureau. Van enige status is allang geen sprake meer.

Maak een duidelijke keuze

Mensen zoals Peter bestaan echt en kom ik in de praktijk ook tegen. Wat ik vooral wil benadrukken is dat traditionele hiërarchische structuren en agile manieren van werken in één organisatie niet samengaan. Dan krijg je de situatie dat medewerkers op papier nog onder verantwoordelijkheid vallen van Peter, terwijl het bij de agile manier van werken ondoenlijk is om voor meerdere opdrachtgevers te werken. Het is als het spelen van een voetbalwedstrijd. Je kunt het maar binnen één team doen en niet op meerdere plekken tegelijkertijd tijdens verschillende wedstrijden de bal spelen. Niemand scoort dan en er zullen alleen maar verliezers zijn.

Wat kunnen mensen die zich in Peter herkennen doen?

Als er echt voor agile gekozen is, dan is dat behoorlijk uitdagend. Wil je werkzaam blijven binnen dezelfde organisatie, maar niet puur als leverancier van mensen, dan kan je bijvoorbeeld jezelf bijscholen tot Scrum Master of Product Owner. Als Scrum Master wordt je een coach. Als Product Owner kan je je juist met de inhoud bezighouden. Agile werken vraagt om een groot aanpassingsvermogen. Plotseling wordt er van je verwacht dat je het tegenovergestelde gaat doen van datgene wat je jarenlang gewend bent:

• Traditioneel ging het om controleren van het team, nu om vertrouwen hebben in het team.
• De organisatie werkt niet meer top-down, maar bottom-up bij agile.
• Foute beslissingen waren altijd ongewenst, nu leer je van fouten en mag je ze maken.
• De gewenste uitkomst was vooraf altijd bepaald, in agile kunnen uitkomsten tussentijds wijzigen.
• Beslissingen worden niet genomen door één (=macht), maar doe je plotseling samen met het team.

Probeer dus geen deuren van vergaderruimten meer open te beuken als er eenmaal voor agile gekozen is. Begin bij jezelf en bepaal of een nieuw gewenste agile aanpak bij jou past en of je bereid bent te veranderen. Agile is namelijk een cultuurverandering en binnen een cultuur moet je je wel thuis blijven voelen.

Remco Reitsma – ProjectReports – Tel: 06 – 53 24 77 43 – [email protected]

In de wereld om ons heen draait alles om snelheid. Om te overleven moeten bedrijven razendsnel kunnen innoveren en zich aanpassen aan veranderende klantwensen. In de media lezen en horen we hoe het mis gaat met de winkelketens die zich niet snel genoeg aanpassen, zoals de V&D, Intertoys en Coolcat. Deze versnelling in de maatschappij is een belangrijke reden dat agile en Scrum zo populair geworden zijn. Maar aan deze nieuwe manier van werken zit ook een keerzijde voor directies. Want datgene wat snel voorbijkomt moet wel te interpreteren blijven.

Hoeveel informatie kan je echt verwerken?

Er zijn directieleden die pijn in de benen krijgen van al die stand-ups en demo’s waarin de scrumteams elke twee of drie weken aan hun stakeholders laten zien wat voor mooie producten ze hebben opgeleverd. De agenda’s van de directieleden waren al vol en raken nu helemaal overvol. Met als belangrijkste reden het teveel aan teams die ze moeten bezoeken om bij te blijven. Het wordt ondoenlijk om van ieder team te vernemen welke sprintjes er getrokken zijn. Niet dat ik geen voorstander ben van agile en Scrum, maar ieder mens heeft ergens een grens om alle informatie te begrijpen, te verwerken en overal bij aanwezig te zijn.

Overzichtsrapportages blijven belangrijk

Uiteindelijk moeten al die verschillende agile teams altijd een bijdrage leveren aan het bedrijfsresultaat en is er niets mis met een sanity check of dat ook zo is. Het kan namelijk voorkomen dat teams niet de snelle opleveringen weten te realiseren die verwacht worden van agile teams. Of dat er toch meer out-of-pocket kosten gemaakt worden dan begroot. Of dat er producten worden (door)ontwikkeld door een agile team die uiteindelijk maar beperkte waarde blijken te hebben. Helaas zijn er genoeg voorbeelden van mooi uitgewerkte oplossingen, bijvoorbeeld in de IT, die in de praktijk niet of nauwelijks gebruikt worden. Natuurlijk zijn voor de teams zelf indicatoren als ‘team happiness’ en ‘velocity (productiviteit)’ zeer belangrijke indicatoren. Maar de directie wil nog steeds weten of de producten op tijd worden opgeleverd en niet te veel geld kosten. Terwijl de directieleden niet elke demo van al die teams kunnen bijwonen. Conclusie: zorg voor een overzichtsrapportage waarin de directie kan volgen hoe het met de voortgang en de belangrijkste indicatoren gaat. Voorbeelden van indicatoren zijn ‘tevredenheid stakeholders’, ‘opgeleverde business waarde’, ‘blokkades (‘impediments’). En voor de voortgang beschouw ik het zogenaamde Minimum Viable Product (MVP) als een ouderwetse ‘mijlpaal’. Daarvan kan je aangeven na hoeveel sprints je die verwacht op te leveren. 

Minder pijn in de benen?

Laat ik vooropstellen dat deelname van de directie aan elke stand-up en demo enorm gewaardeerd wordt. Maar als het niet mogelijk is om voor alle demo’s ook tijd vrij te maken is er niets mis met één overzichtsrapportage waarin op een uniforme manier in één oogopslag duidelijk is hoe het met alle veranderinitiatieven staat. Ook als er een keer een stand-up of demo gemist wordt kan de besluitvorming verbeteren door begrijpelijke, duidelijke en goed te interpreteren informatie van de agile teams. 

ProjectReports

Wij brengen met onze oplossing overzicht, inzicht en rust in al die verschillende veranderinitiatieven waar medewerkers elke dag met plezier aan werken.

Tijdens een online demonstratie laat ik het graag aan je zien. Staan mag, zitten natuurlijk ook.

Remco Reitsma – ProjectReports – Tel: 06 – 53 24 77 43 – [email protected]

Er werd hard geapplaudisseerd voor het agile team. Het team had een grote bijeenkomst georganiseerd om het resultaat te vieren. Iedereen was blij en trots op het bereikte resultaat: de opdrachtgever, het team en de gebruikers. Nu, tien maanden later, is dit meest gemotiveerde agile team gedesillusioneerd en zijn de hoofdrolspelers die het eerst heel goed met elkaar konden vinden nu in een heftige strijd verwikkeld. Wat ging er mis?

Het ontbrak aan een vruchtbare bodem

Dit beschreven voorbeeld is helaas echt. Recent sprak ik met de verantwoordelijk product owner, een persoon die opviel door zijn enorme motivatie en gedrevenheid en nu in dit gesprek een vermoeide, bijna verslagen indruk maakte. Hij vertelde dat ook de motivatie in zijn team fors was gezakt. Daar stond hij dan als product owner met top-motivatie en alle kennis en vaardigheden om er een succes van te maken. De omgeving, de oude organisatie, werkte tegen. De vruchtbare bodem om het team succesvol te laten groeien ontbrak. Met als gevolg dat de motivatie in een diep dal terecht is gekomen.

Wat is er aan de hand?

De product owner zag als belangrijkste oorzaak het ontbreken van een toekomstperspectief voor de lijnmanagers. Met als gevolg tegenwerking. De menselijke tegenreactie is dat jarenlang opgebouwde ‘koninkrijkjes’ worden verdedigd en bestaande rollen angstvallig worden vastgehouden. Het zal immers je baan maar zijn als er in de nieuwe agile organisatie geen perspectief voor jou is. Sterker nog, regelmatig was verkondigd dat er voor lijnmanagers geen plek meer zou zijn. Geen wonder dat de motivatie van de huidige lijnmanagers ver te zoeken was.

Zelf constateer ik dat senior management de laatste maanden de agile transitie niet echt prioriteit geeft en in haar communicatie ook niet uitstraalt dat ze overtuigd is van nut en noodzaak. Dat zie je door de verminderde aandacht en middelen die de transitie nu krijgt. Zo is bijvoorbeeld het aantal coaches sterk afgebouwd en is de transitie ‘overgedragen aan de lijn’, oftewel de lijn moet het naast het reguliere werk doen. Inmiddels ontstaat een voedingsbodem voor twijfel waarin de oude en nieuwe organisatie elkaar in de weg lopen. Daardoor kunnen ontwikkelingen agile aangestuurd worden terwijl een ander deel van de organisatie hieraan niet meewerkt.

Wat te doen?

Snel duidelijkheid bieden helpt altijd. Een te lange transitiefase waarbij iedereen met vraagtekens rondloopt ondermijnt het vertrouwen. Zoals ik in mijn vorige blog heb beschreven zijn naast motivatie twee andere factoren noodzakelijk voor het realiseren van gewenst gedrag, in dit geval voor agile werken: de kennis en kunde (capaciteit) en tijd, ruimte en ondersteuning (gelegenheid). In de overgangssituatie moeten de lijnmanagers ervoor zorgen dat de agile teams ook de gelegenheid krijgen om hun werk succesvol te doen.

Hoe voorkom je botsing van belangen?

Om de beschermers van hun ‘koninkrijkjes’ mee te krijgen in de agile transitie zullen ook de lijnmanagers van de ‘oude’ organisatie:

• gemotiveerd moeten worden (bijvoorbeeld door begeleid te worden naar een nieuwe rol)
• begeleid moeten worden om de benodigde kennis en kunde voor hun nieuwe rol op te doen (capaciteit) en
• ondersteuning, ruimte en tijd moeten krijgen om het bij hun agile rol passende nieuwe gedrag te vertonen (gelegenheid).

Conclusie

Zorg als verantwoordelijke voor een agile transitie dat de drie factoren van het Triade gedragsmodel voor alle betrokkenen in de agile transitie voldoende aandacht krijgen. Alleen als alle drie de factoren positief scoren zullen mensen het gewenste gedrag gaan vertonen en zal agile kans van slagen hebben.

Naast mijn jarenlange kennis op het gebied van projectmanagement deel ik graag mijn ervaringen met het Triade model. Je kan hier meer over het Triade-model lezen. Indien je meer wilt weten, stuur dan een mailtje; bij voldoende interesse kan ik een workshop over het Triade gedragsmodel organiseren. In ieder geval wens ik je veel succes met je verandertrajecten. 

Remco Reitsma – ProjectReports – Tel. 06 – 53 24 77 43 – [email protected]

Een groeiend aantal organisaties werkt al volgens een agile methode of is bezig een agile methode in te voeren (meer over agile kan je vinden in eerdere blogs). Bekende voorbeelden zijn Spotify en ING. Zeker in organisaties die nog in de transitie naar agile zitten krijgen projectmanagers en product owners met elkaar te maken, terwijl de besturing (governance) soms nog niet goed is ingericht. In die situatie zag ik een paar keer een krachtmeting ontstaan tussen een projectmanager en een product owner omdat ze het niet eens werden over de prioriteit die een product owner gaf aan een ‘user story’ (het werk) van deze projectmanager. Dat is eigenlijk best merkwaardig en heeft mijns inziens te maken met het ontbreken van heldere afspraken. Dus je kan er wat aan doen: afspraken maken!

Het gaat niet om persoonlijk winnen!

In een ideale situatie zou de projectmanager niet met een product owner moeten wedijveren. Het zou moeten gaan om datgene voorrang te geven dat topprioriteit voor de organisatie heeft. Maar de projectmanager wil zijn project op de afgesproken datum opleveren en de product owner kijkt bij de voorbereiding van een sprint welke user stories de hoogste business waarde opleveren. Dan zie ik het gebeuren dat een project met de hoogste prioriteit (bijvoorbeeld invoering van de AVG) wordt vertraagd, omdat de product owner een andere user story, die volgens hem een veel hogere businesswaarde oplevert, voorrang geeft. Met als gevolg dat de projectmanager het gevraagde niet geleverd krijgt. Met als risico dat het project vertraagt.

Wie grijpt er dan in? De opdrachtgever van het project heeft niet de hiërarchische bevoegdheid om de product owner hierop aan te spreken. In organisaties waarin agile bottom-up wordt ingevoerd krijgt het inrichten van de besturingslaag boven de product owner soms te laat aandacht. De projectmanager en zijn opdrachtgever hebben dan geen logisch aanspreekpunt om te escaleren. Waardoor de product owner te veel speelruimte krijgt met als risico dat hij/zij te weinig oog heeft voor het organisatiebelang. Projecten lopen daardoor onnodig risico op vertraging.

Wat te doen?

Regel het! Bepaal eenduidig aan wie een product owner in jouw organisatie rapporteert. Dat is dan het logische aanspreek/escalatie-punt voor projectmanagers en opdrachtgevers die de prioritering ter discussie willen stellen. In bijvoorbeeld het Scaled Agile Framework (SAFe) vind je handvatten hoe je de besturing kan inrichten.

Zelf vergelijk ik de samenwerking tussen projectmanager en product owner als een soort intern leverancierscontract. Leg een paar afspraken tussen project en product owner vast, bijvoorbeeld dat het op te leveren werk gedurende het benodigde aantal sprints de hoogste prioriteit zal houden. En als je als project sterk afhankelijk bent van een product owner adviseer ik om die product owner op te nemen in je stuurgroep, net zoals je met een belangrijke leverancier kan doen.

Nog een persoonlijke tip: Meet de tevredenheid van de stakeholders

Ook ben ik een groot voorstander van meten en zichtbaar maken. We meten wat klanten van ons vinden, we geven ratings aan leveranciers, scrum teams meten de team-happiness en we vragen bij een sprint-demo wat de product owner van het opgeleverde werk vindt. Mijn tip is om structureel de tevredenheid van alle stakeholders van een product owner te meten, gewoon uitgedrukt in een getal. Onder die stakeholders reken ik ook de projectmanagers die met de product owners samenwerken. Zorg vervolgens voor communicatie van de gemeten resultaten binnen de organisatie.

Uiteindelijk streven we naar een samenspel om de organisatie waar je allemaal voor werkt te laten winnen. Een mooie gedachte toch? Regel dan ook de besturing goed.

Reageren?

Ik ben altijd benieuwd naar reacties van projectmanagers, product owners en porfolio managers, omdat we elkaar op die manier kunnen versterken.

Hoe vaak heb je het wel niet als ondernemer met een klant meegemaakt? Nadat iedereen zijn stinkende best heeft gedaan om de deadline te halen, zegt de klant: “Fijn bedankt, maar waarom kan ik dit er niet mee? En dat niet?

 

Zo’n domper op de feestvreugde wil je uiteraard graag voorkomen. Omdat ik al jaren binnen allerlei organisaties werk, heb ik gezien dat het ook anders kan. Ik ben zelf erg geïnspireerd geraakt door de Agile-methode. En een van de meest succesvolle toepassingen die ik daarvan ben tegengekomen heet Scrum. Het is namelijk gewoon leuker werken, heb ik gemerkt. Zoals ik in mijn vorige blog schreef is Agile op de eerste plaats efficiënter, maar de psychologische kant – die vooral bij Scrum aan bod komt – spreekt me persoonlijk ook erg aan.

Je medewerkers worden er dus blijer van. En jij uiteindelijk ook! Want:

1. Medewerkers die rechtstreeks contact hebben met een klant en hun collega’s, voelen zich meer betrokken bij het project.
2. Als ze meer zeggenschap hebben over de gang van zaken, werken ze harder.
3. Is er een probleem, dan voelen ze zich meer verantwoordelijk om dat op te lossen.
4. Het is voor iedereen prettiger om niet maandenlang door te modderen maar op tijd bij te sturen. Dat geeft ook voor jezelf als manager/directeur een gerust gevoel.

Wat is ervoor nodig om van Scrum een succes te maken?

– Maak multidisciplinaire teams, dus stop medewerkers vanuit diverse disciplines in één team.
– Geef het team ook daadwerkelijk de kans om zelfstandig te werken en laat de controle los.
– Laat het team elke dag een kwartier met elkaar overleggen.
– Zorg voor krappe deadlines (elke twee of drie weken een versie opleveren).
– Nodig de klant en de productmanager uit voor de oplevering.

Even een uitstapje om iets te bewijzen…

Jaja, en wie zegt jou dat het inderdaad een succes wordt als je de werkwijze in je organisatie volledig omgooit? Goede vraag! In de ICT-sector is de Scrum-aanpak massaal omarmd en ook de ‘echte’ business werkt steeds meer volgens Scrum: marketeers, productmanagers en communicatie. Niet alleen bij start-ups. Meest bekende voorbeeld van grote organisaties is ING. In andere sectoren denk ik aan Buurtzorg Nederland. Deze zorgorganisatie was een van de eerste die met zelforganiserende teams werkte. Ze deden dat weliswaar niet officieel volgens de Scrum-methode, maar het basisprincipe was min of meer hetzelfde: de teams maakten zelf planningen, vakantieroosters, etcetera. Opeens wilde iedereen bij Buurtzorg werken. Nu hebben bijna alle thuiszorgorganisaties zelforganiserende of zelfsturende teams. De nieuwste trend is dat wijkverpleegkundigen niet alleen voor het verzorgen van een wond of de medicijnen langskomen bij cliënten. Ze mogen ook weer meer tijd besteden aan een praatje en vooral: meer zelf bepalen of dat praatje nodig is. Het beoogde doel: tevreden cliënten, tevreden familie en tevreden thuiszorgmedewerkers.

Reageren? Of wil je gewoon eens bijpraten? Tel. 06 – 53 24 77 43

Remco Reitsma

ProjectReports

Het vuistdikke handboek van mijn boardcomputer heeft mijn auto nooit verlaten. Hadden de makers maar van de organisatiemethode Agile gehoord, dan was het vast anders gelopen… Daarom: misschien is dit ook wel iets voor jouw bedrijf!

Is er ook een gewone term voor Agile?

Jazeker, Agile betekent wendbaar. Oftewel flexibel. Oftewel: snel inspelen op veranderingen.

Wat houdt Agile in?

Deze organisatiemethode is de laatste tijd vooral bekend geworden dankzij Spotify en ING. Inmiddels werken veel grote organisaties ermee. Agile is gebaseerd op het Agile Manifesto, dat uit 12 principes bestaat. Een van de belangrijkste principes is (vrij vertaald):

Simpel, simpeler, simpelst

Werk je met Agile dan stelt de klant geen lange lijst met wensen over en doe je er ook geen jaar over om een systeem te bouwen – zoals vooral bij IT-projecten gebruikelijk is. Een multidisciplinair team gaat aan de slag en levert na twee of drie weken een eerste versie af. Klanten en collega’s mogen daar feedback op geven en vervolgens past het team het product of de software aan. Met elke feedbackronde wordt het beter en je gaat door tot het goed genoeg is.

Om even advocaat van de duivel te spelen…

Je zou zeggen: “Dat kost toch juist extra tijd?” In de praktijk is dat niet zo. Werk je volgens de traditionele methode dan wil de klant als je klaar bent immers bijna altijd dat je van alles aanpast. En dat is die klant ook niet helemaal aan te rekenen. Toch? Vaak komt het door nieuwe inzichten, nieuwe ontwikkelingen, interne personeelsverschuivingen of doordat hij eigenlijk niet helemaal wist wat hij wilde. Of de klant is in een andere valkuil gevallen: je hebt er op zijn verzoek allerlei zaken in gestopt die niemand uiteindelijk gaat gebruiken.

Praktijkvoorbeeldje:

Het is alweer enige jaren geleden, maar ik herinner mij nog erg goed dat een collega een heel simpel rekenmodelletje voor tussenpersonen in de hypotheekbranche ontwikkelde. Het programma kon maar 1 ding: het rekende precies uit wat een potentiele koper netto en bruto aan zijn hypotheek kwijt zou zijn. In eerste instantie gingen de wenkbrauwen wel even omhoog, maar uiteindelijk is het een prijswinnend rekenmodel geworden. En uiteraard konden de tussenpersonen uiteindelijk ook een print maken en een grafiek tevoorschijn toveren op hun laptop. Want dat is wat ze graag wilden. Dat doet mij sterk denken aan mijn boardcomputer. Meer dan gps, blue tooth en radio heb ik in de auto niet nodig. Jij wel?

Volgende keer: Hoe krijg je blijere medewerkers?

Reageren? Of wil je gewoon eens bijpraten? Tel. 06 – 53 24 77 43

Remco Reitsma

ProjectReports