Een website ontwerpen met agile design en scrum

D-rent taskIn de herfst van 2008 zagen wij ons als bureau voor een bijna onmogelijke deadline gesteld: een complete website ontwerpen in vier weken. We zagen al snel in dat er maar één manier was om dit voor elkaar te krijgen: de agile manier.

Het zogeheten ‘scrum’-project dat daarop volgde was even spectaculair als effectief. De impact was enorm. Sindsdien hebben we veel agile projecten gedaan voor klanten als Albert Heijn, Ziggo, TNT Post, Sanoma en Nationale Nederlanden. We hebben geleerd het agile proces toe te passen en naar onze hand te zetten. Ook ontdekten we dat snelheid niet de enige reden is om agile te ontwerpen.

Agile (‘vlug en lenig’) werken is een manier om een project op te splitsen in korte overzichtelijke delen, steeds werkend naar concrete resultaten.In drie artikelen wil ik graag onze ervaringen delen en de basics van scrum uiteenzetten. Om mijn conclusie maar meteen weg te geven: agile is uitdagend, maar niet ingewikkeld. Het komt aan op durf, motivatie en openheid. Mijn advies aan ontwerpers: just do it!

Design versus development

AH scrum room

De toepassing van agile in de designwereld is nog vrij nieuw. Lang niet iedereen is ervan overtuigd dat er überhaupt een rol voor ontwerpers is weggelegd in agile. Agile is ontstaan in de software-wereld als agile development. Het is een ‘conceptueel raamwerk’ met daarbinnen een aantal methodieken, waaronder scrum.

Veel van wat er over agile wordt geschreven en gezegd is nog steeds sterk beïnvloed door de afkomst uit de software ontwikkelaars-hoek. Uit veel publicaties blijkt een moeizame relatie tussen ontwerpers en developers in agile methoden, verrassend genoeg nog moeizamer dan bij de ‘waterval-methode’, waarbij ontwikkeling volgt op het ontwerp. Velen, zoals David Farkas, Jonathan Arnowitz en Marc Sasinski berusten daarom in een subtiele scheiding van User Experience Design en Agile development.

Onze ervaringen tonen echter aan dat de methode heel goed toegepast kan worden op het ontwerpproces. Daarbij onderscheiden we twee ambitieniveaus:

  1. Integratie ontwerpers en klant. De ontwerpende disciplines en de klant werken gelijktijdig in één team. Dit is dus een agile project zonder ontwikkelaars in de kern van het team. Dat noem ik agile design.
  2. Integratie van alle disciplines, inclusief ontwikkelaars. Dit is wat ons betreft nog steeds de heilige graal van agile: volledige integratie. Ook op dit vlak hebben we ervaring opgedaan.

What the f*ck is scrum?

AH scrum board

Scrum is een vorm van agile werken. In feite is scrummen het samen duwen en trekken aan één project. Het hele proces is opgeknipt in kortlopende ‘sprints’ met strakke deadlines en duidelijke doelen. Interactieontwerpers, visueel ontwerpers en webontwikkelaars zitten niet rustig te wachten tot de ander klaar is, maar sprinten tegelijkertijd naar hun doel.

Scrummen gaat gepaard met speciale rituelen en technieken. De dagelijkse ‘daily scrum’ bijvoorbeeld, een staande bespreking van maximaal 20 minuten. Om ongestoord te kunnen scrummen en de samenwerking te intensiveren werkt iedereen samen in één scrum room.

Hoe pakken wij scrum en agile design aan?

De belofte van agile

Agile design heeft voor ons en voor onze klanten de volgende voordelen:

  1. Het is snel en de leverzekerheid is groot: op tijd én binnen budget.
  2. Ideeën, schetsen, twijfels, afspraken, alles wordt zonder drempel uitgewisseld.
  3. Het project heeft een zelfsturend karakter. Het team is zelf de drijvende kracht.
  4. Doordat zomin mogelijk informatie in computers blijft hangen, is het overzicht voor iedereen binnen oogopslag te krijgen.
  5. Er is een veel intensievere en effectievere band tussen opdrachtgever en bureau. Read my lips: No More Foam Boards!
  6. Door deze voordelen is de kwaliteit van het eindproduct hoger.

