Agile usability, (hoe) werkt dat?

Fragment van een agile schema“Watervallen is niet meer van deze tijd. Gezamenlijk doen en snel resultaat wel. Agile zijn. Korte time to market en een ingeperkt risico.” Aldus Paul Manuel (partner bij Tam Tam) begin dit jaar, op zoek naar een nieuwe manier van werken. Agile is hot, al een tijdje. En tegelijk eng, want we houden met z’n allen zo van zekerheid. Zekerheid voor de opdrachtgever dat hij zijn product krijgt hoe hij het wil, op tijd en voor het afgesproken bedrag. En zekerheid voor de ICT-professional dat hij op tijd en binnen budget afkrijgt wat hij beloofd heeft te maken.

Agile (Engels voor snel, levendig) staat voor iteratief (kortcyclisch) werken, onderdeel voor onderdeel. Handig voor het programmeren, daar zijn velen het wel over eens. Maar op het eerste gezicht lijkt agile een bedreiging voor de user experience (UX) omdat het developers controle geeft over het proces en het niet genoeg tijd gunt voor user research, interactieontwerp en gebruikstesten. Toch horen we ook positieve ervaringen van UX-professionals. Hoe waarborg je user experience in een agile omgeving?

Wat is agile?

De meestgebruikte projectmethodieken volgen het watervalmodel. Hierbij doorloopt het project achtereenvolgens een vast aantal stappen, meestal analyse, ontwerp, bouw, test, acceptatie, implementatie en ten slotte overdracht naar beheer. Iedere stap wordt zo volledig mogelijk uitgevoerd, gedocumenteerd en geaccordeerd, zodat het voor iedereen na iedere stap duidelijk is wat het resultaat is/wordt. Bijkomend voordeel is dat projectscope, -planning en -kosten vroeg in het proces ingeschat kunnen worden en ‘fixed’ afgesproken kunnen worden.

“Waterfall method is best when you can’t afford to learn from your mistakes. You don’t design software for the Space Shuttle in an Agile manner.”

Alon Salant, engineer

De Agile filosofie gaat er juist vanuit dat projecten altijd last hebben van ‘voortschrijdend inzicht’. Dat de klant pas echt weet wat hij wil nadat hij een eerste werkende versie van zijn product heeft gezien. Dat bepaalde denkfouten of gaten in het ontwerp pas worden ontdekt tijdens het bouwen of – erger nog – daarna. Met als gevolg dat er een dure, vertragende iteratie nodig is om dat op te lossen, waar van beide kanten geen rekening is mee gehouden. Agile softwareontwikkeling omarmt juist iteraties en verandering van inzicht. In het Manifesto for Agile Software Development staan de volgende waarden:

  • Individuals and interactions over ‘processes and tools’
  • Working software over ‘comprehensive documentation’
  • Customer collaboration over ‘contract negotiation’
  • Responding to change over ‘following a plan’

Agile werken vertaalt zich o.a. in:

  • Het tegelijk inzetten van alle rollen bij een sprint, in één team. Bij de watervalmethode heeft iedere fase experts., die hun taak uitvoeren en het resultaat overdragen naar de experts voor de volgende fase,
  • Het werken aan één onderdeel tegelijkertijd in korte sprints (liever enkele weken dan enkele maanden),
  • Zeer frequente tussenopleveringen, dus vaak feedback van de klant, dus regelmatig wijzigingsverzoeken,
  • Zo snel mogelijk vertalen van ideeën naar werkende software. Dit is de belangrijkste voortgangsgraadmeter,
  • Zoveel mogelijk persoonlijk contact, zo min mogelijk documenteren,
  • Geen vroege zekerheid over hoe het eindresultaat wordt, hoeveel iteraties er nodig zijn en/of hoe hoog de projectkosten zullen zijn,
  • Nauwe samenwerking op dagelijkse basis tussen ontwikkelaars en belanghebbenden.

Waarom de vraag?

