UX in een Agile omgeving (deel 3)

Dat het bij consumentenproducten loont om de gebruikservaring voorop te stellen laat het succes van verschillende bedrijven zien. Bij B2B organisaties zien we echter dat dit nog in opkomst is: slechts een enkeling gebruikt User Experience (UX) als leidraad voor hun productontwikkeling. In deze serie van blogposts leggen onze consultants uit wat UX Design kan bieden en hoe. In dit derde deel licht UX consultant en SCRUM Master Frank toe hoe UX kan werken binnen een Agile / SCRUM omgeving.

In de vorige blogpost lichtte ik toe welke activiteiten er zoal zijn vanuit User Experience Design (UX), ingedeeld in zes fases: Strategy & Vision, Research, Interaction Design, Visual Design, Prototyping en Implementation. In een proces gebaseerd op de ‘waterval’ methode of het V-model zijn deze activiteiten eenvoudig in te passen. Een Agile ingericht proces (waarbij  SCRUM het meestgebruikte framework is) kan zorgen voor een hogere kwaliteit, betere afstemming op de markt en snellere resultaten. Ondanks dat het SCRUM proces er anders uit ziet, kunnen de UX activiteiten daar heel goed mee samengaan. In deze blogpost licht ik toe hoe dat gedaan kan worden.

In SCRUM werkt het development team in Sprints. Dit zijn periodes van 2-4 weken waarin een bruikbare toevoeging aan het product wordt gemaakt. In een Sprint wordt gewerkt aan User Stories: afgebakende, zo klein mogelijke stukjes functionaliteit, die gerealiseerd worden. Deze zijn vaak in een specifiek format, bijvoorbeeld: “Als medewerker wil ik gemaakte onkosten kunnen declareren, zodat ik het voorgeschoten geld terug kan krijgen”. Het maken van een User Story gebeurt buiten een Sprint. De Product Owner (bijvoorbeeld van een bedrijfsportal) signaleert dat er een behoefte is aan het indienen van declaraties. Vanuit de vragen genoemd bij Strategy & Vision bedenkt de Product Owner wie dit zou gebruiken en in welke context, en welke waarde vertegenwoordigd wordt: hoeveel declaraties worden er ingediend per jaar en hoeveel tijd kost dit nu? Is de voorkeur om dit met de computer te doen of met een smartphone?

Voor een aantal van bovengenoemde vragen is wellicht Research nodig. Ook onderzoek naar al bestaande oplossingen zou hieronder kunnen vallen: wellicht is het mogelijk deze functionaliteit als geheel in te kopen in plaats van het zelf te maken. Ervan uitgaande dat deze declaratie-functionaliteit gemaakt moet gaan worden, is het nodig om dit verder te specificeren: wat gaat er opgeleverd worden? Wanneer foto’s van bonnetjes toegevoegd moeten kunnen worden en een leidinggevende akkoord moet kunnen geven, is het meer werk om te maken. Na meer onderzoek is het goed mogelijk dat er nu meerdere User Stories zijn die ieder een deel functionaliteit toevoegen. In principe gebeurt dit buiten de Sprint en door de Product Owner. Een deel van het werk kan ook als opdracht gegeven worden aan het Development team. In dat geval wordt het meestal opgenomen in de Sprint als een Research Story.

 

Tijdens de Sprint zijn er twee mogelijkheden qua aanpak. In de opvatting van SCRUM (hierboven weergegeven) zou een User Story in een sprint opgepakt worden. Het multidisciplinaire team gaat ermee aan de slag, waarbij tijdens die Sprint het Interaction Design (welke stappen zijn er, met welke invoervelden en knoppen etc.) en het Visual Design (hoe gaat dit er precies uitzien) van dat stukje functionaliteit plaatsvinden. In zo’n geval wordt Prototyping vaak overgeslagen (de focus ligt immers op daadwerkelijk gerealiseerde functionaliteit) en vindt Implementation meteen plaats. Het voordeel van deze aanpak is dat de functionaliteit zo snel mogelijk beschikbaar is om op te leveren.

