Ik was laatst betrokken bij een workshop waarbij ter introductie twee plaatjes gebruikt werden om het verschil uit te leggen tussen ‘incrementeel ontwikkelen’ (de watervalmethode) en ‘iteratief ontwikkelen’ (agile):
A- Incrementeel (waterval):
B- Iteratief (agile):
De plaatjes willen laten zien dat bij een ‘waterval proces’ alles eerst wordt uitgedacht en je pas helemaal op het einde een werkend product hebt. Bij een agile proces denk je niet alles van te voren uit maar ontwikkel je in stappen een product wat in elke fase ‘werkt’ (zij het in rudimentaire vorm).
De maker van deze plaatjes, Jeff Patton, hield in zijn artikel uit 2007, ‘Don’t know what I want, but I know how to get it’, een pleidooi voor de agile werkmethode. Het is een prima artikel, al was het maar vanwege de Sex Pistols quote, maar… je kunt duidelijk zien dat Jeff een softwareontwikkelaar is en geen UX ontwerper.
De plaatjes kloppen niet
Het artikel is al zeven jaar oud, maar het Mona Lisa voorbeeld wordt nog steeds gebruikt. Het wordt denk ik tijd om uit te leggen dat de plaatjes verkeerd zijn. Want waar zijn hier de ontwerpers??
De waterval
Creatieve processen lijken wel magisch. Hoe krijgt iemand de Mona Lisa in zijn hoofd? Wanneer ik naar het watervalplaatje kijk, wordt dat zo uitgebeeld:
Voila, bam, daar is ze al, bedacht door een genie! Vervolgens hoef je het alleen nog maar uit te voeren, simpel toch?
Nee, het is niet zo simpel: er is werk aan om tot zo’n beeld te komen en het is wel erg krom dat dat werk in dit voorbeeld buiten het proces wordt geplaatst. Alle ontwerpgeheimen onthullen gaat hier te ver, maar een tipje van de sluier kan ik wel onthullen. Met ontwerp erbij ziet waterval er zo uit:
Agile
Hmm, lijkt dat ontwerpproces hierboven niet heel erg agile? Inderdaad, ik heb het agile voorbeeld ervoor geplakt. Maar dat voorbeeld ís helemaal niet agile, er wordt juist een waterval ontwerpproces uitgebeeld!
Waarom? Hierom:
- De functionaliteit en vorm van de eerste versie is volledig gelijk aan de laatste versie. Alles zit er meteen al in.
- De eindvorm is ook al meteen in de eerste versie definitief, ze is alleen ‘mooier geworden’.
Kijk nog maar eens goed: de eerste Mona kan al kijken, ruiken, lachen, praten, hoofd draaien, neuspeuteren enzovoort. En.. de ze is direct te herkennen als Mona Lisa. Het ontwerp is staat van begin al vast, het wordt alleen maar verder aangekleed.
Zo zou agile helemaal niet moeten werken. In de eerste oplevering is een ‘werkende versie’ voldoende en daarbij draait om het bereiken van doelen, niet van functionaliteit. De Mona Lisa is wereldberoemd vanwege haar blik en haar glimlach. De eerste versie had er dan ook best zo uit kunnen zien:
Vervolgens ga je als volledig team, ontwerpers en ontwikkelaars tegelijk, aan de slag om tot een eindproduct te komen. Daarbij is de insteek van agile dat je kunt sturen. Uit de eerste versie kan dus uiteindelijk best de Mona Lisa ontstaan (wanneer iedereen binnen het team een genie is), maar het had ook heel goed dit succesvolle product kunnen worden:
Voordeel en valkuil
In een echt agile proces weet je dus niet van te voren wat voor vorm er uit komt. Dat is ook de kracht ervan. Maar zo flexibel als ik het hierboven schets (Mona Lisa of Sponge Bob), gebeurt het eigenlijk nooit. De vorm staat meestal wel degelijk van te voren vast. Dat gebeurt dan meestal in een ‘conceptfase’ of een ‘sprint x’, buiten het werkelijke project om. Het ontwikkelen zelf richt zich daarna vooral erop het product ‘werkend‘ te maken, en niet meer op de vorm waarin het moet werken.
Ik snap het wel; het kost allemaal tijd en geld, maar ik vind het toch jammer. Doordat vorm en project zo uit elkaar getrokken worden, blijft ontwerp binnen een agile proces nog steeds een wat ondergeschoven kindje. Terwijl er zo veel kansen liggen, als je maar durft.