Een agile projectaanpak zou de nadelen van het watervalmodel moeten oplossen. Er zijn inmiddels voldoende voorbeelden van bedrijven die agile succesvol toepassen. Een van de bekendste is 37Signals (bekend van tools als Basecamp en Backpack), die er zelfs een boek getiteld “Getting Real” over hebben geschreven. Door de succesverhalen krijgt de agile filosofie steeds meer aanhangers. Waarom dan de vraag of agile en usability wel samen gaan?

“Agile methoden proberen usability barriëres in traditionele softwareontwikkeling weg te nemen, maar introduceren nieuwe bedreigingen voor de kwaliteit van de user experience. … Agile’s grootste bedreiging voor de kwaliteit van een systeem komt voort uit het feit dat het een door programmeurs voorgestelde aanpak is die vooral de implementatiekant van systeemontwikkeling adresseert. Dit heeft tot gevolg dat interaction design en usability vaak over het hoofd gezien wordt en dus meer als bijeffect van het programmeren ontstaan.”

Jakob Nielsen (Usability-coryfee)

Elementen van User Experience (Jesse James Garrett, 2003)De meeste user experience designers hanteren een watervalaanpak. Het bekendste voorbeeld hiervan is wellicht Jesse James Garrett’s “Elements of User Experience” model. Het proces begint vaak met het inventariseren van o.a. functionele eisen en wensen, gebruikersdoelen en huidig gebruik. Vervolgens bedenken we dan een concept, creëren – al dan niet met input van gebruikers – een informatiearchitectuur en interactieontwerp, testen op usability, en documenteren het geheel. Ten slotte zorgt het grafisch ontwerp voor het glazuur van de user experience.

Wat gebeurt er met dit proces als we user experience design agile gaan benaderen? Een korte SWOT-analyse:

Sterkten (Strengths)

In welke situaties komt agile goed tot zijn recht? (bron)

  • Bij projecten:
    • waarin doorontwikkeld wordt (bv. nieuwe features) aan een product (waarvan het concept dus al staat),
    • van start-ups met een duidelijke visie op hun product, features en doelen,
    • waarbij de ‘time to market’ kritiek is voor succes.
  • Bij teams:
    • die het volledige vertrouwen krijgen dat ze de doelen behalen, en die daarin optimaal gefaciliteerd worden,
    • die ervaren zijn, intensief kunnen samenwerken en actief kunnen participeren,
    • met UX-ontwerpers die zich comfortabel voelen bij constante iteratie,
    • met engineers/ontwikkelaars die ook gericht op de gebruiker (‘user-centered’) zijn en veel communiceren met ontwerpers.
  • Bij klanten:
    • die de wensen en behoeften van hun gebruikers kennen/begrijpen,
    • die dagelijks en face-to-face betrokken kunnen zijn en snel beslissingen kunnen nemen (maar ook van gedachten kunnen veranderen),
    • met heldere, vaste business doelen en visie.

Zwakten (Weaknesses)

Wanneer werkt het watervalmodel beter? (bron)

  • Bij projecten:
    • waarin intense, non-modulaire, branded user experiences gecreëerd worden,
    • met grote risico’s en/of complexiteit, die heel goed doordracht moeten worden,
    • waarbij het succes van het ontwerp afhankelijk is van de uitkomsten (en beslissingen) van research.
  • Bij teams:
    • op afstand, bv. outsourcing, of gewoon op verschillende locaties,
    • waarvan de leden niet allemaal tegelijkertijd aan hetzelfde kunnen werken.
  • Bij klanten:
    • die de wensen en behoeften van hun gebruikers niet kennen/begrijpen,
    • die niet dagelijks en face-to-face betrokken kunnen zijn en snel beslissingen kunnen nemen,
    • met veel belanghebbenden die documentatie nodig hebben als context voor besluitvorming,
    • die fixed price, fixed time èn fixed features willen.

