Documentatie Agile Scrum Tom Luuring 1576519
Inhoudsopgave Inleiding Hoofdvraag & Deelvragen Wat is Agile? Wat is Scrum en hoe werkt het? Hoe is Scrum anders t.o.v. traditionele PM methodes Hoe vervult de UX er zijn rol in een Scrum team? Antwoord op Hoofdvraag Bronnenlijst Bijlage A: interview 1 Bijlage B: interview 2 Bijlage C: Zelfreflectie 1 2 3 / 4 5 / 8 9 / 10 11 / 12 13 14 / 16 17 / 21 22 / 24 25
Inleiding Scrum; de meest populaire lightweight Agile project management methode van nu. Eigen interesse en het feit dat ik Scrum overal zag opduiken heeft mij ertoe gezet dat ik hier onderzoek naar wilde doen. Inzicht verzamelen op een populair en veelbesproken onderwerp waarbij de mede CMD er en UX er voor mijn gevoel erg veel aan zal hebben was in mijn ogen een win-win situatie. Van het zelf toepassen van Scrum-achtige methodieken om mijn leven van orde te voorzien tot het proberen toe te passen van Scrum in eigen design projecten. Na het aantal keren veranderen van mijn hoofdvraag en deelvragen was mijn focus gezet, met als gevolg een essay en dit stuk documentatie. 1
Hoofdvraag & Deelvragen Hoofdvraag Hoe is Scrum Agile van waarde in het werkproces van de CMD er en User Experience Designer anno nu? Deelvragen Wat is Agile? Wat is Scrum en hoe werkt Scrum? Hoe is Scrum anders t.o.v. traditionele project management methodes? Hoe vervult de User Experience Designer zijn rol in een Scrum team? 2
Wat is Agile? Agile is een gedachtegoed, een manier van denken die zijn oorsprong vindt in de software development. Dit gezegd te hebben; Scrum is een bepaalde methode die aansluit bij de Agile denkwijze. Zo zijn er bijvoorbeeld andere methodieken zoals XP, KanBan of Lean die onder het Agile straatje vallen. Aan de kern van Agile ligt innovatie en de mogelijkheid tot aanpassingen maken centraal. Agile Project Management is een iteratief proces waarbij er snel gereageerd kan worden op problemen of blokkades om vervolgens nieuwe astemmingen hierop te kunnen maken. De Agile mindset vraagt om zelforganiserende teams waarbij de interactie tussen de diverse rollen in het team duidelijk is. In een onderzoek van Forrester, waarbij een reeks organisaties werden ondervraagd, bleek in 2010 35% gebruik te maken van Agile. Drie jaar later werden dezelfde organisaties geconfronteerd met dezelfde vraagstelling. Zo bleek dat 74% was overgestapt naar Agile. Er bleek ook een sterke opeenstapeling aan redenen hierachter te zitten. Zo blijkt dat 86.9% van de Agile organisaties meer geld verdienen en dat Agile gebruikers voor meer omzet zorgen. Agile door de jaren heen Stukje bij beetje kwam men door de jaren heen erachter dat de implementatie van Agile niet alleen beperkt hoeft te zijn tot alleen software development. Vervolgens begon Agile te bloeien. Zo was Agile was geboren in de jaren 70, maar wist het zijn faam pas vast te klammen in de jaren 90. Een volgende mijlpaal was The Agile Manifesto, waarin de eerste kernbegrippen en waardes van Agile denken zijn omschreven. Na het bijeenkomen van zeventien beoefenaars van diverse project management methodieken werd dit manifesto op papier gezet. Deze groep mensen noemen zichzelf The Agile Alliance. Ze waren het op vele vlakken met elkaar oneens, echter wat in het manifesto staat omschreven zijn stuk voor stuk principes waar zij samen overeenstemmingen hebben getroffen. The Agile Alliance hecht waarde aan de volgende punten: Individuen en interacties tegenover processesen en tools Werkende software tegenover uitgebreide documentatie Samenwerking met de klant tegenover contract onderhandeling 3
Reageren op verandering tegenover het volgen van een plan in kleine opeenvolgende oplevering series en laat deze groeien aan de hand van feedback van de stakeholders. Zo zien zij waarde in de stukken tekst aan de rechter kant, maar hechten zij meer waarde aan de dikgedrukte stukken tekst. Daarbij staat het manifesto voor twaalf principes waarbij de volgende punten van belang zijn: een focus op de klant tevredenheid, frequente software oplevering, een nauwe samenwerking tussen zaken mensen en ontwikkelaars en het creëren van een bevoegd cultuur met gemotiveerde individuen. Wanneer je de principes en waardes van Agile in acht zou nemen bij project ontwikkeling is het belangrijk om alles zo simpel mogelijk te houden. Wees niet bang voor verandering, hier is namelijk geen ontkomen aan, hier wordt juist waarde aan gehecht in een Agile project. Zo kunnen talloze factoren meespelen in het brengen van verandering in een project. De project manager moet dit omarmen in een dynamisch non-stop veranderend landschap. Belangrijk is een stapsgewijze ontwikkeling. Er is geen plaats voor het ontwikkelen van een alomvattend perfect project plan bij Agile. Ontwikkel in kleine porties 4
Wat is Scrum en hoe werkt het? Scrum is een Agile manier om een project te managen. Het werd ontwikkeld in de vroege jaren 90 door Ken Schwaber en Jeff Sutherland en is vastgelegd in hun Scrum Guide. Ze maken duidelijk dat het belangrijk is om Scrum niet te zien als een techniek of een proces om een product te creëren. Zie het als een framework waarin je verschillende processen en technieken in kunt gebruiken. Het Scrum framework bestaat uit Scrum teams, de bijbehorende rollen, evenementen, producten en regels. Sprints Scrum werkt met sprints. Een sprint heeft tijdsbestek van een aantal weken (meestal duren sprints 2 tot 3 weken). In deze weken wordt een gedeelte van het project uitgewerkt. Via sprints worden stukje bij beetje verbeteringen aangebracht aan het product dat wordt ontwikkeld. In de Scrum community staan sprints ook wel synoniem aan iteraties. Hoeveel sprints er nodig zijn om een project te voltooien ligt aan de tijd die het kost om een Minimal Viable Product (MVP) te creëren. Drie sprints is ongeveer het minimale om mee te beginnen. Daily Scrum Gedurende een sprint houdt het team dagelijks een Scrum bijeenkomst. Dit wordt de daily Scrum genoemd. Vaak zijn deze meetings rond dezelfde tijd op dezelfde locatie en in de ochtend, zodat de context al gauw bepaald kan worden voor de rest van de dag. Het is van belang dat alle teamgenoten aanwezig zijn bij elke Scrum bijeenkomst. De bijeenkomst draait niet om het oplossen van complicaties. Het is de bedoeling dat elk teamlid antwoord de volgende vragen beantwoord: 1. Wat heb ik gisteren/sinds de vorige meeting gedaan? 2. Wat ga ik vandaag/tot de volgende meeting doen? 3. Tegen welke complicaties ben ik tegen gelopen, en welke hulp heb ik hierbij nodig? Het doel van deze vragen is binnen korte tijdsintervallen per persoon te weten te komen welk werk er is verricht en wat er nog te doen staat. De meeting is geen controle om te kijken of iedereen wel op schema loopt. Het draait erom om als team elkaar van inzicht te voorzien wat betreft de voortgang van 5
het project, en om elkaar vervolgens duidelijk te maken welke volgende stappen er worden genomen. Dus wanneer een User Experience Designer zegt dat hij morgen een set wireframes gaat opleveren, dan weet het team dat zij kunnen aannemen dat dit er de volgende morgen bij de Daily Scrum ook daadwerklijk zal zijn. Het team maakt in feite geloftes aan elkaar wat betreft de volgende oplevering. Product Backlog In de Product Backlog staat een lijst van alles wat wellicht nodig is in het product. Het is een bron van eisen waar vervolgens naar gekeken kan worden wanneer er veranderingen gemaakt moeten worden aan het product. De Product Backlog zit vol met items, ook wel genaamd: user stories. Gedurende een sprint worden verschillende user stories gerealiseerd. Op deze manier wordt de Product Backlog gevuld. Bij het doorlopen van een aantal sprints veranderen de user stories en dus ook de requirements. De Product Backlog is dynamisch. Het verandert constant om te bepalen wat het product nodig heeft om competitief, bruikbaar en passend te zijn. User Stories User stories zijn korte simpel omschreven kenmerken beschreven vanuit het perspectief van de gebruiker of klant. Het is van belang dat de stories niet door één persoon worden geschreven. Vaak schrijft iedereen in het team user stories. Het is minder van belang wie het schrijft. Wat belangrijker is zijn de discussies die uit de user stories voorvloeien. Daarbij staat het delen en het begrijpen van de user stories door het team hierbij centraal. Vaak wordt het volgende template gebruikt om tot een user story te komen: Als een <type gebruiker/rol> wil ik <doel/user need> zodat ik <waarde/resultaat> Indien er een reeks user story opleveringen zijn atfgeleverd volgt de sorteer fase. Sommige user stories zijn namelijk meer relevant dan de andere. Het team gaat de stories vervolgens sorteren op relevantie. Hierbij heeft de Product Owner het laatste woord. 6
Het Scrum board Het Scrum board is een bord die overzicht verschaft van een sprint. Op dit bord zijn sprint backlog items weergegeven. Je ziet hierop in één oogopslag hoe de sprint vordert. Daarbij heb je te maken met 3 kolommen: To Do Doing Done Scrum rollen & team In een Scrum project wordt er gewerkt met verschillende rollen. Zo heb je de Scrum Master en de Product Owner. Naast deze rollen heb je het team. Het team zal het daadwerkelijke werk leveren om zo de sprint doelen te realiseren. Dit team is meestal niet kleiner dan vijf, of groter dan negen mensen (de Scrum Master en Product Owner tel je niet mee). Dit vergt namelijk teveel coördinatie en complexiteit om effectief te kunnen functioneren. Van het team wordt verwacht dat het multidisciplinair is, zelfsturend en zelforganiserend. Zij zijn dus zelf verantwoordelijk voor het werkproces. Een Scrum team ziet er vaak als volgt uit: Scrum Master Product Owner (PO) visual designers interaction designers front-end developers back-end developers copywriters 7
De Scrum Master De Scrum master zorgt ervoor dat het team Scrum begrijpt en dat Scrum juist wordt uitgevoerd. Hij/zij zorgt ervoor dat het team de regels en theorie van Scrum navolgen. Als een soort coach zorgt hij/zij ervoor dat iedereen in het team zelforganisatie en cross functionaliteit binnen het team juist toepast. Daarbij zorgt hij/zij ervoor dat alle Scrum elementen op de juiste momenten en op de juiste tijden worden uitgevoerd. Enige obstakels zoals onenigheden in het team of moeite hebben met bijbenen door een bepaald teamlid zijn punten waar de Scrum Master nauw bij betrokken is. Het is zijn/haar taak op deze zaken in te spelen. Zo zou je de Scrum Master als een persoon die ervoor zorgt dat het gehele team op een aangename en juiste manier kan functioneren. Daarbij is het ook de taak van de Scrum Master om het team te motiveren en om een positieve werksfeer te bewerkstelligen. Vaak is de Scrum Master een interaction designer of een project manager, indien het project en de teamstructuur dit toelaat. De Product Owner (PO) De Product Owner is in feite de eigenaar van het product namens de klant en de stakeholders. Hij/zij is verantwoordelijk voor het maximaliseren van de waarde van het product. Samen met de Scrum Master schrijf de Product Owner de user stories die vervolgens in de Product Backlog komen te staan. Daarnaast verschaft de Product Owner de Product Backlog van onderhoud. Elk item in de backlog moet duidelijk omschreven zijn en in een heldere volgorde staan zodat het team inzicht en helderheid heeft in hetgeen waar zij opeenvolgend aan moeten werken. Indien er enige veranderingen of aanpassingen in de Product Backlog gewenst zijn, dan zou je de Product Owner moeten overtuigen van de toegevoegde waarde hiervan. 8
Hoe is Scrum anders t.o.v. traditionele PM methodes? Project management is een vorm van procesbeheersing. Traditionele project management methodes verschillen in dit opzicht met Scrum. Waterval vs Scrum Neem bijvoorbeeld de traditionele Waterval methode; een stapsgewijs en linear proces. Zoals de naam Waterval al suggereert, en wat je hier beneden goed kunt zien is dat het proces een bepaalde sequentie volgt; als een waterval stroomt Bron: http://www.silodesign.nl/images/_images/scrum_infographic_schets2_x700.jpg het proces van het beginpunt naar het eindpunt. Een Agile methode zoals Scrum werkt heel anders in dit opzicht. Daar waar traditionele project management methodes zoals waterval een late oplevering hebben en kampen met het risico dat het verkeerde product wordt opgeleverd speelt Scrum hier juist op in. Zo kan bij Scrum vaak na de eerste Sprint al feedback vanuit een werkend product worden geleverd. Bij Waterval is aan het begin duidelijk welke requirements er nodig zijn, bij Scrum kunnen de requirements al gauw veranderen en aangepast worden. Waterval werkt met Bron: http://www.commonplaces.com/sites/commonplaces.com/files/waterfall_method. png één vast plan, bij Scrum kan deze planning aangepast worden. Kortgezegd: Waterval staat voor zo min mogelijk verande- 9
ring; Scrum omarmt het maximaliseren van de voordelen van goede veranderingen. Verantwoordelijkheden worden bij Waterval vooral gedragen door de Project Manager. Bij Scrum ligt de verantwoordelijkheid verdeeld over het team. Waterval werkt volgens een schema waarbij opleveringen strak op papier worden aangegeven. De scope wordt anders bepaald bij Scrum, waarbij de teamleden bij de Daily Scrum aangeven wat hun volgende oplevering zal zijn. Zelfmanagement en zelforganisatie staan hoog in het vaandel bij Scrum. Bij Waterval bepaalt de Project Manager de manier van management en organisatie. Voor gemak staan hier nogmaals de besproken punten op een rij: Bron: http://www.scrumstudy.com/scrum-vs-traditional-pm.asp 10
Hoe vervult de UX er zijn rol in een Scrum team? Agile frameworks zeggen niks over user experience/design elementen. De invulling van de positie/rol van de User Experience Designer varieert dan ook van bedrijf tot bedrijf. Daarbij zijn er diverse aanpakken om de Agile omgeving vóór en niet tegen de UX er te laten werken. Een User Centered aanpak in het Agile Framework De uitdaging van een User Experience Designer in een Agile framework zit in het verzamelen van data van contextuele onderzoeken om snelle iteraties van prototypes te valideren via usability tests. Een bedrijf genaamd Salesforce.com heeft de uitdaging van het snel valideren van prototypes en het verzamelen van relevante data opgelost door een grote groep users te vragen om te participeren in het proces op verschillende manier; dit doen zij door: elke maand een groep gebruikers van deze duizenden participanten uit te nodigen om samen te werken met Salesforce personeel om prototypes en werkende software te testen Deze aanpak vindt zijn kracht in het snel, simpel en vaak testen. Tests in de vorm van screen-sharing, screen recording tot het delen van digitale prototypes tot het houden van korte telefoongesprekken waarbij likes en dislikes worden gedeeld zijn manieren om vroeg in het proces validatie te verkrijgen en om relevante data te verzamelen. Ten opzichte van een meer traditionele methode zijn er vele meer iteraties en dus ook meer confrontaties met de gebruiker en zijn behoeftes in een Agile aanpak. de gebruikers hun ideeën laten delen via een custom website de gebruikers uit te nodigen voor hun user experience blog en user experience marketing campagnes (hierbij tellen zij duizenden participanten) Een Agile project management aanpak zorgt ervoor dat een product snel via vele iteraties aangescherpt kan worden en via deze manier in de juiste richting begeleid kan worden. Bij traditionele development wordt het ontwikkelde product pas in een ver stadia getoond; met alle gevolgen van dien. Wanneer 11
een gebruiker gauw en in een vroeg stadium met een product wordt geconfronteerd kan er direct worden ingespeeld op de eventuele kink in de kabel. Een volgende iteratie en een volgende usability test kan vervolgens hierop verder doorborduren. Een groot voordeel van deze Agile aanpak voor de UX er is het feit dat het product mee kan groeien met de user needs zodat deze te allen tijde worden gewaarborgd. De UX er als Product Owner of Scrum Master? De User Experience Designer is vaak de Product Owner, of maakt deel uit van een Product Owner team. In vele succesvolle organisaties is het User Experience team het Product Owner team, en in andere gevallen heeft de User Experience Designer een nauwe band met de Product Owner. De User Experience Designer is nauw betrokken wanneer het gaat om wat er moet worden gemaakt en welk werk er eerst gedaan moet worden (de User Stories op prioriteit ordenen). De User Experience Designer begrijpt de klant. Door contextuele interviews, field studies, usability tests en persona ontwikkeling leveren zij vervolgens een lijst aan user needs aan. Gezien de User Experience Designer(s) vaak exclusief eigenaar is van deze kennis komt het vaak voor dat de Product Owner naar de UX er toerijkt om deze kennis te vergaren. Het komt echter vaak voor dat de rol van Product Owner veel tijd in beslag neemt en dat de toevoeging van UX elementen voor extra last zorgt. Een oplossing hiervoor is het splitsen van de Product Owner rol, waarbij de User Experience Designer en de Product Owner nauw samenwerken als één orgaan. Bij ontwerpbureau Fabrique kaart Pieter Jongerius (Scrum trainer, Strategist en UX passionate) aan dat de meeste Scrum Masters bij Fabrique senior UX designers zijn. Daarbij zegt Pieter dat wanneer je wilt dat je design impact heeft je User Experience Design los moet laten van de Product Owner, en dat de UX er niet moet fungeren als een adviesorgaan naar de Product Owner toe. Pieter ging met Jeff Patton (independent consultant, teacher & Agile coach) hiermee in discussie. Pieter is van mening dat UX aan de basis van Agile kan staan. Jeff is van mening dat UX een plaats naast het Agile Development team moet innemen. Na het wisselen van een aantal woorden kwamen ze tot een consensus waarbij Jeff Patton toegaf dat dat wellicht erg goed zal werken. 12
Antwoord op Hoofdvraag Hoe is Scrum Agile van waarde in het werkproces van de CMD er en User Experience Designer anno nu? Agile is een krachtig gedachtegoed. Door de vele korte iteratie momenten kan er goed worden ingespeeld op de veranderende eisen van de klant, wat zorgt voor een sterk afgericht product die nauw aansluit op de behoeftes van de gebruiker. Scrum als raamwerk is een zeer waardvol project management methode. Gezien het een raamwerk is vraagt het echter wel om eigen invulling. Zo zijn er een aantal conventies waar de meerderheid baat bij heeft, echter wat belangrijker is is om te kijken wat werkt voor jouw unieke situatie, jouw project en of het past in jouw (bedrijfs)cultuur. Daarbij is belangrijk dat de juiste mensen de juiste rollen vervullen. Wanneer de klant de rol als Product Owner vervult kan dit zorgen voor een sneller, maar vooral effectiever proces. Wordt de UX er de Scrum Master? In hoeverre ondersteunt hij/zij de Product Owner? Zo zegt Agile coach Skyp Angel: Scrum is easy to learn, but difficult to master. 13
Bronnenlijst Boeken Get Agile! Scrum for UX, design & development Jongerius, P. (2012) blz 10 t/m blz 44 PDF publicaties http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.pdf Sy, D. (2007, May) blz 120 http://cdn2.hubspot.net/hub/134568/file-505882676-pdf/enfocussolutions_dualtrackagile_2.4.14.pdf Parker, J. (2014, February 4) https://www.scrum.org/portals/0/documents/scrum%20guides/scrum_guide.pdf Sutherland, J. Schwaber, K. (2011, October) http://www.agileproductdesign.com/writing/ieee/patton_getting_software_rite.pdf Patton, J (2008, May/June) https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/2013-state-of-scrum-report_062713_final.pdf Scrum Alliance (Unknown) (2013, June) 14
Artikelen http://agilemanifesto.org/history.html Highsmith, J. (2001) http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/ Agile Alliance (Unknown) (2014) http://boxesandarrows.com/the-ux-professionals-guide-to-working-with-agile-scrum-teams/ Rosenstein, A. (2013, September 2) http://www.mountaingoatsoftware.com/agile/scrum Mountain Goat Software (2012) http://www.mindtools.com/pages/article/agile-project-management.htm Mind Tools (2014) http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html Patton, J. (2008, June 27) https://www.planbox.com/blog/agile/scrum/research/2013-study-reveals-statistics-on-agile-market-share.html Planbox. (2013, October 25) 15
http://www.leanagiletraining.com/agile/waterfall-versus-scrum-how-do-they-compare/ LeanAgileTraining (2012, March 24) https://www.udemy.com/blog/agile-vs-waterfall Mikoluk, K. (2013, September 9) http://www.demystifyingusability.com/2012/02/agile_ux_product_owner.html Spillers, F. (2012, February 28) http://www.jeffgothelf.com/blog/ux-designer-as-product-owner/#sthash.xsrlgfiv.0rxcdguu.dpbs Gotheif, J. (2011, February 17) Geïnterviewden Jeroen van Geel Scrum & product personality specialist http://www.jeroenvangeel.com https://www.linkedin.com/in/jeroenvangeel https://twitter.com/jeroenvangeel Michiel Rovers - Docent & onderzoeker nl.linkedin.com/pub/michiel-rovers/10/983/256 https://twitter.com/michielrovers 16
Bijlage A: interview 1 Geïnterviewde: Jeroen van Geel Website: http://www.jeroenvangeel.com Twitter: https://twitter.com/jeroenvangeel Jeroen is een UX er, een Scrum & product personality specialist. Schrijver. International speaker. Jeroen werkt op dit moment bij Strategic design studio Oak & Morrow. Hij heeft gewerkt bij Dutch Design Week Digital, Fabrique en Johnny Holland. Ziet u de UX er de rol van Scrum Master of Product Owner vervullen? Zo zijn er veel organisaties waarbij de UX er de rol van Product Owner overneemt of dat de UX er in nauw verband in feite één orgaan is samen met de Product Owner. Het verschilt per organisatie, het ligt aan de cultuur van je organisatie. Wat is een UX er? Dat verschilt ook enorm in een team, en per bedrijf. In het ene bedrijf zijn dit informatie architecten, in het andere bedrijf zijn het halve strategen, zo zwart wit kun je het niet zeggen. Ik ben UX er, Interactie Ontwerper, maar ik was ook Scrum Master. Bent u welleens Product Owner geweest? Ik ben welleens Product Owner geweest omdat de klant er niet was. In principe dwing ik altijd af dat de klant er is. De klant is de Product Owner, en die weet hoe dat in elkaar zit. Ik als Scrum Master vervul de rol van UX er, en stuur ik de Product Owner aan. Ook ondersteun ik hem/haar in het goed prioritizeren en schrijven van de User Stories. 17
Waar een UX er heel goed in is, is een User Story schrijven. Wat is een User Story ten opzichte van wat is een functionele omschrijving. Ik wil mij aanmelden voor een nieuwsbrief is geen User Story, dat is een functionele omschrijving. Die splitsing kan een UX er heel goed maken. Ik heb wel voorbeelden meegemaakt bij ons waarbij we onsuccesvol waren een klant mee te nemen in een project, en daar was de UX lead Product Owner geworden. Het is dus wel logisch dat je UX er de Product Owner wordt als je klant het niet kan zijn. De ideale situatie is dat de klant altijd de Product Owner is. Dat de klant over het budget gaat en intern de politiek aanvoelt in de organisatie. Hoe dichter hij tegen het projectteam aanzit hoe sneller hij beslissingen kan maken. Je hebt te maken met Daily Scrums, is het zo dat de klant en dus de Product Owner hier elke keer bij moet zijn? Idealiter wel. Ik heb projecten meegemaakt waarbij de klant alle dagen aanwezig was, en ik heb projecten meegemaakt waar de klant één of twee keer per week aanwezig is. Hoe is het anders indien de klant elke dag aanwezig kan zijn bij de Daily Scrum? Dat is beter. Hoe meer hoe beter, als je de juiste Product Owner hebt. De ene persoon is veel meer een control freak dan een ander persoon. Je moet een persoon kiezen met de juiste instelling. Hij/zij moet in de organisatie mandaat hebben om keuzes te maken, en de inhoud te snappen om ook die keuzes te kunnen maken, en aan de andere kant moet hij/zij niet teveel een control freak zijn. Jij en jij moet dit en dat doen is uit den boze. Het team beslist. Wij zeggen vaak kom bij ons zitten. Dan voel je de discussie, dan voel je waar wij tegenaan lopen of wat soepel gaat. Hoe heeft Scrum populariteit gewonnen in Design teams? Er wordt vaak een fixed price gevraagd, dit is wat wij nodig hebben om het projejct te doen. We hebben twee contact momenten en dan is het klaar. Dat werkt niet. Want als jij in twee contact momenten niet raakschiet, dan heb je een probleem. Vraag je dan meer geld? En dan zegt de klant, nee 18
ik wil niet meer geld betalen want het is nog niet goed en ik betaal voor een goed resultaat. Die controle over het eindresultaat, die wil iedereen hebben. We hebben bij Scrum te maken met Sprints, de iteraties waardoor de requirements kunnen meebuigen gedurende het proces. Is dit wat een gewenst eindresultaat waarborgt? Absoluut. Waardoor het zo succesvol is, is omdat je gegarandeerd een eindresultaat hebt, wat de klant een gerust gevoel geeft, en tegelijkertijd geeft het ook de Design bedrijven de controle over het budget. We gaan niet over het budget heen. Aan de andere kant is de grootste uitdaging waar ontwerpbureaus tegenaan lopen. Hoe zorg je ervoor dat je kwaliteit kunt leveren? Waar Scrum ook voor gezorgd heeft is dat projecten niet meer outstanding zijn, dat ze een soort van richting de 7-tjes zijn gegaan. Daar is heel veel discussie over bij een aantal design bureaus. Hoe kunnen we ervoor zorgen dat we wel iets neerzetten wat een verschil maakt, qua design. Je ziet dat de projecten die qua design een groot verschil maken, daarin wordt vaak niet gescrumt, of die zijn van tevoren helemaal dichtgetimmerd wat betreft hoe het er grafisch uit gaat zien. Bij techniek maak je een architectuur en dat ga je gewoon bouwen. Bij design wil je op een bepaalde manier keuzes maken die niet in een groepsproces zijn vast te leggen. Een designer kan gewoon in zijn eentje drie weken iets ontwerpen, of hij bedenkt het in één uur, maar die heeft tijd nodig om op iets te broeden. En dat werkt niet zo goed in Scrum. Is Dual Track Scrum een effectieve methode? Als de ontwikkelaars ineens erg snel gaan, dan moet je achter de ontwikkelaars aan. Je moet proberen voor te blijven. Bij 9292 bijvoorbeeld zaten wij één sprint voor. Én je loopt voor en je moet daar waar de ontwikkelaars een sprint achterlopen moet je ook weer met hun meedenken want zij komen ook weer dingen tegen. Dus je bent naar voor en achter aan het springen de hele tijd. Dit is prima, maar nogsteeds is het concept wat neer is gezet het uitgangspunt, en de design principles zijn voor het sprinten bedacht. We kunnen niet design principles tijdens het sprinten bedenken, dat is bijna niet te doen. 19
Welke tips/advies zou u geven aan de CMD student, de beginnende Scrummer om via een toegankelijke wijze Scrum juist toe te passen? Het makkelijke antwoord, maar wat moeilijk is uit te voeren: doe het met een ervaren iemand. Zorg dat je één ervaren iemand hebt die het proces begeleidt. Het uit de boekjes overnemen en het zelf gaan proberen is altijd moeilijk. Houd je aan de basis regels en volg deze strak op. Ik ben een extremist wanneer het om sommige principes gaat. Altijd een stand-up, iedere dag, een kwartier en niet meer. Alles op de wand hangen. Je Product Backlog volledig uitgeschreven, en doe niks digitaal. U bent niet fan van online tools? Waarom niet? Als je het op de wand hebt hangen. Dit werkt psychologisch. Iemand hangt zelf een post-it met zijn taak erop, verplaatst hem zelf actief, dan zit er een mentale commitment aan de taak. Dan kun je ook niet zeggen van ja ik wist niet dat het er hing of jij hebt het verplaatst, nee dit heb jij zelf gedaan, dus je weet wat je moet doen en je weet wat er moet gebeuren. Het hang altijd in het zicht. Je ziet iedere seconde hoe ver je bent met het project. Hoe zit het met Scrum als framework. Zo gebruikt iedereen zijn eigen soort methodieken en is er geen één antwoord op het hanteren van de juiste methode. Hoe zie jij dit? Het hangt heel erg van de bedrijfscultuur van waar jij vandaan komt hoe dit precies ontstaat. Bij Fabrique waar ik lang gezeten heb en waar Get Agile ook vandaan komt spreken we van een design organisatie. Dit is ook de eerste organisatie waar Scrum aangepast richting een design structuur. Als je kijkt naar de projecten die hieruit voortgekomen zijn geloof ik wel dat dat de way to go is. Dat UX in de lead is en een belangrijke/prominente rol heeft in een Scrum proces. UX moet dus de backbone van het gehele proces zijn? Ja. En als je het lostrekt. Dat kan gewoon niet. Want alles is UX. Iedere beslissing, iedere seconde in een Scrum proces bepaalt hoe de UX is. Hoe de database opgezet is. Hoe dingen gekoppeld zijn aan elkaar, bepaalt hoe de UX aan de voorkant is. Je kunt wel zeggen, de ontwikkelaars moeten dit maken met deze 20
voorwaardes, maar als zij er tijdens het proces erachterkomen dat een bepaalde koppeling drie dagen kost in plaats van één dag, laten we het maar niet doen. Dan vind ik dat de UX er het team moet beïnvloeden en moet zeggen: wat doet dit met het eindresultaat? Ja. Dus, als je dit zou doen, hoe zou dat dan door de UX-check heengaan. Wat levert dat dan op. Je moet het bespreekbaar en zichtbaar maken. Dat is een gevoel en soms een mening, dan ga je het meten, of degene die het hardste schreeuwt die krijgt gelijk. Hoe kan de UX er valideren of ervoor zorgen dat het team deze UX-mindset hanteert? Dit hangt van verschillende dingen af. Je reputatie is maakt bijvoorbeeld ook uit. Meten is weten. Na iedere sprint of na iedere paar sprints een usability test doen, een user test doen en laten zien dat het werkt. Ik heb bij een project van de Nederlandse Schaatsbond via Treejack een snel een eenvoudig testje in elkaar gezet. Deze zet je in een kwartiertje op, je stuurt het naar honderd mensen toe en de volgende dag heb je output. Bij 9292 had ik één grote poster gemaakt genaamd de UXcheck. Dit was een set vragen; snapt mijn moeder het? Werkt dit? Deze UX-check werd dus ook dagelijks uitgevoerd? 21