De Agile projectgroep
11 april 2016 • 4 minuten lezen
In elk project is het duidelijk: je hebt een doel te behalen en een beperkte hoeveelheid tijd om daar te komen. Maar hoe kom je daar, zonder dat je moet haasten, maar toch altijd op tijd? Binnen Topicus zijn we continu met deze vraag bezig. Tijdens mijn opleiding tot industriëel ontwerper heb ik vaak in projectverband moeten samenwerken en heb daarvoor dezelfde basis gebruikt die we binnen Topicus elke dag weer toepassen.
Je maakt er al vroeg kennis mee tijdens je studie: je moet samenwerken met je medestudenten. Het is belangrijk om goed te leren samen te werken, want er zijn weinig bedrijven die op zoek zijn naar ‘die ene narcistische einzelganger’.
Agile proces
Naast op persoonlijk niveau samenwerken is het minstens zo belangrijk om als team te performen. Voor mij is dé manier om goede performance te bereiken het Agile-proces. En dat werkt op veel meer plaatsen dan in softwareontwikkeling. Een project op de universiteit/hogeschool is vrijwel altijd vast in resultaat (verslag, deliverable, etc.), maar open in proces. De begeleiding die er is, is voornamelijk om het didactisch proces te borgen en te zorgen dat de werklast eerlijk verdeeld is. Ook speelt de begeleider vaak de rol van opdrachtgever.
Veel voorkomende aanpak
Een veel voorkomende aanpak om naar een eindresultaat toe te werken is door die deadline op een kalender aan te strepen, en vanaf daar terug te gaan plannen. Eerst grof (‘twee weken voor verslag schrijven’, ‘dat product krijgen we wel af in een week’) en daarna misschien preciezer. Op die manier kun je de hoeveelheid tijd die je uitgeeft budgetteren tegen de beschikbare tijd; het heeft immers geen zin om zes weken werk in analyse en onderzoek te steken als het totale project zeven weken mag duren. Ook voelen docenten zich ongemakkelijk bij projectgroepen die zich een week voor de deadline met een afgerond verslag melden. Dat tezamen betekent dat deze logische manier vaak niet helemaal werkt: je onderschat het werk en hebt daardoor aan het einde tijd te kort (wie heeft er niet een nacht doorgehaald om het verslag op tijd bij de printshop te krijgen?). Of je overschat het werk en komt er aan het eind achter dat je meer tijd aan een van de onderdelen had kunnen besteden.
Elk project draai je met een nieuw team, en de opdrachten liggen in onderwerp en opdracht vaak ver uit elkaar, waardoor het moeilijk is door ervaring grip op de planning te krijgen.
Deze situatie komt niet alleen op school voor – het is een probleem waar projecten al sinds mensenheugenis mee stoeien. Projecten worden klassiek als waterval gedraaid – zodra er een stap klaar is als voorbereiding van de volgende, ga je door naar de volgende stap, en nooit terug. Door deze structuur is een kleine fout in het begin desastreus voor het verloop van het project. Als je op dag 1 begonnen bent met een foute aanname, en aan het eind bij het schijven van het verslag blijkt dat je daardoor geen antwoord kan geven op de opdracht, heb je een groot probleem.
Agile Manifesto
In software-land is het daarom gebruikelijk om op Agile wijze te werken. Hierin wordt het belangrijk gesteld om regelmatig werkende software op te leveren, in plaats van soms. Ook is het belangrijk om bij elke oplevering de klant tevreden te stellen, en door die continu terugkoppeling ervoor te zorgen dat de hoeveelheid werk die niet gedaan wordt, gemaximaliseerd wordt. De volledige Agile Manifesto vind je terug op agilemanifesto.org.
Agile vertaalt naar woorden als behendig, lenig, vlug. Door steeds een klein brokje deliverable helemaal af te handelen ben je na elk brokje weer klaar voor wat nieuws, ook als dat iets heel anders is. Bovendien heb je elke keer iets te tonen aan elkaar, want als het niet toonbaar is, is het niet klaar. Dat maakt dat je elkaar gemakkelijk en eerlijk kunt controleren, verbeteren en aanvullen om de kwaliteit te maximaliseren. Als je dit vertaalt naar teamwerk voor universiteitsprojecten passen de agile-principes erg goed (zelfs als het onderwerp niet software-gerelateerd is). Door elke dag weer je best te doen dat wat je uitgezocht hebt of gemaakt hebt niet alleen verslagwaardig is, maar ook daadwerkelijk in het verslag en de deliverable geintegreerd is, heb je aan het eind van de rit geen stress. Op elk moment kun je aan de ‘klant’ en aan de rest van je team je prototype laten zien (van zowel je product als je verslag) zodat je kunt toetsen of dat naar verwachting is. Dat voorkomt discussie aan het eind van de rit. En je kunt zoveel brokjes oppakken als je zelf wil, totdat de tijd op is. Doordat resultaten vaker zichtbaar zijn is bijsturen makkelijker en minder ingrijpend. Zodra de deadline zich aandient heb je nooit teveel werk gedaan: je zit maximaal een fractie van een brokje voorbij je target. Dat zorgt er voor dat je makkelijk en zorgeloos je project kunt inleveren.
Bovendien heb je gaandeweg een onmisbare skill geleerd, waar werkgevers heel erg blij van worden: jij kunt een project soepel, on-time, on-budget afronden, met tevreden collega’s en klanten als gevolg!
Tobias Oort heeft Industrial Design Engineering gestudeerd aan de Universiteit Twente en is nu werkzaam als software-engineer bij Topicus , en werkt daar samen met collega’s aan het hypotheekadviespakket Findesk.
Meer informatie?
Kijk op de website van Finance voor meer informatie of neem contact op met Topicus