De ultieme demo – waarom het niet kon en hoe het toch lukte

Door Arjen Uittenbogaard

Ik beschreef eerder hoe we aan het begin van het project het prachtige idee kregen om bij de project kickoff het end-to-end proces te simuleren. Dit zou dan de eerste demo annex integratietest zijn die de teams gaven. Die kickoff met de simulatie hebben we inmiddels achter de rug. Ik beschrijf hieronder hoe het liep en wat het opleverde. Maar eerst wil ik ingaan op alle bezwaren die ik in de voorbereiding allemaal te horen kreeg. Diverse projectleden waren ervan overtuigd dat zo’n simulatie een slecht idee was.

De bezwaren klonken redelijk: met z’n veertigen een proces nabootsen dat nog niet bestond, dat kon alleen maar tot veel verwarring leiden. Het was nog veel te vroeg in het project om nu al zoiets te proberen. We zouden allerlei discussies krijgen tussen mensen die er te weinig van af wisten. Het zou, voor je het weet, niet meer over het proces gaan, maar over wat in welke IT-component zou worden afgehandeld. Mensen zouden hoofd- en bijzaken niet kunnen onderscheiden en voor je het wist zouden we niet meer met een eenvoudig scenario bezig zijn, maar de uitzonderingen op de uitzonderingen van de alternatieve paden aan het bespreken zijn. Kortom, zou het niet veel beter zijn als een van de business analisten het toekomstige proces gewoon aan de groep zou presenteren?
Gelukkig was ik niet de enige die ervan overtuigd was dat de simulatie wel degelijk een goed idee was. Een van de specialisten die betrokken was bij tal van implementaties van nieuwe processen had heel goede ervaringen met deze werkvorm. En ook de projectleider zelf durfde het experiment wel aan. Dus uiteindelijk hebben we het gewoon gedaan, op dag twee van de kickoff.

In de inleiding heb ik heel duidelijk gemaakt wat we gingen doen en wat het wel en wat het niet pretendeerde te zijn. Deze simulatie was geen presentatie van het hele proces met al zijn uitzonderingen. Het was een doorloop van enkele eenvoudige scenario’s met als doel te ontdekken welk team voor welke delen van het proces verantwoordelijk was. Het was niet de bedoeling om harde afbakeningen te komen, maar juist om te ontdekken waar de teams tijdens het ontwikkelwerk met elkaar zouden moeten samenwerken. Ik kondigde aan dat ik de discussies binnen de perken zou proberen te houden en dat er vast wat verwarring zou ontstaan, maar dat dat erbij hoorde. Ook in het project konden we de nodige verwarring verwachten, dus mooi dat we nu al een beetje konden ervaren hoe we ermee zouden kunnen omgaan.

En het werkte.
Natuurlijk niet zo supertof en gladjes als ik had gehoopt. In plaats van drie scenario’s te doorlopen in de anderhalf uur die we hadden, kwamen we niet verder dan één. Er werd best veel gediscussieerd. Maar wat leverde dat een hoop op! Al vrij snel kwamen de architecten erachter dat de manier hoe er binnen het project over de systeemarchitectuur gedacht werd totaal verkeerd was. Na de kickoff zijn ze als de sodemieter aan de gang gegaan om in alle teams duidelijk te maken hoe die wel in elkaar stak en wat dat voor dat team betekende.
Tijdens de simulatie weken we ook vrij snel van het voorgekookte scenario af omdat de man uit de praktijk, die de operator speelde in de simulatie, op verschillende punten kon aangeven dat er zaken niet klopten met hoe het momenteel ging of hoe het volgens wet- en regelgeving zou moeten gaan.
Product Owners van verschillende teams discussieerden al tijdens, maar ook na de simulatie met elkaar over punten waar hun deeloplossingen elkaar zouden raken. Interface-discussies werden meteen beslecht of in elk geval werden afspraken gemaakt voor vervolgoverleg.
Het team dat verantwoordelijk zou worden voor de component die de workflow zou gaan regelen besloot ter plekke hoe ze vanaf de eerste demo ervoor zouden zorgen dat er een raamwerk zou staan waarbinnen elk team zijn increment kon inpassen, zodat ook daadwerkelijk elke week een geïntegreerde demo kon worden gegeven.
Na deze simulatie hadden alle teamleden, ook degenen die tot dan toe nog niets wisten over het project, hadden nu een gedeeld beeld van de context van hun werk in de komende maanden.

De ultieme demo, nog vóór het project gestart is, was een succes. Ik kan het iedereen van harte aanbevelen!

Arjen Uittenbogaard

Arjen is verhalenverteller. Een training van hem is een ervaring die je niet licht vergeet. Hij is ook regisseur van improvisatietoneel. Dat vindt hij een mooie metafoor voor zijn werk in het coachen van teams en individuen in organisaties die meer agile willen worden. Want dat is zijn expertise: agile werken. Daar heeft hij al twintig jaar ervaring mee en daar is hij goed in. Zijn hart gaat uit naar de menselijke kant van het werk, naar de communicatie en de samenwerking. Daarbij weet hij alles van complexe adaptieve systemen: omgevingen waarin niets is wat het lijkt, waar best practices je op het verkeerde been kunnen zetten en waar je steeds zult moeten experimenteren en leren. Ook heeft hij nog steeds lol van zijn achtergrond in object georiënteerde softwareontwikkeling: hij mag ontwikkelaars graag uitdagen op hun ontwerpen en de toepassing van design patterns daarin.

06 - 59 443 440

Andere posts

Klik hier