Agile Design & Scrum: de mythes, de FAQ

Scrum biedt leverzekerheid, snelheid én kwaliteit. Maar Scrum wordt ook omringd door hardnekkige mythes. Is elk project geschikt? Hoe zit het met creativiteit, user centered design en echt parallel ontwerpen en ontwikkelen? En hoe moet je beginnen aan Scrum?

Zet Scrum naar je hand

Nu ik op steeds meer plekken onze ervaringen met Scrum deel, loop ik vaak tegen dezelfde vragen en mythes aan. En dat is niet verwonderlijk: als je nog geen Scrumervaring hebt, is het vanwege de grondige verschillen tussen Scrum en waterval echt moeilijk om je voor te stellen hoe het werkt. Scrum vraagt om het loslaten van veel zekerheden die bij waterval vanzelfsprekend zijn: vastgelegde scope, goedgekeurde interactieontwerpen, dichtgetimmerde planningen.

Ik krijg ook vragen over de rekbaarheid van Scrum. Ik ben niet een dogmatisch Scrummer: Scrum is er voor ons, niet andersom. Zet het naar je hand. Probeer het, kneed het. Gebruik eventueel zelfs alleen onderdelen. Alles is mogelijk, zolang je de spelregels maar van tevoren vaststelt. Als je een methode als deze vrij interpreteert, zijn antwoorden al snel controversieel, dus ik hoor graag jullie mening.

Tip: Ben je nieuw met Scrum? Check even mijn eerdere artikel over Scrum.

1) Is Scrum voor elk project geschikt?

Nee. Hoewel Scrum een heel flexibele methode is die voor veel situaties geschikt is, zijn er ook omstandigheden waarbij het niet zal werken:

• Bij zeer democratische opdrachtgevers, of bij opdrachtgevers met onduidelijke beslisstructuren, bestaat de kans dat de product-owner onvoldoende mandaat krijgt. Als voor elk detail overlegd moet worden met het achterland, gaat de snelheid uit de sprint. Als de meeste echte beslissingen uitgesteld moeten worden tot ‘presentatiemomenten’ tijdens de sprint-demo’s, dan maak je te veel inbreuk op het beginsel dat een sprint resulteert in een gereed product. Dat haalt de noodzakelijke spanning uit een sprint dat het echt helemaal ‘af’ moet zijn.
• Als de cultuur van opdrachtgever of leverancier erg formeel is en de teamleden zijn gehecht aan uitgebreide documentatie of ‘Def’ opleveringen tussen disciplines, dan gaat dat ten koste van het parallelle karakter van sprints. Werken op halffabrikaten, aannames en vermoedens is wat Scrum zo effectief maakt.
• Als de grootte van de inspanningen van de verschillende betrokken disciplines heel erg verschilt, is het moeilijk om een team te blijven. Als een project bijvoorbeeld maar een beetje ontwerp vergt, nauwelijks client sided techniek bevat, maar juist enorm veel server sided techniek, dan komt er een punt waarop het niet meer efficiënt is om een breed scrumteam in leven te houden.

In dit soort gevallen hoef je niet meteen heel Scrum af te schrijven:

• Je zou kunnen besluiten om de teamsamenstelling per sprint te wijzigen. Onze ervaringen hiermee zijn echter niet zo positief, omdat mensen mentaal echt ‘uitchecken’ als ze bij een sprint afwezig zijn geweest. Het is dan lastig om na instappen weer helemaal committed te worden.
• Je zou dan kunnen besluiten om alleen de voortgangsbewaking op Scrumwijze te doen met behulp van een Scrumboard, dit doen we voor één van onze SNS Reaal projecten (zie de foto hierboven). Het heet wat mij betreft dan geen Scrum meer, maar hey, het werkt.

2) Is Scrum alleen voor grote projecten geschikt?

Nee. Het is wel zo, dat een Scrumteam tijd nodig heeft om op elkaar ingespeeld te raken. Daardoor moet een Scrumproject niet te kort zijn.

De grootte van een Scrumproject laat zich uitdrukken in aantal sprints, sprintlengte, aantal sprintdagen per week en het aantal teamleden. Uit onze ervaring blijkt dat Scrum werkt vanaf 3 sprints van 2 weken, 2 à 3 dagen per week, met 3 teamleden. Dus vanaf circa 25 mandagen.

3) Is er binnen Scrum ruimte voor creativiteit?

