Overslaan en naar de inhoud gaan

De ultieme agile checklist: 7 tips om van je project een succes te maken

Thomas van Eldijk
 | Bijgewerkt op 22 maart 2022

Wanneer je van plan bent om een team van ontwerpers en of developers op een agile manier te laten werken  dan heeft dat veel voordelen maar het kan ook even wennen zijn. In dit artikel geef ik je 7 tips die jou als opdrachtgever helpen om van je project een succes te maken.

Wat is agile? 

Agile werken is door de twee Japanse wetenschappers Takeuchi en Nonaka bedacht voor een nieuwe ontwikkeltechniek. Ze zagen kleine teams in korte periodes prototypes ontwikkelen bij bedrijven als Honda en Toyota. Deze kleine teams konden zich sneller aanpassen, voerden continu verbeteringen door en werden daardoor productiever en behaalden betere resultaten. 

Deze flexibele werkmethode wordt ook wel agile genoemd. Door alleen de tijd en kosten vast te stellen en niet het uiteindelijke resultaat, ontstaat de vrijheid om binnen de afgesproken tijd aanpassingen te maken die worden verkregen met nieuwe inzichten tijdens het ontwikkelen. 

Door de tijd in sprints op te delen, ontstaan ontwikkeletappes waardoor meerdere start- en eindpunten ontstaan. Deze punten geven de gelegenheid om te herijken, af te wegen wat belangrijk is, of om van koers te veranderen.

De belangrijkste voordelen van agile werken met sprints zijn:

  • Van tevoren staat vast hoeveel tijd en budget het ontwerpen en ontwikkelen van je project gaat kosten.
  • Je hoeft geen eindeloze specificaties door te geven. 
  • Je kunt steeds bijstellen en bijsturen. Handig voor als je nog niet 100% zeker bent van hoe het eindproduct eruit moet zien.

De grootste nadelen van agile werken met sprints zijn:

  • Het is niet zeker waar je mee eindigt. Misschien dat je gaandeweg meer prioriteit stopt in bepaalde onderdelen en daardoor minder oog hebt voor kleine details.
  • Je bent als opdrachtgever meer betrokken en moet tijdens de ontwikkeling vaak input leveren en keuzes maken. Dat kost tijd en maakt je medeverantwoordelijk voor het succes.

Het alternatief: de watervalmethode

Tegenover agile staat de watervalmethode. Hierbij som je als opdrachtgever alle specificaties op, het bureau koppelt er een vaste prijs en tijd aan. 

Het lastige hierbij is dat je zeer volledig moet zijn als opdrachtgever. Wanneer je onderdelen niet benoemt, gaan ze ook niet mee in de ontwikkeling. Vaak ontstaan tijdens de ontwikkeling nieuwe onderhandelingen over specificaties die gekoppeld moeten worden aan prijs en tijd. Hierdoor wordt het een stroperig proces waarbij vaak al tijdens de ontwikkeling het besef komt dat de richting anders moet, dat er onderdelen missen, of dat die misschien ontwikkeld worden terwijl ze niet meer nodig zijn. 

Naast de volledigheid moet je als opdrachtgever bij de watervalmethode vooraf ook een compleet inzicht hebben in de techniek en de mogelijke opties. Je kunt tussentijds niet meer bijsturen wanneer blijkt dat de oplossing die je voor ogen had eigenlijk niet past bij het doel dat je probeert te bereiken.

Dit verklaart waarom de agile werkmethode zo ontzettend populair is geworden in alle sectoren waar men aan ontwikkeling doet. Van ICT tot de bouw. Zodra er een website of applicatie opgezet wordt die uit meer dan alleen een online brochure bestaat, is agile ontwikkelen al snel in het voordeel.

Tips voor opdrachtgevers die agile gaan werken

Leuk en aardig allemaal, maar wat betekent dat agile werken nu voor een opdrachtgever? Wat moet je nu doen in plaats van een eisenlijst maken en deze maanden later controleren?

Hieronder noem ik enkele tips die we elke opdrachtgever mee willen geven. De meeste ervan zijn geleerd met vallen en opstaan en komen rechtstreeks uit de praktijk. Let op: dit is geen handleiding voor de agile werkmethode. Daar kun je letterlijk een boekenkast mee vullen. 

Dit zijn tips bedoeld voor opdrachtgevers bestaande uit communicatie-, marketing- en ICT-medewerkers die een team van designers en developers moeten aansturen tijdens een agile project.

1# Maak de agile werkmethode duidelijk bij de managers en leidinggevenden

Nog niet iedereen is bekend met agile werken en het kan voorkomen dat een directie niet begrijpt waarom alle features niet meteen bij de eerste oplevering aanwezig zijn. Of dat er gaandeweg het project gekozen is voor een andere functionaliteit die beter aansluit bij de doelgroep. 

Maak daarom duidelijk aan je collega’s en de management/directielaag van je organisatie dat het project met een agile methode wordt ontwikkeld. Dat daar voordelen aan zitten, zoals een vast aantal sprints met een vaste prijs en vaste ontwikkelperiode, maar dat gaandeweg bepaald wordt welke functionaliteiten worden ontwikkeld en hoe de website of applicatie wordt ingericht.

Door iedereen binnen de organisatie ervan bewust te maken hoe de applicatie of website ontwikkeld wordt ontstaat een constructieve houding ten opzichte van het project: hoe kunnen we het nog beter maken, welke functies missen we nog die we in een volgende release kunnen opzetten? 

Het is een hele andere manier van werken dan bij de watervalmethode, waar je een checklist afloopt van alle features die enkele maanden geleden bedacht zijn.

2# Maak een goede backlog

