/img/coolprofs_logo_full.png
Schrijf mij in voor de nieuwsbrief
Ready? Set? GO!

Ready Set GOVoldoen de User Stories aan de Definition of Ready? Is de sprint ingepland? Dan kunnen we los! We sprinten erop los. De scrummaster ziet erop toe dat het beste uit het team wordt gehaald en dat er geen impediments zijn. De Product Owner (PO) zet zich in om aan het team uit te leggen wat hij wil en in welke volgorde. Het ontwikkelteam bouwt wat er in de User Stories beschreven staat. Die User Stories worden als warme broodjes opgeleverd bij de PO en in rap tempo worden de gestelde sprintdoelen gehaald.

En zo wordt het nieuwe systeem sprint na sprint steeds groter. Dan volgt de eindgebruikerstest, of erger nog, het systeem gaat live. En dan blijkt dat ondanks alle tussentijdse demo’s en tests die tijdens de sprints zijn uitgevoerd, het systeem toch niet helemaal voldoet aan de wensen van de gebruikers. De interface is toch niet intuïtief genoeg. Of het systeem voldoet niet aan de eisen van de architectuurboard. Data blijken dubbel te worden opgeslagen met als gevolg een stuk refactoring. Dat willen we niet.

Wat wil je en waarom?
Gelukkig is dit verhaal aangedikt en meestal niet één op één van toepassing op ontwikkeltrajecten. Maar toch gebeurt het nog wel eens dat er iets gebouwd wordt dat achteraf aangepast moet worden. Vanzelfsprekend kun je niet alles vooraf bedenken. Daarom werken we ook agile; al doende wordt het steeds beter. IKIWISI, I Know It When I See It. De opdrachtgever weet bij aanvang niet precies wat hij wil. Vol goede moed bouwt het team een eerste versie. En dan weet hij het wél. Het moet niet zoals in die eerste versie. Met wat aanpassingen wordt het precies zoals hij het wil.

Ready Set GODe andere kant van de medaille is dat we de Preliminairy Investigation nog wel eens overslaan, de allereerste fase van een systeemontwikkelingstraject zoals 30 jaar geleden omschreven door H.L. Capron in “Systems Analysis and Design”. In deze fase zijn we op zoek naar de prikkel of wens om te veranderen. Je klimt als het ware in de huid van de klant om te begrijpen wat hij wil, maar belangrijker nog, waarom hij het wil.

Ik volgde onlangs een workshop Design Thinking, over de zoektocht naar het dieperliggende ‘waarom’. De vraag achter de vraag. Waarom hebben klanten/gebruikers ergens behoefte aan? Wat zit er achter een opmerking van een klant? Een voorbeeld:

De kleur van een knop in een scherm moet in bepaalde gevallen rood kleuren volgens de gebruiker. Waarom moet die knop rood kleuren? Waarom niet blauw? Nou, zegt de gebruiker, omdat we met rood willen aangeven dat deze actie met spoed uitgevoerd moet worden. Kijk, nu weten we dat de gebruiker blijkbaar behoefte heeft om prioriteit aan te kunnen geven in het scherm.

Op zoek naar de drijfveer
Met de achterliggende reden van een bepaalde wens of behoefte kunnen we creatieve, out of the box oplossingen bedenken die waardevol zijn voor deze gebruikers. Het is hier bij de kunst om de gedachtes of gevoelens van de gebruiker aan te voelen.

Wat Capron in 1985 al optekende, heeft veel weg van het hedendaagse Design Thinking (DT). In beide gevallen staat de ervaring van de klant/gebruiker centraal. Hij ervaart immers waarde door het gebruik van producten en diensten om zijn doelen te realiseren. Daar waar Capron een meer analytische aanpak hanteert om de prikkel voor verandering te achterhalen, is DT een creatief proces, dat - anders dan analytisch denken - zorgt voor het generen van goede ideeën. DT past in dat opzicht heel goed in een Preliminairy Investigation waar we op zoek zijn naar de incentive, de rationale, de drijfveer van de klant.

Zonder te pleiten voor het herintroduceren van de watervalmethode wil ik wijzen op het belang van de Preliminairy Investigation fase voorafgaande aan een softwareontwikkelingstraject. Dit belang wordt nog wel eens onderschat. Ik wil niet terug naar comprehensive documentation over working software. Maar het is wel belangrijk om bij aanvang van een softwareontwikkelingstraject een stapje terug te doen om de behoefte en de context waarbinnen die behoefte leeft in kaart te brengen. In welke bedrijfscontext moet de applicatie functioneren? Wat zijn de interfaces met andere systemen? Welke bedrijfswaarde creëert de applicatie? Deze informatie stelt je in staat om een globaal procesmodel en gegevensmodel op te stellen. Hiermee voorkom je dat er uiteindelijk een applicatie staat dat los van de omgeving functioneert. Het resultaat is een vooraf gedefinieerde systeemarchitectuur.

Bij CoolProfs onderkennen we de noodzaak van een  Preliminairy Investigation fase en hebben we een dergelijke fase verwerkt in onze agile werkmethodiek. We noemen het Architected Agile en dit vindt plaats in onze sprint 0. Door Architected Agile kan refactoring worden voorkomen en krijg je een goed fundament om op te bouwen. Preliminairy investigation, Design Thinking, Architected Agile, allemaal termen uit een eigen tijdsperk en voor een bepaalde doelgroep, maar eigenlijk komt het neer op een stukje voorbereiding, “Reflect before you act”.

Reflected? Ready? Set? GO!

Meer weten over Architected Agile? Neem contact op met ons op en vraag naar onze Way of Working.

Deze site maakt gebruik van cookies om te leren over hoe de site gebruikt wordt en wat er beter zou kunnen.
Behoud de cookies en optimaliseer mijn website beleving.