Deze aanpak heeft ook een mogelijk nadeel: het gehele ontwikkelteam heeft al significante tijd besteed aan het realiseren van die functionaliteit. Stel nu dat één van de aannames tijdens de Strategy & Vision fase niet juist was? Het zou bijvoorbeeld kunnen dat het oude papieren proces in de praktijk sneller werkte dan het nieuwe proces met inloggen en naar de juiste pagina navigeren. In dit geval kom je daar pas achter na het maken van de benodigde functionaliteiten en was het eigenlijk een verspilling. Eén van de Agile principes is juist “Simplicity–the art of maximizing the amount of work not done–is essential”. Een ander nadeel is dat er afhankelijkheid optreedt: de UX Designer (of Interaction Designer) moet aan het begin van de Sprint voor meestal meerdere Stories gaan ontwerpen zodat de software developers er mee aan de slag kunnen. Er is dan te weinig tijd beschikbaar om het ontwerp te evalueren met gebruikers voor het gemaakt gaat worden. SCRUM geeft aan dat er geen sub-teams binnen het multidisciplinaire Development Team mogen zijn, maar geeft verder geen oplossingsrichting.

Er is ook een andere aanpak. Deze komt in de praktijk voor, maar is niet wat het SCRUM framework voorschrijft. Deze aanpak is om één of meerdere fases uit te voeren in de sprint voorafgaand aan de sprint waarin de functionaliteit daadwerkelijk geïmplementeerd moet worden. In zo’n geval loopt het UX werk één sprint voor op de Software Development sprint. Helemaal als een onzekere factor van tevoren bekend is, kan er validatie plaatsvinden voordat het hele team aan de slag gaat met het maken. Zo is het bijvoorbeeld relatief eenvoudig om een prototype te maken uit een digitaal ontwerp. Met het prototype kan een inschatting gemaakt worden hoeveel tijd nodig is voor het navigeren en invullen van de declaratie. Een bijkomend voordeel is dat dit meer duidelijkheid geeft voor de developers (en dus voorspelbaarheid en een consistentere workload): bij aanvang van de development sprint is namelijk veel concreter vastgelegd wat gemaakt moet worden. Het risico is dat er tijd verloren gaat aan het maken van specificaties. Mijn ervaring is dat tijdsverlies nauwelijks optreedt zolang de specificaties bestaan uit het uitwerken van de interface in design software en enkele korte bulletpoints bij de user story. Een nadeel is dat onderling contact niet meer verplicht is. Mijn ervaring is dat dit nog steeds ruim voldoende kan plaatsvinden, zowel tijdens de Sprint als bijvoorbeeld bij de Sprint Planning.

In de praktijk is het afhankelijk van veel factoren wat op dat moment het ideale proces is. Hoe lang is de ontwikkeling van het product al bezig? Hoe belangrijk is het om als eerste op de markt te zijn? Hoeveel aannames en onzekerheden zijn er nog in de visie voor het product? Is communicatie binnen het development team op dit moment een lastig punt? En hoeveel ervaring is er al met SCRUM? In alle gevallen is het mogelijk om User Experience Design in te zetten om de gebruiker een betere beleving te bieden, de waarde voor uw bedrijf te maximaliseren en risico’s te verkleinen.

Bent u benieuwd hoe UX Design en/of SCRUM in uw bedrijfs- of ontwikkelproces zou passen? Neem dan contact met ons op, bijvoorbeeld via het formulier hier rechts.

Frank

UX Design Consultant

UX is geen extraatje (deel 1)

Dat het bij consumentenproducten loont om de gebruikservaring voorop te stellen laat het succes van bedrijven zoals AirBnB en Apple [...]

UX in de praktijk (deel 2)

Dat het bij consumentenproducten loont om de gebruikservaring voorop te stellen laat het succes van verschillende bedrijven zien. Bij B2B organisaties [...]

Bij twijfel: de UX scan (deel 5 – slot)

Dat het bij consumentenproducten loont om de gebruikservaring voorop te stellen laat het succes van verschillende bedrijven zien. Bij B2B organisaties [...]

neem contact op

*verplichte velden