Dit is eigenlijk de agile variant van de wensen/eisenlijst binnen de watervalmethode. Binnen de wensen/eisenlijst is het heel gebruikelijk dat er een lijst wordt gemaakt van mogelijkheden die een website of webapplicatie moet bevatten. 

Bij Emble hebben we al duizenden van deze lijsten doorgekregen en meestal bevatten ze voor een groot gedeelte dezelfde wensen en eisen. Denk aan: de applicatie moet er overzichtelijk uitzien, de website moet goed beveiligd zijn. 

Dat is ook logisch, want als opdrachtgever weet je niet precies wat ervoor zorgt dat het overzichtelijk of veilig wordt. Omdat bij een agile ontwikkelmethode de scope niet vastgesteld wordt is er ruimte om na te denken waarom iets ontwikkeld zou moeten worden.

Agile werken daagt je als opdrachtgever uit om na te gaan denken over wat je nu echt nodig hebt. Of beter gezegd: wat je doelgroep nodig heeft. Voor wie ga je iets laten maken? Wat is het doel van deze doelgroep? En waarom? 

Deze ‘user stories’ vertellen een verhaal over wie je wilt bereiken en waarom. Het maakt het project vele malen inzichtelijker voor jou en het team dat voor je gaat ontwerpen en ontwikkelen. Daarnaast dwingt het je om keuzes te maken of op zijn minst na te denken over welke doelgroepen nu echt belangrijk voor je zijn. Het kan je ook inzicht geven over wat nu haalbaar is (in de aankomende sprints) en wat je in een volgende fase kunt gaan bereiken.

3# Stapje voor stapje

Wanneer de user stories gereed zijn is het een kwestie van starten. Vaak lijkt een project heel groot. Zo groot dat het bijna verlammend werkt. Er zijn dan oneindig veel redenen om niet te starten met het project en nog even te wachten op een user-feedbackonderzoek of het nog even uit te stellen tot een aanpassing in het brandbook. 

Maar in tegenstelling tot de watervalmethode hoeft niet alles vooraf bekend te zijn voordat wordt gestart. De kracht van agile werken is juist dat door te starten er meer en nieuw inzicht ontstaat.

4# Houd de vinger aan de pols

In tegenstelling tot de watervalmethode, waarbij een opdrachtgever met name voor- en achteraf aan tafel zit met het design & developmentteam, communiceer je binnen de agile ontwikkelmethode veel vaker met degenen die het werk uitvoeren. Je bent immers wendbaar en moet soms bijsturen. 

Het is gebruikelijk om in ieder geval wekelijks een overleg te plannen met het team, waarbij je kunt bespreken hoe de voortgang verloopt, welke input nodig is of knopen kunt doorhakken over beslissingen die genomen moeten worden. 

Naast dit wekelijkse overleg werken de meeste agile teams met een projectmanagementsysteem waarin je alle werkzaamheden kunt volgen en waarin je per taak input kunt geven. Het bijhouden en tijdig terugkoppelen van feedback zorgt ervoor dat het design & developmentteam door kan werken en dat je als opdrachtgever weet wat er speelt.

5# Plan voldoende tijd voor jezelf en collega’s in

De wekelijkse calls en het aanleveren van input kost tijd. Het is verstandig om hier voldoende ruimte voor in te plannen. Daarnaast moet er ook voldoende tijd worden vrijgemaakt voor het testen van wat er is ontwikkeld of ontworpen. Meestal kun je dit niet alleen af en heb je hierbij collega’s nodig. 

Bij de start van een project is het daarom verstandig te vragen op welke punten binnen het project bepaalde onderdelen getest moeten worden en wanneer de feedback hiervoor idealiter binnen moet zijn.

6# Communiceer op eenduidige manier richting het design & developmentteam

Om goed te begrijpen wat er speelt en het team goed aan te sturen is het essentieel te communiceren binnen het gebruikte projectmanagementsysteem. 

Uiteraard hoeft niet de hele organisatie aanwezig te zijn binnen het projectmanagementsysteem. Sterker nog, dat kan misschien zelfs wat chaotisch worden. Wel is het verstandig op zijn minst een of twee mensen vanuit de kant van de opdrachtgever hier verantwoordelijk voor te maken.

Ze vormen op die manier niet alleen een brug tussen alle betrokkenen die aan het project werken, maar ze kunnen ook controleren of alle input die aangeleverd wordt eenduidig is. Het wil nog wel eens voorkomen dat het salesteam een andere beslissing neemt dan de afdeling communicatie waardoor het design & developmentteam niet precies weet wat de bedoeling is. Of zelfs werk opnieuw moet uitvoeren, wat zonde van de tijd is.

7# Experimenteer en kom er snel achter of iets werkt of niet

Binnen agile werken zal je misschien vaker de term ‘Fail fast’ gehoord hebben of gaan horen. Dat klinkt eng, maar dat ideeën mislukken is onderdeel van het ontwikkelen en verbeteren. Soms kan een idee zorgen voor een betere functionaliteit voor de eindgebruiker, soms kan het ervoor zorgen dat een project de helft minder kost. Het uitproberen van zo’n idee kun je het beste zo snel mogelijk doen, zodat er nog voldoende tijd is om indien nodig een alternatief pad te bewandelen.

Binnen onze projecten hebben we vaak te maken met de afweging of een complexe functionaliteit haalbaar is met de open-sourcetechniek die voor handen is. Direct op maat code schrijven is het zekere pad, maar het kan lonen eerst een 'proof of concept' op te zetten. 

De kans dat het mislukt is aanwezig, maar hier kun je het beste zo snel mogelijk achter komen. En mocht het slagen, dan is er binnen het project tijdwinst behaald. 

Gerelateerde artikelen

Wij delen graag de kennis die we in huis hebben

Reacties

Er zijn nog geen reacties geplaatst.