In dit deel: wat heb je nodig om te scrummen? ‘Scrummen’ is een manier van agile (‘vlug en lenig’) werken. Een project wordt opgedeeld in korte ‘sprints’ waarin steeds samen met de klant wordt gewerkt aan een concreet resultaat.
Wij hebben inmiddels veel ervaring opgebouwd met Scrum en andere vormen van Agile ontwerpen. In drie artikelen wil ik graag onze ervaringen delen en de basics van Scrum uiteenzetten. Mijn advies aan ontwerpers: just do it!
Scrum: wat heb je nodig?
Hieronder zie je een overzicht van het scrumproces. De totale hoeveelheid werk (product backlog) wordt ingedeeld in een aantal sprints. In dit artikel beschrijf ik de belangrijkste onderdelen van Scrum.
Het Scrumproces (bron: Wikipedia)
Scrum room
Scrum drijft op ad hoc-communicatie tussen de teamleden. Het hele team zit daarom in één ruimte. Altijd. Zelfs één deur tussen twee teamleden decimeert de communicatiebandbreedte tussen die twee teamleden!
Onze ervaring
De Scrum room…
- … hoeft niet dedicated te zijn, dus er mogen niet-projectleden bij zitten. Maar een Agile Design project maakt veel lawaai, dus aan te raden is het niet.
- … moet veel muurruimte hebben. Eén van de belangrijkste pijlers van Scrum is: maak het fysiek. Werk op papier. Werk je op de computer? Haal alles eruit, hang alles op. Schrijf en corrigeer op de prints, zodat iedereen het ziet.
- … moet een ruime voorraad pennen, papier, post-its in alle kleuren en Scotch invisible tape bevatten.
- … moet echt VAN het team zijn. Maak het eigen. Ja, hang die poster van Jakob Nielsen maar op. Don’t be shy.
Soorten sprints
Scrum gebruikt een projectopdeling in ‘sprints’. Een sprint duurt tussen 2 en 4 weken, met 3 weken als duidelijk optimum. Fabrique onderscheidt deze sprints:
- Sprint 0 – De eerste sprint, die als ‘kwartiermakersfase’ zou kunnen worden gekenmerkt. Alle benodigde aanleveringen worden gedaan, research wordt gedaan, persona’s en scenario’s worden opgesteld, en er wordt een redelijk precieze omschrijving van de scope van het project gemaakt. In Scrum heet dat laatste de product backlog.
- Zelfgereguleerde sprints – Soms plannen we een aantal gelijkvormige sprints achter elkaar. Deze sprints zijn communicerende vaten. Het team bewaakt zijn eigen voortgang (velocity) per sprint, en stuurt -indien nodig- bij. Dit is de klassieke Scrum aanpak.
- Fixed deliverable sprints – Het kan handiger zijn om elke sprint een vast resultaat te geven, zoals een tak van een website, of verschillende middelen.
- Split sprints – in dit sprinttype zijn in één ruimte twee scrum teams tegelijkertijd bezig: een design team en een software-ontwikkelingsteam. Daily scrums zijn gezamenlijk, maar het ontwikkelaarsteam loopt één sprint achter, en bouwt wat het design team in de sprint ervoor heeft ontworpen. Ja, “au”. Maar het werkt.
- Sweep sprint – Soms is het handiger om het rework op sprintresultaten niet meteen te doen, maar al het rework te verzamelen in één laatste sprint.
Onze ervaring
- Fixed deliverable sprints is de meest laagdrempelige vorm om mee te beginnen. De fixed deliverables geven houvast en zorgen dat je je geen zorgen hoeft te maken over ingewikkelde zaken zoals velocity, of een grote homogene product backlog. De meeste van onze Agile projecten hebben fixed deliverable sprints.
- Agile projecten mèt ontwikkeling zijn bij ons split sprints. We hebben geprobeerd om ontwerp en ontwikkeling in één sprint te vatten, maar het is om allerlei redenen heel lastig, zo niet onmogelijk, om het efficiënt te laten gebeuren. Het doet pijn om zo’n waterval te moeten laten bestaan, maar uit rondvraag blijkt dat ook anderen met hetzelfde probleem zitten. Jammer!
- Toch streven we er nog steeds naar om split sprints te voorkomen. We proberen nog verschillende dingen uit, bijvoorbeeld eerder prototypen, of tweetallen maken van ontwerper en programmeur.
Product backlog
Elke sprint bestaat uit meerdere stories. Een story is een herkenbare, min of meer op zichzelf staande eenheid in de sprint. De verzameling van alle stories over het hele project, heet de product backlog. Hier zie je de product backlog van het Allerhande project voor Albert Heijn. De items worden ingedeeld in drie groepen, van grof idee naar ready for sprint. Terwijl de sprints vorderen, zorgt de product owner (de klant) er samen met de scrum master voor dat de product backlog gevuld blijft, en dat de stories snel genoeg concreet worden. Een story is ready for sprint als er genoeg input voor aanwezig is, en er een redelijk heldere inschatting gemaakt kan worden van de bijbehorende ontwerp- en ontwikkelinspanning.
TIP: Besteed met een deel van het agile team iedere dag 10 minuten om stories te concretiseren, en zo de volgende sprint voor te bereiden.
User stories
Een story is geredeneerd vanuit een user benefit, en ziet er bijvoorbeeld zo uit:
As a user I want to see all previous orders so that I can easily reorder.
Het is belangrijk dat je met echte verhalen werkt, omdat je dan veel duidelijker de user benefit voor ogen hebt. Door een story wordt duidelijk waarom we een bepaalde feature willen. Stories dwingen de klant ook om na te denken over waarom zij een bepaald feature willen.
Het is goed om duidelijke afspraken te maken wanneer een story klaar is, om tegenvallers aan het eind van de sprint te voorkomen. Hiernaast zie je een voorbeeld van een Definition of Done-blad.
Onze ervaring
In sommige situaties kunnen klassieke user stories uitlopen op semantische discussie en onenigheid tijdens de sprint over hoe die user need beantwoord moet worden. In die gevallen zien stories er daarom zo uit, bijvoorbeeld:
- Layout en navigatie
- Homepage
- Product detailpagina
- Ingewikkelde functionaliteit X
Tasks
Elke story wordt voor aanvang van de sprint opgesplitst in taken. Typische taken zijn:
- Wireframe schets
- Business rules opstellen
- Bellen met X
- Paper prototypen & testen
Zolang taken nog niet worden uitgevoerd, hebben ze geen eigenaar. De teamleden kiezen zelf welke taken ze gaan uitvoeren en voegen dan hun naam toe aan de taak.
Scrum board
Het Scrum board geeft het grote overzicht over alles wat nog gedaan moet worden, en al gedaan is. Hiernaast zie je een aantal voorbeelden van scrum boards. Een goed onderhouden scrum board is meer waard dan duizend Excel sheets!
De belangrijkste onderdelen van het scrum board zijn:
- Stories en tasks statusgebied – Welke tasks zijn nog in voorraad, welke zijn checked out (‘wordt op dit moment aan gewerkt’), en welke zijn done.
- Burndown chart - De tijdens de daily sprint besproken voortgang wordt aan de hand van de eerder gedane schattingen omgezet in een aantal dagen. Dit wordt van de werkvoorraad afgetrokken, en zo ontstaat een mooie rechte lijn naar beneden. ;-)
- Unplanned items – Gebruik je hoofd niet om te onthouden. Bedenk je iets dat “ook nog moet gebeuren” maar dat nog nergens is opgeschreven? Maak een post-it en plak hem bij de unplanned items. Scrum master of projectleider zorgen ervoor dat ze in de workflow een plek krijgen.
- Evaluatieblad – Scrummen is leren, ieder project, iedere dag opnieuw. Na iedere sprint, maar vaak ook al tijdens de daily scrum, kijken we wat er beter kan, wat al beter gaat, en wat helemaal top gaat.
Onze ervaring
Sommige scrummasters vinden het handig om een extra kolom in het statusgebied toe te voegen: keuring door product owner. De product owner, meestal de klant, ziet dan welke taken op zijn keuring wachten. Hij of zij kan ze bespreken en vervolgens naar rechts (done) of naar links (checked out) verplaatsen.
Wordt vervolgd…
Tot zover dit tweede deel. In het eerste deel heb ik uitgelegd wat het betekent om een website te ontwerpen met agile design en scrum. In het volgende en laatste deel ga ik in op de teamsamenstelling en overlegvormen die wij hanteren. Met onder andere mijn pleidooi om de product owner, oftewel de klant, volledig in het Scrum-team op te nemen. Tot dan!
Dylan 
Tim de Vrind 
Melis danny 
Agnieszka Biela 
Robert Didier 
Hi Pieter, erg mooi overzichtsartikel en ik herken vrijwel alles in ons eigen proces. Ook mooi hoe jullie e.e.a. zo visueel maken. Mijn ervaring is dat dit beter lukt met grafische ontwerpers dan met ontwikkelaars. Zit in de aard van het beestje denk ik.
T.a.v. de intensieve samenwerking tussen ontwerp en ontwikkeling maken wij actief gebruik van het werken in paren. Overigens is het succes hiervan wel afhankelijk van de omvang van de brokken werk. Maar als beiden erg afhankelijk van elkaar zijn, is onze ervaring dat een intensieve samenwerking tussen de twee het beste werkt. De ontwikkelaar geeft aan wat hij van de ontwerper nodig heeft en vice versa. Hierdoor zit niemand op elkaar te wachten.
Ik kijk uit naar het derde deel.
Hoi Pieter, erg leuk om zo compact jullie aanpak te lezen. Leerzaam, herkenbaar en goed om er weer eens even bij stil te staan.
Eén vraag: wat is “de poster van Jacob Nielsen”?
ai… als je niet weet wie JaKob Nielsen is moet je maar even snel gaan googlen en dit nooit meer hardop afvragen ;-)
Leuk overzicht trouwens. Ben benieuwd naar deel 3
@Hendrik, hé wiseguy, ik vraag naar de poster van Jacob, niet naar wie Jacob is.
@Harry Waarschijnlijk bedoelt de auteur van dit artikel ( om het gebruik van poster te vermijden ;)) het als grapje.. Zovan, om het gezellig te maken hang je een poster op van je favoriete usabilitydesigner ofzo.. Zoals vroeger je favo soapie boven je bed ging ;)
Mocht het wel gaan om een ‘poster met lessons from Jacob’ graag!
..hmm.. dan ben ik erin getuind.. en blijf ik mijn eigen poster van Seven of Nine ;-)
Speciaal voor Harry: http://www.useit.com/jakob/photos/
Hij zal mooi naast Seven of Nine staat denk ik.
@all, dank.
@peter, dank, goed om te horen dat het werken in paren voor jullie goed werkt! De functionaliteit waaraan gewerkt wordt moet merk ik wel goed modulair zijn om teveel dependencies tussen andere pairs te voorkomen…
@harry. Sorry… @Sendar heeft gelijk. Je moet eens googlen op “Jacob Nielsen poster” en kijken wat op 1 staat. En inderdaad, als Seven of Nine voor jou inspirerender werkt dan Jakob Nielsen, dan go. Maar check eerst die link van Henrik! ;-)
Interessant artikel. Ik heb het eerste deel ook gelezen.
Het scrum-principe is me al wel een tijdje bekend. Maar niet zo uitgebreid als jij het beschrijft.
Ik vraag me af of er niet enorm veel tijd gaat zitten in het ‘managen’ van jullie scrum processen? De user stories, het scrumboard; volgens mij zit er veel werk in het behouden van overzicht. Terwijl juist scrums toch fijn zijn omdat je een kleine specifieke taak doet. Focussen op de taak (task) en minder op het proces.
Wat betreft de scrum room, je geeft aan dat er veel lawaai is. Werkt dat dan fijn voor de werknemers? Kan me voorstellen dat er veel afleiding ontstaat, wat de productiviteit niet ten goede komt.
Bij 37signals werken ze ook met scrums, alleen dan vanaf aparte locaties. Minder overleggen, meer doen. Wij werken zelf ook op deze manier en moet zeggen dat we veel minder “ouwehoeren” over zaken die er niet toe doen. We komen sneller tot besluiten.
Laatste vraag: wat doen jullie als er taken aan het eind van een scrum periode nog niet voltooid zijn? Bij 37signals wordt het dan in de ijskast gezet:
“If something isn’t done in two weeks, then it goes back into the pot. Another team can choose to pick it up as a future iteration, or it may just die. This encourages team to make sure they have something launchable at the end of an iteration.” (http://37signals.com/svn/posts/2099-2010-the-year-of-the-products-a-new-way-of-working)
Dus hard werken, anders is je werk misschien wel voor niets geweest ;)
Nogmaals, leuk artikel! Ben benieuwd hoe groot jullie scrum-teams zijn. Maar dat lezen we vast in het volgende deel.
Ik ben zeer benieuwd wat in het laatste artikel zal staan. Ik begrijp ook waarom jullie het niet “gebruikelijk” vinden om een waterval methode in te zetten. Want als achteraf blijkt dat een onderdeel niet juist uitgevoerd is dan moeten alle andere stappen ook weer opnieuw doorlopen worden en dat kost dan weer veel tijd.
Goed, wat jullie toepassen is komt redelijk overeen hoe wij het bij Dezing ook doen. Alleen wij verdelen het in verschillende “increments” en het werken tussen een designer en een vormgever gebeurt ook in tweetallen. En dan volgens de “work breakdown structure”
Nu ga ik eerst nog even deel 1 van je verhaal lezen ;-)
Goran,
Ik ben meer te vinden voor een mengvorm. Initieel starten met een soort Waterfall, dit om de gegevens te verzamelen. Je kan, als je tenminste bekwaam bent, die gegevens niet verkeerd verzamelen. Wel kan het zijn dat je niet genoeg tijd had om alles mee te pakken. Of dat er te weinig budget is om alle requirements verzameltechnieken toe te passen.
Die gegevens verkrijg je o.a. uit het gebruikers profiel, contextuele taak observaties, het vastleggen van usability doelen, klassieke functionele analyse e.a. zaken.
Als die fase is afgerond dan kan je een conceptueel model ontwerpen, wat kan met potlood en papier, als er usability fouten aanwezig zijn (wat kan blijken na het testen), dan ga je terug naar de tekentafel, eventueel doe je dan bijkomend requirements onderzoek.
Wanneer het goed wordt bevonden dat kan je gaan itereren met Agile of gelijkaardige methodologieën zoveel je wil (ik doe dat trouwens ook zo). Dat is dus, prototype uittekenen, testen, coderen. Waarbij de usability mensen een weekje voorlopen op de programmeurs.
Een GUI is geen verzameling van kleine afzonderlijke scherm elementen. Er moet een algemeen overzicht zijn en een visie achter staan die o.a. de consistentie kan waarborgen. Die bewaak je met dat conceptueel model (dat relatief snel en goedkoop ontworpen wordt) en gebaseerd is op een adequate voorstudie.
Er wordt dikwijls vrij snel met gedetailleerd ontwerpen en zelfs coderen begonnen, zonder dat die adequate voorstudie achter de rug is. EN dat is het probleem, als er dan fouten opduiken dan kan je heel kostbare ontwerp en codeer tijd of wel vernietigen, of wel maar laten staan (omdat het al te veel geld heeft gekost). Beide kosten altijd veel geld.
Ik vind Agile goed, maar men moet er gewoon niet te snel mee beginnen. Ja, ik hoor wel eens af en toe succesverhalen over projecten waarbij men Agile vanaf dag 1 zit toe te passen. Maar wat is de oorzaak van dat succes? Een klein project? Bijzonder getalenteerde vakmensen met decennia lang tonnen ervaring? Of gewoon een lucky shot?
Fanatieke Agile adepten zijn gewoon soms wat blind voor de realiteit, ze lijden aan het American Dream syndroom. Het is niet omdat zij een paar keer succesvol ermee waren, dat iedereen dat kan en zal zijn. Ik ben een oude man, ik heb genoeg projecten gezien die wél de mist in gingen, puur door de verkeerde methodologie te gebruiken of deze verkeerd aan te wenden.
Usability engineering is geen speeltuin, het is een engineering proces. Er worden geen fysieke gebouwen ontworpen op een Agile achtige manier, toch niet vanaf dag 1. En dat is geen toeval.
Helder uitgelegd en erg leuk om de foto’s erbij te zien.
Ik kan me voorstellen dat diverse user stories met elkaar in verband staan. Het vinden van de juiste balans tussen diverse gebruikerswensen is vaak best lastig.
Wanneer je user stories in aparte sprints verwerkt, hoe vind je dan de juiste balans?
@Joep
- Het managen van scrum processen kost tijd, dat klopt. Net zoals bij waterval-projecten kost het ook meer tijd naarmate het team groter is. De scrum master doet een groot deel van deze coördinatie, maar deze last is ook enigszins verdeeld over de teamleden, die hun eigen taken in de gaten houden.
- Het lawaai in de scrum room wisselt van uur tot uur, afhankelijk van hoeveel dependencies of discussiepunten er zijn. Tot nu toe ben ik erg te spreken over het directe contact. Ik heb een hoge pet op voor 37signals, maar ik zie Basecamp projecten ook wel eens ontaarden in een duizelingwekkende hoeveelheid tickets, responses en notification mails… hoe lekker is het dan om gewoon in één ruimte te zitten :-)
- Als taken echt niet klaar zijn, komt dat meestal omdat bewust ruimte is gemaakt voor andere taken. De product owner bepaalt of ze belangrijk genoeg zijn voor een volgende sprint, of kunnen vervallen. Meestal zijn deze taken dan ook niet checked-out geweest, overigens. Er gaat vrijwel nooit werk verloren.
@Edwin
Het klinkt bijna alsof je Agile toch weer voorbehoudt voor prototyping en development. Mijn kernpunt is dat je vanaf de allereerste designactiviteiten Agile kunt werken. Om ruimte te maken voor (user-)research en requirements, hanteren we regelmatig een sprint 0, waarin een groot deel van het team al ingeschakeld wordt.
Het is de kunst om sprint 0 zo klein te houden dat er voldoende kader is zodat het team in dezelfde richting sprint, maar zodat er geen verstikkend en vertragend requirements pakket ligt. Dus wel de scope, maar niet de stramienen en de flows. Wel de stijlstudie, niet de definitieve layouts. Wel de tone-of-voice bepalen, niet de teksten schrijven. Wel de technische architectuur bepalen, maar geen concreet technisch ontwerp bij alle functionaliteit. En zo’n sprint 0 kan behoorlijk scrummig aanvoelen kan ik je vertellen :-)
Alle projecten kunnen de soep in draaien, ik heb dat bij Agile projecten gelukkig nog niet meegemaakt. De belangrijkste redenen hiervoor zijn dat de verantwoordelijkheden heel voelbaar zijn, en de monitoring heel persoonlijk en direct is.
En als Industrial Design Engineer durf ik deze stelling wel aan: Usability engineering is geen speeltuin, het is een wonderland :-)
@Floris
Het is inderdaad de kunst om de stories goed te clusteren. Ook kan je in de product backlog al een goede balans aanbrengen tussen verschillende stories. Daar maak je al de eerste moeilijke keuzes over welke functionaliteit je meeneemt.
Hallo Pieter,
Hoe zie je die tasks voor je. Tot nu toe ben ik gewend te werken met alleen de userstories die door het team worden ingeschat. Laat je die inschatting van userstories voor wat het is en pas je het alleen toe op de tasks of doe je beide. Het zou volgens mij namelijk niet werken om een userstorie bv 10 points te geven, hem op te splitsen en vervolgens iedere task weer een nieuwe inschatting te geven. Daarnaast krijg je dan volgens mij een ´straatje schoonvegen werksfeer´ ieder werkt zijn eigen tasks af en gaat zitten wachten op de rest.
Hi Erwin,
wat je schrijft klopt: inschatten doe je op story niveau. Waarbij je idealiter al wel een idee hebt van de achterliggende tasks. Merk verder op dat tasks geen eigenaar vooraf hebben, maar in de daily “geadopteerd” worden. Niemand hoeft zo te wachten :-)
Hallo Pieter,
Leuke artikels. Even een reactie op de laatste post(s):
Ik dacht ook dat je de User Stories op het post-it blaadje schrijft en deze vervolgens heen-en-weer schuift? Of staan op een User Story ook de Tasks omschreven?
Hoe werkt dat in de praktijk? Tasks op een User Story? Je moet het toch ergens vastleggen, wil je er een eigenaar aan toekennen, lijkt me… Of werken er geen 2 personen of meer aan een story?
Heb gewerkt met TeamPulse van Telerik, maar dat is toch nog wat beperkt. Misschien is een whiteboard toch praktischer!
Groet,
Daniel
Hi Daniël,
dank! Op deze foto (http://bit.ly/aO8lSb) zie je hoe het werkt. De stories worden op grotere blaadjes geschreven en hangen vast in de linkermarge. Per story heb je een aantal tasks, die schrijf je op postits, en hang je in de linkerkolom (Not Checked Out). Per task is een persoon eigenaar, dus meerdere personen kunnen tegelijk aan een story werken, afhankelijk van de dependencies binnen een story.
Oh en gebruik geen whiteboard als scrumboard, de post-its vallen er van af ;-)
Groeten,
Pieter
[...] Deel 2 – Wat heb je nodig? [...]
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