Ja! Maar die komt er niet vanzelf. Ontwerpen is een kwestie van inspiratie en transpiratie, ofwel divergeren en convergeren (eerst breed gaan, dan kiezen en uitwerken). Dat is binnen Scrum niet anders. Divergeren begint al tijdens sprint 0, als verschillende proposities en site-concepten verzonnen worden en er gebrainstormd wordt op verschillende functionaliteiten. De backlog wordt vervolgens gevuld met de keuzes uit die sessies. Bij Micazu dwongen we ons antwoord te geven op de vraag: wat wordt uniek aan deze site? Een vuistregel: een goede sprint 0 bevat evenveel sprintdagen als het project sprints bevat.

Ook binnen sprints kan het team besluiten om ruimte te maken voor divergentie. Zelfs last-minute ideeën kunnen ingepast worden door te kijken naar de resterende tijd en werkvoorraad en eventueel nieuwe prioriteiten te stellen. Vanwege het grotere projectoverzicht is een dergelijke keuze in Scrum zelfs gemakkelijker te maken dan in waterval.

Herinner je je de Definition of Done van het Allerhande project (afbeelding)? Hierin staat een mooie eis die leidt tot creativiteit.

4) Is Scrum te combineren met User Centered Design?

Jazeker! In Scrum kan je tijd en ruimte maken voor alles wat je belangrijk vindt. Dus ook voor ‘UCD’!

• Tijdens sprint 0 kunnen user experience designers alle research doen die nodig is en waar budget voor is. Bijvoorbeeld field studies doen, interviews houden en de findings vastleggen in persona’s.
• Tijdens de sprints kan het maken van een paper prototype en het met users testen daarvan tot de taken behoren. Post-it schrijven, taak uitvoeren, klaar.
• Volledige usability tests kunnen uitgevoerd worden tussen sprints, op basis van het sprintresultaat, of eventueel parallel aan de daaropvolgende sprint.
• Een laatste mogelijkheid is om de sprint demo als usability test op te zetten. Verschillende stakeholders kunnen het product dan zelf als user ondergaan. We hebben dit voor Albert Heijn gedaan; een betere manier van demo-en is er niet!

5) Hoe kan je nu iets programmeren dat je tegelijkertijd aan het ontwerpen bent?

Ah, de ‘million dollar question’. In één sprint ontwerpen én bouwen, dat zijn wij respectvol ‘Überscrum’ gaan noemen. En met reden. We hebben dit inmiddels gedeeltelijk opgelost, onder andere in projecten voor Nationale Nederlanden en Welland College. Ons inzicht is nu zo:

• Het is voor teamleden uitdagend, maar niet onmogelijk. Abstract denken en de mogelijkheid om daar informeel over te communiceren, zijn essentieel.
• De product backlog moet redelijk concreet zijn. De user stories nog concreter. Er moet een heel helder idee zijn over de ruwe functionaliteit, zoals bijvoorbeeld flow.
• Ontwerpers moeten zo min mogelijk aannames doen en zorgen dat hun ontwerpen technisch fundament hebben. Aansluiten op datamodellen, standaardfunctionaliteit en dergelijke.
• Ontwikkelaars moeten eveneens zo min mogelijk aannames doen, maar vaak het overleg zoeken met ontwerpers, en zo de agenda van ontwerpers mede bepalen.
• Het is mogelijk om te proberen design en development 100% te integreren, en bij moeilijkheden over te stappen op het split sprint model, waarbij de ontwikkelaars één sprint achterlopen. Nog steeds zitten beide disciplines in één ruimte om samen te werken aan elkaars deliverables. In sommige gevallen hebben we zelfs twee Scrum boards in één ruimte opgehangen.

6) Hoe belangrijk is documentatie nog in Scrum?

‘Eliminate waste’ is een belangrijk uitgangspunt in Scrum. Documentatie die in waterval gebruikt wordt voor informatieoverdracht tussen teamleden kan vaak geëlimineerd worden. Maar niet elke documentatie is waste, ook al vinden wij ontwerpers dat nog wel eens jammer.

Voorbeelden van documentatie die in Scrum minder belangrijk is, met tussen haakjes hun Scrum-tegenhangers:

• Programma van eisen (user stories, tasks!)
• Uitonderhandelde business rules (product owner ter plaatse!)
• Formele wireframes met toelichting (schets & overleg!)
• Uitgebreide style guide voor ontwikkelaars (moduleset geprint aan de muur!)

Voorbeelden van documentatie die ook in Scrum nodig blijven:

• Strategische keuzes, zoals merk- en productpersoonlijkheid, propositie, positionering
• User insight, zoals persona’s
• Redactiegids voor na livegang
• Beknopte huisstijlmanual voor designstudio bij klant
• Documentatie van belangrijke technische keuzes, voor het nageslacht

7) Mag de klant op elk moment over je schouder meekijken? Brrr!

Nee. Dat is gelukkig een mythe. Scrum leunt er in grote mate op dat teamleden met elkaar kunnen meekijken, en gemakkelijk met elkaar kunnen overleggen over de grote lijn, of juist over de details die het echt af maken. Maar Scrum zegt niet dat dat geen grenzen kent. Integendeel: als ontwerper of ontwikkelaar heb je regelmatig focus en rust nodig, en het is helemaal geen schande om aan te geven dat je even niet gestoord wil worden.

8) Kan je scrummen op afstand?

Daar is niet iedereen het over eens. Wij doen het in ieder geval niet. Zoals ik eerder schreef: 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. Blokkades onmiddellijk wegwerken. Problemen en successen delen.

Het lijkt me dat videoconferencing in combinatie met een digitaal Scrum board dat niet kan bieden, zelfs niet bij een permanente open lijn. Maar: testen is weten. En er zijn mensen die mogelijkheden zien.

9) Kan iedereen zomaar beginnen met scrummen?

Ik moedig iedereen aan om het uit te proberen, maar niet onvoorbereid. Van de ene kant is Scrum een heel overzichtelijk proces. De basis laat zich gemakkelijk uitleggen, en je krijgt er meteen zin in. Maar van de andere kant: er zitten een aantal zakelijke, inhoudelijke en emotionele uitdagingen in, die niet voor de poes zijn. 4 belangrijke uitdagingen op een rij:

• De klant moet begrijpen dat hij/zij achter het stuur zit als product owner. De product owner bepaalt prioriteiten, maakt inhoudelijke beslissingen.
• Omgaan met flexibele scope vraagt communicatieve skills. Hoe kan je klanten ervan overtuigen dat het eindproduct de business goals en user needs gaat dienen, zonder 100% garantie af te geven op scope?
• Scrum is discipline. Een zelfsturend team word je niet zomaar. Alle teamleden moeten open, nieuwsgierig en sterk zijn. Elke discipline moet minstens door één senior bemand zijn.
• Scrum drijft op evaluatie en introspectie. Het is gemakkelijk om te soft te zijn tijdens de daily standup, of de retrospective ‘voor een keertje’ over te slaan. Het is voor sommigen moeilijk om zich eerlijk uit te spreken. Er zijn technieken die daarbij helpen, zoals het van je af schrijven van je observaties. Zie de foto van de quotemuur, hierboven.

Begin je met scrummen? Begin dan met een klein project, een klein team, en met een project dat inhoudelijk niet heel innovatief is, dus waarvan je de basic design-oplossingen en technieken al vaker hebt toegepast.

10) Oké, we beginnen eraan. Wie wordt de Scrum master?

De Scrum master is een duizendpoot. Een empatische leider. Iemand die kan schakelen op de verschillende niveau’s van samenwerking: relatieniveau, inhoud, het maken van afspraken, het wegwerken van impediments (blokkades).

De Scrum master beheerst de taal van de verschillende betrokken disciplines. Begrijpt waar bij elke discipline de complexiteit ligt. Waar snelheid geboden is, waar voorzichtigheid. Hij of zij signaleert kansen en beren, frictie en pret.

Bij beginnende Scrumteams is hij ook nog trainer en grossiert in Scrum do’s en don’ts. Zorg dat de Scrum master heel goed in de materie zit.

Schaap met 5 poten? Bij Fabrique zijn het meestal de senior UX designers die deze skills aan de dag leggen.

Wordt vervolgd…

Zoals ik de vorige keer al schreef: Scrum is ook voor ons nog volop in ontwikkeling. Met ieder project leren we weer bij. En hoe meer we leren over Scrum, hoe duidelijker het ons wordt dat scrummen in een merken-, design- en interactieomgeving nog volop in ontwikkeling is. Hou deze plaats in de gaten voor updates!

Eerdere publicaties over Scrum:

• Frankwatching: Een website ontwerpen met agile design en Scrum
• SlideShare: “Scrum: Fast, Furious, Effective” (incl. speaker notes)
• Meer leestips: zie onderaan deel 3 van mijn artikelserie.