Waar zit de catch?

  1. Agile is niet goedkoper, voor wie dat verwachtte. De kosten zijn vergelijkbaar met de ‘watervalmethode’.
  2. Aanwezigheid van de klant in het ontwerpteam is essentieel.
  3. Agile vraagt veel van de openheid van de teamleden en de klant. Een agile team zou, om maar wat te noemen, ook relaxed een paar uur met elkaar in de kroeg moeten kunnen hangen.
  4. Agile projecten vragen veel energie. Wat doe je op de niet-scrumdagen? En wat gebeurt er met je bureauplanning als al je projecten agile zijn?

So here we are…

Dave Kelly, IDEO

Dave Kelly, IDEO

Agile design is ook voor ons nog een ontdekkingstocht. Maar de paradigmaverschuiving heeft zich voor ons al voltrokken. De centrale vraag is voor ons niet: “Hoe kan ik agile development combineren met mijn ontwerpproces” maar “Hoe kan ik agile toepassen op mijn ontwerpproces?”

Agile is niet het exclusieve speeltje van developers, waarbij ontwerpers aan de kant mogen meekijken. Move over, developers: designers are here to stay!

Nieuwsgierig naar meer? Deze post is deel één van drie. In drie artikelen wil ik jullie laten delen in onze ervaringen, en reacties horen. Nog volgen:

Interessant?

Lees dan ook onze andere artikelen over , , , , , , , , .

