Filter
ChatGPT Een website ontwerpen met agile design en scrum (3): Teams en overleg
‘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. In dit laatste deel uit deze driedelige serie ga ik in op de teamsamenstelling en overlegvormen die zorgen voor een succesvol Agile project.
Scrum team
Een scrum-team is multidisciplinair, maar hoeft niet groot te zijn! Het grootste scrumteam waarmee we ooit gewerkt hebben was 12 man groot, inclusief ontwikkelaars, het kleinste scrumteam bestond uit 3 man.
Een scrum-team bij Fabrique bestaat doorgaans uit deze leden:
- Product owner – dit is doorgaans de klant. Eén of meerdere stake holders vanuit de klant kunnen eigen aandachtgebieden verzorgen, zoals design acceptatie, business rules, content, organisatie klaarstomen. Zie ook de notitie onder ‘onze ervaring’!
- Interactieontwerper – de interactieontwerper speelt de rol van architect, integrator, uitwerker, tekenaar.
- Visueel ontwerper – de visueel ontwerper voegt communicatie toe en onderhoudt nauwe banden met de klant over de karakteristieken van de content.
- Software ontwikkelaar / technisch architect – de software ontwikkelaar bekijkt samen met de ontwerpers de user stories en geeft in een vroeg stadium mogelijkheden en grenzen aan. Hij of zij implementeert het ontwerp en bespreekt design issues.
- Copywriter (short copy / editorial) – De copywriter heeft, naast z’n eigen deliverables, veel ad-hoc contact met het hele team om het product te voorzien van pakkende copy, heldere inleidingen et cetera.
Naast de vaste teamleden is er een aantal rollen in te vullen:
- Scrum master – de scrum master houdt het proces in de gaten. Moet over veel procescreativiteit beschikken en is een drijvende kracht. Hij/zij spreekt alle teamleden aan op hun verantwoordelijkheid. In sommige gevallen is hij of zij ook verantwoordelijk voor kwaliteitborging, als art director of interaction director. Eén van de teamleden neemt de rol van scrum master aan.
- Stake holder – Deze belanghebbenden kunnen op sleutelmomenten aanschuiven, input geven of ontwerpen bekijken. Een stake holder kan vanuit de klant aanschuiven, vanuit het bureau, of vanuit een andere partij, zoals een implementatiepartner. Voorbeelden van stake-holders:
- Specialisten op het gebied van marketing of middelenmix, SEO, Usability testing
- Kwaliteitbewaking in de vorm van een director, of tester
- Account manager van het bureau
- Projectleider – Hoe beter Agile loopt, hoe meer de projectleider op de achtergrond kan blijven. Hij of zij regelt capaciteit, faciliteiten, afspraken, en budgetmonitoring.
Onze ervaring: product owner
- Volgens de klassieke regels van de Scrum maakt de product owner geen deel uit van het Scrum team. In mijn ervaring is dat vaak juist wel een heel effectieve werkwijze. De klant heeft tenslotte eigen taken. Het Scrum proces helpt ook hem om voortgang te boeken. We slagen er meestal in om de klant in het team op te nemen.
- Aan de andere kant: de opdrachtgever altijd in de buurt is niet altijd een zegen. Sommige opdrachtgevers zitten je heel erg op de huid, zoomen enorm in op details waar ze graag uren over praten, of worden heel zenuwachtig van het ontwerpproces zelf, waarin soms 80% van het resultaat ontstaat in de laatste 20% van de tijd. In zulke gevallen is het beter om de opdrachtgever tweemaal per week een dagdeel langs te laten komen. Minder krachtig, maar nog steeds beter dan waterval.
- Als de klant geen product owner ter beschikking kan stellen dan kan het bureau er één aanwijzen. De rol is te vergelijken met die van een projectleider of accountmanager, hij of zij schippert dan tussen de interne en externe belangen en voorkeuren.
Onze ervaring: pro-actief team
- Een cruciaal punt is dat alle teamleden over hun eigen discipline heen moeten kunnen werken, anders zou een miniwaterval binnen een sprint kunnen ontstaan, of teveel dependencies, wat tot wachtende teamleden leidt. Gooi je pet in het midden. Loop naar het task-board, kijk wat je kunt doen.
- Voor het hele scrum-team geldt tenslotte dat het sociaal nogal onverschrokken moet zijn. Daarin schuilt misschien wel het moeilijkste van Scrum: het proces faciliteert het meten van voortgang, maar eist tegelijkertijd veel initiatief van alle teamleden. Met name de scrum master moet man en paard bij naam durven noemen, mensen op hun intenties en afgegeven schattingen wijzen en hen af en toe met kracht uit hun comfortzone kunnen trekken.
Overleg
Het sluitstuk in dit drieluik gaat over overleg. Zoals ik hierboven al schreef: tijdens elke sprint vindt er doorlopend overleg plaats. Toch is een aantal vaste typen overleg essentieel.
Overleg: Sprint planning meeting
Tijdens de sprint planning meeting worden alle stories van die sprint gesplitst in taken. Vervolgens worden alle stories door het team gezamenlijk ingeschat in een proces dat ook wel bekend staat als ‘planning poker’. De product owner (meestal de klant) is als eigenaar van de product backlog uiteraard aanwezig bij deze bijeenkomst en oppert eigen taken
Aan het eind van de sessie worden de stories gezamenlijk op prioriteit geordend en overgebracht naar het scrum board. De product owner heeft het laatste woord over de prioriteitstelling.
Onze ervaring: planning poker met de klant
Hoewel de scrummethode zegt dat de product owner niet deelneemt aan de planning poker, is het onze ervaring dat dit wel zin heeft. Als de product owner met sterk afwijkende schattingen komt, is het interessant het waarom daarvan te achterhalen. Heeft hij eerdere ervaringen? Meer kennis van het product? Verwacht hij dat juist dit onderdeel een spetterende RIA wordt?
Daily scrum
Een daily scrum wordt altijd staande gehouden, en duurt maximaal 20 minuten. De teamleden vertellen één voor één wat ze de voorgaande dag gedaan hebben, en ze bepalen in een tweede rondje welke taken ze op zich nemen voor de komende dag. Ook wordt besproken wat de dependencies zijn, de onderlinge afhankelijkheden. Inhoudelijke discussies worden gesignaleerd, maar voor later bewaard.
De daily scrum is voor de scrum master een belangrijk dagelijks meetmoment van voortgang en team-attitude.
Onze ervaring: tweede stand-up
Met name bij geïntegreerde development sprints kan het zinnig zijn om op een vast moment, later op de dag, een tweede stand-up te houden waarbij je in 10-15 minuten naar de laatste stand van het gebouwde product kijkt. Zo geef je iedereen gelegenheid om zijn feedback te geven op het product (het héle team moet achter hetgeen staan dat je oplevert) en kun je de laatste puntjes op de i spotten.
Overleg met de klant
De communicatie met de klant is in Agile Design radicaal anders. Hij of zij is in het scrum team aanwezig als product owner, doet volop mee aan discussies over het ontwerp en over het proces. Dit heeft als effect dat presenteren eigenlijk niet meer nodig is. De kennis van het wat en waarom van het ontwerp is gemeenschappelijk ontstaan.
De product owner vertegenwoordigt alle stakeholders aan klantzijde, wiens inzichten in het project meegenomen moeten worden. We verwachten wel van de product owner dat hij of zij uiteindelijk beslissingsbevoegd is.
Product demo
Aan het eind van elke sprint wordt het product gedemonstreerd. Omdat de klant tijdens de hele sprint aanwezig was, grijpen we de demo vaak aan om bijvoorbeeld een stuurgroep mee te nemen in de projectvoortgang. Eventuele opmerkingen worden meegenomen als story in de volgende sprint, of liever nog in de sprint daarna.
Onze ervaring: sprintresultaat
In de klassieke Agile/Scrum methode is het resultaat van een sprint altijd een werkend product of een deel daarvan. In onze Agile Design interpretatie kan het product van alles zijn, zolang het maar een herkenbaar en afgesproken deliverable is van het project:
- Een werkend product of een deel daarvan
- Een klikbaar prototype
- Een set ontwerpen en documentatie
Retrospective
Elke sprint wordt afgesloten met een retrospective. De retrospective werkt voor ons echt als een afsluiting van de sprint waarin we de gang van zaken in de vorige sprint evalueren, en waarin iedereen zijn hart kan luchten. Lessen worden opgeschreven en aan het scrum-board toegevoegd. Hierna zijn we als team weer helemaal klaar voor de volgende sprint.
Onze ervaring: retrospective
Uit planningsoverwegingen en de deadlinesfeer aan het eind van een sprint, komt het wel eens voor dat we de sprint planning meeting (de aftrap van een sprint) openen met een korte retrospective. Hoe begrijpelijk dit ook is, een retrospective doe je aan het eind van de betreffende sprint, niet aan het begin van de volgende. In onze ervaring wil je zo min mogelijk ‘staartjes’ van de vorige sprint in een nieuwe sprint: dat vertraagt en vertroebelt.
Scrum is not the silver bullet
Stel je voor dat je er zit: scrum room ingericht, zorgvuldig een team samengesteld, alle rollen benoemd (en vervolgens het interdisciplinaire onderstreept), drie kilo post-its klaar voor de strijd. Waar moet je dan nog op letten?
Juist dankzij de vergaderrondjes, post-its, bijhouden van de scrum room enzovoorts, kan er een gevaarlijk effect optreden, dat ik het “in-slaap-sus-effect” noem. Het ziet eruit dat je lekker bezig bent, de post-its verschuiven, de burndown chart gaat mooi naar beneden, maar ondertussen blijft er veel onzichtbaar werk liggen. Losse eindjes waar je je ogen liever voor sluit. Taken die net wat te snel naar “Klaar” zijn gegaan. De documentatie die net wat té bondig is opgesteld. Deze zaken zullen je in de volgende sprint opbreken. De juiste team-attitude en een scherpe scrummaster kunnen dit voorkomen.
Top tien aandachtspunten bij scrum
- Creëer een sprintsfeer. Een voortkabbelende sprint is…geen sprint.
- Wacht niet. Nooit. Loop naar het scrum board, pak een taak op. Beperk je daarbij niet tot de taken die bij “jouw” discipline horen.
- “Definitief” materiaal is niet altijd nodig. Werk met wat je hebt.
- Definieer “done” en stick to it.
- Let goed op de beslissingsbevoegdheid van de product owner. Is die te gering, dan werk je op drijfzand.
- Werk fysiek. Schets, print uit. Maak foto’s.
- Bespreek resultaat maar geef elkaar de ruimte. Wees daarbij niet bang om over een “andere” discipline te praten.
- Benoem fuck-ups. Neem geen blad voor de mond.
- Vrees niemands input. Haal criticasters juist binnen.
- Vier successen, groot en klein. 🙂
Galerij
Meer over Agile en Scrum
Over de auteur