Grafiek: Agile werkt bij wijzigende requirements en complexe technologie. Waterval werkt bij stabiele requirements en eenvoudige technologie. (bron: http://naarvoren.nl/artikel/agile/)

Kansen (Opportunities)

  • Het werken in iteraties biedt de mogelijkheid om veel regelmatiger feedback van gebruikers te krijgen. Je kunt het zien als continu verbeterproces.
  • Testen met werkende software is meestal te prefereren boven testen met beperkte prototypes.
  • De user experience designer blijft continu betrokken en kan de usability dus blijven bewaken. Bij watervalprojecten raakt hij vaak na de ontwerpfase op de achtergrond, omdat hij niet meer op het project is ingepland en inmiddels aan zijn volgende project werkt.
  • Door veel persoonlijk contact binnen het team wordt usability geen papieren tijger, maar onderwerp van gesprek. Bovendien bespaart het niet uitgebreid documenteren van alle functionaliteiten tijd.

Bedreigingen (Threats)

  • Websites zijn niet hetzelfde als webapplicaties. Agile is in principe gebaseerd op het ontwikkelen van applicaties, met grotendeels afgekaderde, op zichzelf staande functies. Bij veel gebruikersscenario’s voor websites speelt het vinden en verwerken van content een grote rol. Daarom zijn website-taken niet makkelijk te isoleren in specifieke functies.
  • Het opdelen van het product in kleinere, losse delen, die één voor één ontworpen en ontwikkeld worden, heeft verder als risico dat de gezamenlijke features geen coherente totaalbeleving opleveren.
  • Door het werken in korte iteraties van slechts enkele weken en dus heel strakke deadlines, is het risico groot dat als eerste beknibbeld wordt op usability (research en/of testing), uit angst dat daar geen tijd voor is.
  • Als de doelgroep moeilijk bereikbaar en/of beschikbaar is voor het projectteam voor gebruikstesten, maar je wilt wel in iedere iteratie toetsen op usability, dan kan dit een tijdrovende en kostbare activiteit worden.
  • Een nauwe samenwerking tussen ontwerper en ontwikkelaar is noodzakelijk. Bij waterval hebben ontwikkelaars nog een Functioneel Ontwerp als houvast voor het uitwerken van de user interface. Wat niet beschreven staat, wordt – met name door ontwikkelaars die zich niet ten volste betrokken voelen bij het succes – niet gemaakt of zo makkelijk mogelijk opgelost zonder overleg met de ontwerper. Hieruit volgt ook: Agile en outsourcing gaan niet samen.

Succesvol zijn in een agile omgeving

Jeff Patton (onafhankelijk consultant en agile coach) heeft de volgende aanbevelingen voor user experience designers om succesvol te zijn in een agile omgeving:

  • Neem de rol aan van business owner.
  • Onderzoek, modelleer en ontwerp vooraf, maar niet teveel.
  • Hak je ontwerpwerk in brokken. Voorkom hierbij dat ontwerptijd in het gedrang komt door ontwerpintensieve iteraties af te wisselen met ontwikkelintensieve iteraties.
  • Werk parallel aan de huidige development iteratie vooruit aan de volgende iteratie en evalueer/test de vorige iteratie.
  • Creëer een pool van gebruikers waar je continu gebruikersonderzoek mee kunt doen.
  • Organiseer continu gebruikersonderzoek in een eigen spoor, los van development.
  • Combineer meerdere doelen als je met gebruikers zit.
  • Test en optimaliseer de user interface iteratief.
  • Maak prototypes simpeler (‘low fidelity’) naarmate de samenwerking met ontwikkelaars intensiveert.
  • Gebruik prototypes / wireframes voor discussie in plaats van specificatie.
  • Word een ontwerpfacilitator.

In een volgend artikel ga ik uitgebreider op deze aanbevelingen in.

Zelf ervaring?

Zelf heb ik nog geen hands-on ervaring met agile UX design. Wie heeft er al wel ervaring mee? Klopt de SWOT-analyse? Nog tips?

8 gedachten over “Agile usability, (hoe) werkt dat?”

  1. Hoi Ferry,

    Interessante post.
    Heb al in meerdere projecten gezeten waar met ‘agile uitgangspunten’ werd gestart. Je SWOT klopt wat mij betreft erg goed.
    Mijn ervaring is dat tijdens het project de agility nogal eens afneemt. Onder druk is het verleidelijk om af te bakenen in vertrouwde watervalstappen. Agility vergt vooralsnog veel inspirerend vermogen en leiderschap.

    Ben benieuwd naar andere ervaringen.

    Groet, Bas Brand

  2. Heel mooi samengevat wat de voor- en nadelen van Agile werken zijn. Ik heb helaas nog te weinig ervaring met Agile om een goed oordeel te kunnen vellen, maar bedankt voor je artikel. Zeer verhelderend!

  3. Hoi Ferry,

    Je hebt me geïnspireerd: ik ga hier een afstudeerstage van maken bij Approach.

    Ik weet dat veel webbureaus in NL met de vraag worstelen hoe de voordelen van Agile kunnen worden gecombineerd met de wensen van user centered designers en opdrachtgevers.

    Mijn collega’s dragen agile een warm hart toe, vanuit disciplines als software en enterprise architectuur, BPM, en QA testing. Ik ben sceptisch over de meerwaarde van “strict agile”, maar heb nog geen eigen ervaring met Agile methoden. Tijd voor onderzoek met een afstudeerder, die het discussievuurtje hier intern ongetwijfeld lekker zal opstoken 😉

    Ik zie voor me dat een afstudeerder op dit onderwerp:
    – de do’s and don’ts op een rij zet op basis van desk research
    – een rondje maakt langs een aantal NL webbureaus om de praktijkervaringen met waterval en agile te wegen (interviewssessies, round table gesprekken)
    – waarbij de designer, ontwikkelaar, projectmanager en opdrachtgever aan het woord komen
    – de resultaten uitwerkt en komt tot een praktisch model waarmee webbureaus voordelen kunnen benutten en risico’s kunnen beperken, voor 4 genoemde doelgroepen.

    Uiteraard worden de uitkomsten van de afstudeerder beschikbaar gesteld, zoals goed gebruik op jouw blog (tnx!).

    Groet, Nils

  4. Hallo Nils,

    Leuk dat je dit zo gaat oppakken! Ben nu al benieuwd naar de uitkomst…

    Ik zal in de tussentijd zorgen voor nog wat desk research materiaal. 😉

  5. Ferry,

    Eerst en vooral: soms kom je al eens een blog of website tegen over usability die de moeite is. Deze is er zo ééntje. Hij krijgt dan ook een plaatsje op mijn site.

    Ik heb wel wat ervaring met Agile achtige modellen. In organisaties die héél zuiver zo werken, kan je niet op een ernstige manier aan usability doen. Tenzij het om zeer kleine projecten ging, was de usability niet op maat van de gebruiker, zijn taak en zijn omgeving.

    Het probleem ligt voor een stuk bij één van de Strengths van je SWOT analyse van een Agile benadering:

    “Klanten die de wensen en behoeften van hun gebruikers kennen en begrijpen.”

    Dat is in de praktijk een zeldzaam gegeven. Weinigen geven gewoon toe dat ze hun gebruikers niet kennen en begrijpen, de meeste zeggen dat ze dat wél doen, maar in mijn praktijk blijkt dat ze het zelden echt weten. Vooroordelen en misvattingen zijn eerder legio.

    Als je niet weet WIE de gebruiker is, WAT, HOE en WAAR hij zijn taken uitvoert dan kan je geen software (website of applicatie) afleveren op maat van die gebruiker.
    Dan is die software op maat van de programmeur, zijn omgeving en zijn interpretatie van de taken van de gebruiker. Wat je dan ook kan merken in pakweg 80% van de software in omloop.

    Slimme organisaties en bedrijven zien dat wel in en gaan Agile mengen met waterval.

    Zo’n mengvorm verenigt het beste van die 2 werelden. Ik ben zelf bezig met zo’n methodologie: http://usability-vlaanderen.blogspot.com/2009/04/het-fusion-usability-recept_10.html

    In het kort:
    Ik verzamel eerste een kritische massa aan gegevens over de gebruiker, zijn taak en omgeving, destilleer hieruit de usability doelen en hierna ga ik op een Agile achtige wijze te werk bij het ontwerpen van de feitelijke user interface.

    Belangrijk is dat de software architecten pas beginnen wanneer het conceptueel model is afgerond, de programmeurs starten pas na aflevering van een getest prototype. Wat uiteraard niet wil zeggen dat de usability mensen eerst ALLES moeten afronden nog voor de anderen aan de slag mogen.

    Daarna kunnen de software architecten en programmeurs zoveel ‘Agilen’ als ze zelf willen.

  6. Edwin, bedankt voor je uitgebreide reactie en natuurlijk de vermelding op je site!

    Je hebt gelijk dat veel organisaties hun doelgroep écht kennen en begrijpen en dat dit een risico is voor een agile aanpak. Ik denk wel dat er meerdere manieren zijn om hiermee om te gaan en dat de keuze tussen agile, waterval en een mengvorm van meer factoren afhankelijk zijn.

    Je kunt inderdaad meer user research vooraf doen, zoals je voorstelt. Je zou ook de doelgroep meer in het proces kunnen betrekken. In het opvolgartikel vermeld ik tips van Jeff Patton om op regelmatige tijdstippen een pool van gebruikers te betrekken bij user research en usability testing.

    In ieder geval ga ik je Fusion usability recept eens goed bestuderen.

  7. Ferry,

    Ik denk dat je bedoelde “NIET écht kennen” ipv “écht kennen”.

    Ik volg wel dat er meerdere manieren zijn om tot een doel te komen. Het hangt ook allemaal af van de aard van het project, de belangrijkheid, het protocol in het bedrijf of organisatie, het aantal gebruikers, de beschikbaarheid van de team (en andere) leden en last but not least: het budget.

    Ik volg ook niet altijd de ‘ideale’ weg: research -> conceptueel model maken -> testen -> basis prototype ontwerpen -> testen -> finale prototype ontwerpen -> testen -> source code laten schrijven.

    Deze weg is niet goedkoop, kost wat tijd en is niet voor elk type project nodig of mogelijk.

    Persoonlijk hou ik er wel niet van om te starten en wel te zien waar ik uitkom. In mijn nederige opinie is er altijd een kritische massa aan research nodig. Maar goed, ik ben niet echt een grote fan van XP achtige toestanden (wat niet wil zeggen dat er niets goed in dat concept zit).

    Ene Gilb heeft eens gezegd dat als een usability wijziging in de ontwerpfase $1 kost, deze $10 kost in de ontwikkelfase en zelfs $100 moet kosten na aflevering van het systeem. Ik heb al ondervonden dat het niet overdreven is.

    Voer je die kritische massa aan research niet uit, dan loop je het risico dat de programmeurs onnodige of verkeerde source code gaan schrijven. Het is duurder om functionaliteit te programmeren dan deze even uit te tekenen in een concept of een prototype.

    Er is ook een psychologische factor: het dumpen van een prototype (of een gedeelte ervan) wordt veel gemakkelijker aanvaard door het team. Source code dumpen, waar ze weken en zelfs maanden aan gewerkt hebben, is niet alleen een kostelijke affaire het zal veelal tot wrevel en fricties leiden binnen het team.

    Het komt ook de leesbaarheid van de code ten goede. Als je constant wijzigt en schrapt, door wijzigende functionaliteit en requirements, dan zit je code dikwijls vol hacks en workarounds, wat dan weer repercussies heeft voor het onderhoud later.

    Een ander gevaar is, dat ze het gewoon zo laten. Ook al weten ze dat het niet in orde is. Ze vinden het gewoon zonde om de investering te vernietigen en nieuwe code schrijven kost ook geld.

    Wat het Fusion Usability Recept betreft: zeker komen kijken en kritiek geven! 🙂

Geef een reactie