Reacties

  1. Interessant hoe designers met scrum/agile UP omgaan. Wij hebben op basis van deze technieken onze eigen agile methode ontwikkeld voor webdevelopment. Ik denk dan ook niet dat je vele methodes klakkeloos moet overnemen. Neem nou de dagelijkse staande scrum meeting. Voel jij je als designer prettig bij een dergelijke geforceerde (amerikaanse) werkwijze? Zulke dingen hebben we er dan ook snel uitgesloopt zodat het tenminste authentiek en nuttig lijkt, wat we aan het doen zijn.

    Ik heb nog 1 laatste opmerking over je artikel: je gooit mensen die niet bekend zijn met UP relatief in de diepte door niet uit te leggen wat agile/scrum nu eigenlijk is en wat er anders aan is.

  2. Ha Pieter,

    Mooie post! Wij hebben bij VONQ ook de Agile manier van ontwikkelen ontdekt. Op een minder gestructureerde manier dan hierboven omschreven wordt overigens. Maar wij werken dan ook met een kleiner team van slechts 4 betrokkenen.

    Het is een interatief proces waarbij je zeer intensief met elkaar samenwerkt met het design en ontwikkelteam. Ontwerp, bouw, evaluatie, ontwerp, bouw, evaluatie, etc. Net zolang totdat het gewenste eindresultaat er is. Deze “scrums” zoals jij dat noemt hebben wij dagelijks zeer kort over detail opleveringen en wekelijks over de overkoepelende planning en om vooruit te kijken naar volgende modules.

    Het voordeel is dat je tussentijds van koers kan veranderen door voortschrijdend inzicht, terwijl dat geen problemen oplevert voor het project. Niemand die daar raar van opkijkt. Sterker nog, het hoort er gewoon bij.

    Overigens passen wij in sommige deelmodules ook waterval methode toe. De methodieken lopen soms in elkaar over. Ik ben sterk voorstander van het gebruiken wat op dat moment het beste voelt. Soms is dat waterval, soms is dat Agile.

    Nogmaals, mooie post. Ben erg benieuwd naar meer detail en kijk uit naar de volgende artikelen.

    Mvg Remy Verhoeven
    (Partner VONQ en verantwoordelijk voor o.a. IT)

  3. Hi Pieter,

    Een mooi verhaal dat ik grotendeels onderschrijf. Bij een klant van mij hebben we net een 10 weken durend agile traject afgerond met meerdere backend integraties. Precies op tijd voor de commercial. Agile was, zeker weten, de enige manier om die deadline te halen.

    Ben benieuwd naar jouw volgende verhalen.

    Groet!
    Dick

  4. Klinkt eigenlijk meer als een zweepje voor de manager om je onderdanen meer te laten sprinten ;-) Wat met onverwachte vrije dagen, ziektes, motivatieproblemen bij teamleden? Zeker in een korte doorlooptijd is strakke planning van capaciteit wel een must.

    Interessant artikel én benieuwd naar de opvolgende artikelen.

  5. Onze SW Dev voor zowel app als website gaan sinds kort ook via deze methode, zeer tevreden en effectief.

  6. Een collega van mij van de opleiding Communication & Media Design (CMD) past deze agile aanpak toe in zijn (webdesign) projecten en hij is ook erg enthousiast erover. Dit artikel zet me weer aan het denken en ik vraag me nu weer af of deze aanpak ook werkt voor meer technische projecten (ik werk in de industriële automatisering). In die projecten zijn natuurlijk kritische eisen zoals veiligheid en betrouwbaarheid enorm belangrijk en dat zal altijd extra aandacht vergen. Het watervalmodel, wat we nu toepassen, vind ik niet zo geschikt, zeker ook omdat we eigenlijk altijd in een ‘concurrent engineerings omgeving’ zitten. GAMP (Good Automation Manufacturing Practice, veel toegepast in de industriële automatisering) is de methodiek die we nu gebruiken (eigenlijk ‘GAMP-light’, omdat de aanpak anders te veel ‘papierwerk’ vraagt van onze studenten) is echter een strikte watervalmethodiek. Ik ga je artikelen volgen en hoop in contact te komen met mensen die worstelen met dezelfde problematiek als ik…misschien moeten we wel een agile GAMP light op basis van DSDM gaan ontwikkelen ;-).

  7. Ik vind het dé manier om websites af te leveren op maat van de programmeurs en de klant.

    Spijtig genoeg zijn zij doorgaans NIET de gebruikers van de website. Het is immers de klant zijn klanten die het gaan gebruiken.

    Je kan geen goed concept afleveren wanneer je een beetje kennis hebt over die gebruikers, zijn manier van werken en zijn omgeving. Pas wanneer je een kritische massa aan gegevens hebt, dan pas kan je aan de slag en een website of applicatie afleveren op maat van die gebruiker.

    En neen, de klant weet doorgaans niet wie zijn klanten zijn en hoe die in elkaar zitten, maar zijn ego zal hem dikwijls wijs maken dat hij het allemaal wel weet.

    Wat hij wel heeft, is een perceptie, een gevoel over die klanten, maar dat schiet niet écht lekker op.

    Om alle misverstanden te vermijden, ik hou wel van Agile en Scrum toestanden. Ze zijn geschikt om iets te bouwen, maar niet om te ontwerpen.

    Stel je voor dat een huis werd ontworpen volgens een Agile procedure, do I need to say more? :)

    Omarm Agile, maar pas ook andere methodologieën toe, zoals het Fusion Usability Recept.

  8. Floris Nijdam |

    Goed verhaal.

    Een agile design team 1 stap vooruit laten werken op een agile development team lijkt een mooie middenweg. Het heeft ook te maken met de grootte en de doorlooptijd van een project. Kleine projecten onder hoge druk kan je beter helemaal agile doen, grotere projecten met langere omlooptijden opgesplitst zoals gesuggereerd.

    Overigens bied het volgende artikel ook mooie inzichten op dit onderwep: http://boxesandarrows.com/view/bringing-user

  9. Hi All,
    dank voor alle reacties. Eindelijk heb ik een moment om te reageren.

    @melvin — helemaal eens dat je je eigen draai moet vinden. Voor ons is de daily scrum wel essentieel, op die manier blijf je dagelijks op de hoogte van voortgang en afhankelijkheden binnen het team. Je hebt denk ik wel gelijk over “de diepte in”. Wellicht dat de twee volgende artikelen wat goedmaken :-)

    @remy — dank. Voortschrijdend inzicht is de motor waarop Scrum draait inderdaad. En het klopt dat af en toe een stukje waterval ook moet kunnen. Sommige dependencies zullen altijd blijven bestaan.

    @eijkb — ha! Een agile team dat op stoom is heeft helemaal geen zweep nodig :-) En je vraag: tja, common sense, denk ik. Of marge inbouwen, of improviseren zodra het gebeurt. Maar het kan spannend worden ja!

    @peter — ik ken GAMP niet, maar ik hoor na de volgende artikelen graag wat je denkt!

    @edwin — je hebt op alle punten gelijk, behalve de belangrijkste: dat Agile en User Centered Design niet samen zouden gaan. Daar ben ik het fundamenteel mee oneens. Ik ben groot voorstander van UCD en vind het belangrijk dat het benodigde user research en ook usability- of andere tests worden gedaan. Dit is prima te combineren met Scrum. In de navolgende artikelen zal ik hier dieper op in gaan. Als je bezwaar blijft, dan hoor ik het graag…

    @floris – yep.

    Groeten,
    Pieter

  10. Pieter,

    Ik heb ook nooit gezegd dat het niet samengaat.

    Je zult even op een waterfall manier je kritische massa aan data moeten verzamelen. Daarna je concept uittekenen. Wanneer dit conceptueel model is getest kan je wel op een Agile achtige manier aan de slag.

    Vanaf dag één met Agile beginnen gaat niet. Enfin, dat gaat wel, maar dan heb je een website die niet op maat is van je gebruikers, hun taken en hun omgeving. Zoals de meeste websites dus. *grijns*

    Nogmaals, stel je eens voor dat de architect zijn ontwerp begint te tekenen wanneer de metsers al muurtjes aan het zetten zijn…

    Hoe zou DAT huis eruit zien denk je? :)

  11. @edwin, eens. De kunst is wel om vooraf zo min mogelijk te bepalen.

  12. Pieter, kan alleen maar beamen dat het mij in positieve zin enorm heeft verrast hoe succesvol deze methode is. Het leuke vind ik persoonlijk dat je door deze methode iedereen in het project zijn eigen verantwoordelijkheid geeft. Zowel opdrachtgever als bureau.

  13. Hi Martin,
    yes, het was super om samen te werken aan http://www.micazu.nl en de aanverwante websites.
    Groeten!
    Pieter

  14. Door je klanten te betrekken in het proces, worden ze enthousiaster over het project.Ook zijn ze tevredener over de dienstverlening.

    groetjes,
    Ron

  15. @ Ron: Als je je eigen site een keer noemt is dat prima, maar als je het vaker gaat doen dan halen we dat toch maar even weg. Voor promotie mag je andere wegen gebruiken.

  16. Hi all,
    voor meer info, zie mijn Emerce Eday 2010 presentatie (Engelse versie met notes). Deze is online op http://slidesha.re/cW8Z5Q
    Groeten!
    Pieter

  17. Zijn jullie allemaal van mening dat je Scrum groepen in een ruimte moeten zitten? Hoe staan jullie tegenover scrum groepen die vanuit hun eigen ruimte zitten en via videoconferentie elkaar kunnen spreken?

  18. Hi Priscilla,
    eigenlijk wel. Scrum is erop gebaseerd om de communicatiebandbreedte tussen teamleden te maximaliseren. Geen aannames doen, meteen vragen. Elkaars body language aflezen en vragen waarom er twijfel is. Het lijkt me dat videoconferencing dat niet kan bieden, zelfs niet bij een permanente open lijn. Maar: testen is weten. En er zijn mensen die mogelijkheden zien:
    http://www.scrumalliance.org/articles/165-scrum-success-in-a-distributed-team-environment
    Succes!
    Pieter

  19. He Pieter!

    Echt bedankt voor jouw reactie! Ik laat het weten of het is gelukt :)

    Priscilla

  20. Goede site micazu, beetje langzaam alleen. Ben benieuwd hoeveel jullie aan offline marketing hebben uitgegeven (heb redelijk wat spotjes/abri’s voorbij zien komen) en of het nog zin heeft tegenwoordig.

    Goed verhaal verder en is zeker een manier om een website binnen gestelde termijn en verwachtingen op te leveren. Echter, wanneer is een website “klaar”… Nooit!

    Zolang het web (en daarnaast dirigent Google) verandert, dienen sites ook te veranderen, continu proces. Verder is input van bezoekers, zoals van Kranenburg in zijn presentaties meldt, überbelangrijk. The proof of the pudding is the eating.

  21. @Huurda. Bedankt voor je reactie en leuk dat je de website van Micazu goed vindt. Hebben we ook met veel plezier hard aan gewerkt.

    Snelheid hebben we nog recent laten onderzoeken door een echte specialist (Aaron Peters) en we zijn nu nog aan het finetunen. Ik moet zeggen dat de site nu goed gaat qua performance. Maar dank voor de tip, wellicht was het gisteren druk. Ga er meteen induiken, we gebruiken hier onder meer de tool Pingdom voor.

    Wat de marketingcampagne betreft heeft de offline campagne wel degelijk effect gehad. Een offline campagne is natuurlijk anders dan Adwords inkopen maar we zien dat het op de lange termijn effect heeft. Ik merk dat veel mensen er nog lang over doorpraten en het gezien hebben. Nu wordt het zaak om die top of mind positie te houden. Social Media wordt hierin ook belangrijk nu, waarbij we alle Nederlandse particuliere eigenaren ook inzetten om met zijn allen de marketing te doen. Zo staat nu op elke presentatie van een vakantiehuis een facebook en tweetthis icoon. En als alle 4.000 eigenaren nu hier actief mee omgaan….. dan creëren we zo ook een enorme exposure.

    De scrum methode is super geweest in de initiële opzet van de website. De website staat nu en daarmee is de scrum ook afgelopen. Nu zijn we dagelijks bezig hoe we van de bezoekers nog meer boekers kunnen maken. We kijken dagelijks in Analytics en andere tools en passen ook bijna wekelijks de site aan om te kijken wat het effect is op conversie. Ben het helemaal met je eens dat een website nooit af is en dat je in kleine releases continue aan het verbeteren bent. Daarbij testen we ook veel met gebruikers van de website, hier blijf je van leren.

    Nogmaals dank voor je leuke reactie en ik hoop dat er ook een leuk vakantiehuis van een Nederlandse eigenaar op Micazu staat. We hebben er een kleine 4.000 in 50 landen. Het mooie vind ik dat de community van eigenaren het aanbod bepaald, nooit gedacht vooraf dat we 130 huizen zouden aanbieden in Curacao.

    Nou mocht je nog vragen hebben hoe we de optimalisatie oppakken mag je me ook altijd bellen of mailen. De contactgegevens vind je op de site.

  22. @huurda @martin, met steeds meer klanten werken wij aan dat continue proces. Daarvoor is scrum overigens prima geschikt! Er zijn veel mensen die “Sprints” bijvoorbeeld “Iterations” noemen. Op die manier werk je in een vaste cyclus van bijvoorbeeld drie of vier weken aan het live product, met aan het eind van elke “iteration” een nieuwe release met conversieverbeteringen, features, fixes en andere updates.
    Wat ons bij Micazu vooral veel opleverde, is wat ik het Asterix&Obelix effect ben gaan noemen: bureau en opdrachtgever hebben elk hun eigen kracht, maar de combinatie geeft succes!

  23. Tsja feedback is natuurlijk de belangrijkste input.

    80% van onze bezoekers is nu nog steeds nieuw, dus weinig terugkerend. Wellicht tekenend voor de “vluchtige internetklant van tegenwoordig”. Ben bezig met een feedback-opzet, ben benieuwd. Iemand nog feedback/ervaring hiermee?

  24. Ik heb bij een klant de online interactie met klanten gekoppeld aan een Agile ontwikkelproces en dan wordt het echt interessant. Klanten bepalen de volgorde van de backlog! Weg met de overheadkosten en meteen ontwikkelen waar de klant bij zit. Werkt als een trein! Elke twee weken kunnen we met klanten gaan testen!

  25. Ik heb bij een klant de online interactie met klanten gekoppeld aan een Agile ontwikkelproces en dan wordt het echt interessant. Klanten bepalen de volgorde van de backlog! Weg met de overheadkosten en meteen ontwikkelen waar de klant bij zit. Werkt als een trein! Elke twee weken kunnen we met klanten gaan testen! En de ontwikkelaars hebben er ook meer lol in.

Plaats een reactie

Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn met een * aangegeven.

Verschijnt je reactie niet, dan is deze mogelijk in de spam terechtgekomen. Mail ons dan even!