HOE WERKEN WE SUCCESVOL MET SCRUM? Promotor: mevr Bieke Masselis

Transcriptie

1 HOE WERKEN WE SUCCESVOL MET SCRUM? Promotor: mevr Bieke Masselis Project performed by STUDENT JOREN VANDAMME to achieve the degree Bachelor in the NEW MEDIA AND COMMUNICATION TECHNOLOGY Howest

2

3 HOE WERKEN WE SUCCESVOL MET SCRUM? Promotor: mevr Bieke Masselis Project performed by STUDENT JOREN VANDAMME to achieve the degree Bachelor in the NEW MEDIA AND COMMUNICATION TECHNOLOGY Howest

4 WOORD VOORAF Mijn naam is Joren Vandamme en ik ben student New Media & Communication Technology aan Howest Kortrijk (NMCT). Al van jongs af aan ben ik geïnteresseerd in alles dat met computers te maken heeft. Het is voor mij nog steeds een moeilijke keuze maar ik ben nu toch de programmeer kant opgegaan. Het ontwikkelen van iets dat vlot werkt voor de gebruiker is iets dat ik graag zou doen. Als jobstudent en ook thuis heb ik mensen zien werken en vloeken op software omdat ze niet logisch in elkaar zit. Persoonlijk vind ik dat heel erg jammer. Op school kregen we tijdens de DES-weken, Digital Expert Weken, een infosessie over Scrum. Ook de manier waarop we het moet gebruiken werd uitvoerig uit de doeken gedaan. Tijdens ons project hebben we dat met vier teamleden eens getest. Ondanks de goede uitleg is het ons niet echt gelukt om met scrum te werken. We hebben maar eerste dag, tijdens de 2 de week van dat project, gewerkt volgens het scrum principe. Allerlei onderdelen van de techniek werden vergeten en we vielen terug op de watervalmethode. Een van de pijlers van scrum is dat je vaak met de gebruiker waarvoor we de software schrijven samen zit. Dit is zodat de gebruiker zijn mening er over kan geven en bijsturen waar nodig. Tijdens zo een gesprekken merken we dat de gebruiker toch anders denkt dan de ontwikkelaars. Die gesprekken zijn dan ook niet altijd zo gemakkelijk, maar wel heel erg nuttig. In de praktijk zien we mensen werken met maatsoftware en gaat dat niet altijd zo vlot als we zouden denken. Dat is software die grotendeels kan wat de gebruikers nodig hebben, maar waar ze toch nog onderdelen missen of dat het niet zo vlot werkt. Dat is wel vreemd voor op maat gemaakte software. Het is enorm moeilijk voor de ontwikkelaar om zich volledig in te leven in zijn gebruiker, en daar bied scrum dan een oplossing voor. Doordat de gebruiker vaak feedback kan geven die het gebruik van de software veel aangenamer of logischer voor hem gaat maken. Op mijn stage heb ik kunnen proeven van scrum, en het aangenaam ontvangen. Hiervoor wil ik Bart Strubbe van CLEW Systems & Software bedanken. Ook zeker en vast niet te vergeten zijn mijn stagementor, Bieke Masselis, voor haar enorm uitgebreide feedback.

5 ABSTRACT Hoe werken we succesvol met scrum? Door Joren Vandamme, student New Media and Communication Technology aan de Howest te Kortrijk. Voor het ontwikkelen van software bestaan er verschillende werkmethodes. Een van de meer onbekende is scrum. Deze methode heeft een grotere kans om een project succesvol te volbrengen ten opzichte van de meest gangbare methodes. Dit is ook de reden dat veel teams en managers wel eens gebruik willen maken van scrum. Het probleem hierbij is dat velen hals over kop scrum gaan doen. Dit werkt niet zo, men moet goed weten waarmee ze bezig zijn voordat ze er mee beginnen. Scrum gebruiken lijkt gemakkelijk maar dat is verre van waar. Er zijn veel valkuilen en manieren waarop scrum projecten kunnen falen. Er is training nodig voor de scrum master zodat hij het team kan coachen. De scrum master moet durven het team sturen. Dat betekent niet dat hij zich als een manager moet gedragen. De scrum master is de woordvoerder van het team en moet sterk in zijn schoenen staan. Zeker wanneer hij tegenover de product owner staat, die als klant vertegenwoordiger altijd meer wilt.

6 VERKLARENDE WOORDENLIJST Scrum: Is een flexibele manier om (software)producten te maken. Sprint: periode van op voorhand vastgelegde duur waarin we een onderdeel van het project proberen af te werken, waarna een demo volgt. Maatsoftware: software die op maat van de gebruiker is gemaakt. Fibonacci nummers: Het volgende nummer is de som van de vorige 2 nummers: 1,2,3,5,8,13,21, Product backlog: De onderdelen die moeten gebeuren (ontwerpen, bugfixen) om tot het werkend eindproduct te komen. Sprint backlog: De onderdelen die moeten gebeuren tijdens een sprint, worden uit de product backlog genomen. Sprint retrospective: Meeting na een sprint review, enkel voor teamleden. Herbekijken van hoe de sprint verlopen is. Sprint Review: Meeting na een sprint, worden demo s gegeven van wat er die sprint gemaakt is. Wireframe: Snelle schets van hoe een onderdeel of scherm er visueel uitziet. Scrum master: Middelpunt van het scrum team, coacht het development team en is het communicatiepunt tussen de product owner en het development team. Product owner: Persoon die de toekomstige gebruiker(s) van het product belichaamt. Hij moet dus heel erg goed weten wat de bedoeling en verwachtingen van het product zijn. Burndown chart: Een overzicht van de snelheid waarmee we de taken tijdens een scrum kunnen vervolledigen. Scrum Artefacts: Groep van de product backlog, sprintbacklog en burndown chart. Whiteboard: Bord waar men met stiften op kan tekenen en snel weer uitwissen, handig voor snel schetsen of teksten op te plaatsen. Ook post its blijven hier goed op hangen. Stand up: Dagelijks moment waarbij alle leden van het developersteam kort overlopen wat ze gisteren gedaan hebben, wat ze vandaag gaan doen, en welke hindernissen ze zijn tegen gekomen.

7 INHOUDSOPGAVE Inleiding Wat is scrum?... 9 SPRINTS... 9 KLEINE MULTIDISCIPLINAIRE TEAMS... 9 FLEXIBILITEIT DOORZICHTIGHEID INSPECTIES Hoe scrum gebruiken? STAP 1: PRODUCT OWNER, SCRUM MASTER & BACKLOG STAP 2: SCHAT DE BENODIGDE TIJD STAP 3: SPRINT PLANNING STAP 4: SPRINT PLANNING (TAKEN) STAP 5: WERKPLEK STAP 6: SPRINT! STAP 7: STAND UP! STAP 8: BURN DOWN CHART STAP 9: AFWERKING STAP 10: HERBEKIJKEN, VERBETEREN EN OPNIEUW Wat gaat er mis? SCRUM EENS WILLEN PROBEREN, MAAR MICROMANAGEN ZICHZELF BLIJVEN OVERSCHATTEN TE GROTE TEAMS PRODUCT OWNER PROBLEMEN ROLLEN UIT ELKAAR HOUDEN Hoe meer kans maken op slagen? SCRUM MASTER PRODUCT OWNER DEVELOPER MANAGER Besluit Referentielijst

8 INLEIDING De meest gekende techniek om software te ontwerpen is de waterval methode. Bij deze methode gaan we door een paar fasen, en we beginnen niet aan de volgende fase voordat de vorige fase afgelopen is. We gaan er dan ook van uit dat er geen fouten zijn gebeurd in vorige fases. Deze methode werkt vaak wel voor kleine projecten, maar voor grotere projecten kan het soms erg lang duren voordat de klant iets te zien krijgt, en als er iets veranderd is in die periode, moeten we helemaal opnieuw beginnen. Een kort woordje uitleg over scrum: scrum is onderdeel van de agile techniek, het is iets dat niet veel mensen kennen, en dat hoeft ook helemaal niet. Enkel (software) ontwerpers moeten er ooit eens van gehoord hebben. Sommige klanten weten nog niet goed wat ze willen of nodig hebben bij het opstellen van hun project omschrijving. Hierdoor krijgen ze bij de oplevering van hun project niet altijd wat ze echt nodig hebben. Dit kan zijn door het ontbreken van onderdelen of een enorm ingewikkelde of onbruikbare user interface. Met scrum gaan de ontwerpers onderdeel per onderdeel afwerken, en dat op vaste momenten aan de klant tonen, die zo weet waar de ontwerpers mee bezig zijn, en ook zijn mening kan geven. Wat kan er beter en wat er ontbreekt. Het is mogelijk dat het op deze manier een beetje langer duurt om een project af te krijgen, maar het eindproduct is wel iets waarvan de ontwerper weet dat zijn klant er wat mee kan, en de klant is blij dat zijn product iets is waar hij heel blij mee is, ook al wist hij in het begin niet eens wat hij echt nodig had. Nu hebben wij daar op Howest over geleerd, en in de praktijk om moeten zetten. Daar viel op dat maar bitter weinig groepjes echt slaagden in het gebruik van scrum. Van mijn stiefbroer, die ook voor een software ontwikkelingsbedrijf werkt, hoorde ik dat ze daar soms ook eens scrum proberen, maar dat ze dat niet lang volhouden en al snel weer in het oude ritme terugvallen. Projecten moeten zijn wat de klant wilt, de klant moet tevreden zijn over wat zijn software voor hem kan doen. Niet teveel en niet te weinig toeters en bellen. De klant moet snel en intuïtief met zijn software om kunnen gaan. Ik ben heel erg geïnteresseerd in het maken van software waarmee je heel intuïtief kan werken. Ik ben geïnteresseerd in het gebruik van scrum. Ook omdat je op die manier meer contact zou hebben met je collega s en weet waar zij mee bezig zijn. Je weet dan ook sneller bij wie je moet zijn voor een bepaalde technische vraag. Omdat op mijn stageplek ook volgens het scrum principe gewerkt wordt, zou ik hier willen zien hoe het echt moet. Deze bachelor proef is dus vooral geschreven vanuit deze twee perspectieven. Het vak project in de richting NMCT en het efficiënte gebruik van scrum in mijn stagebedrijf CLEW. Natuurlijk lees ik hier ook veel literatuur rond. Als resultaat schrijf ik een advies, met tips en gouden regels waar iedereen zich aan moet houden. Zorgen dat de managers, de klanten en de teamleden op dezelfde lijn zitten, en dat wanneer er iets mis begint te lopen, er op tijd kan bijgestuurd kan worden en er geen terugval is naar de waterval methode. 8

9 1. WAT IS SCRUM? De term scrum komt van de rugby sport. In een scrum gaat van elke partij een groepje samen tegen elkaar staan, waarna de bal er in geworpen wordt en elke groep zo hard mogelijk tegen elkaar gaat duwen om de tegenstanders van de bal weg te duwen, en zo de bal zelf te pakken te krijgen. Het belangrijke deel hiervan is dat je samen werkt, samen duwen tegen de tegenstander, te vergelijken met een omgekeerde touwtrekken. De scrum waar we nu over wil spreken is een software ontwikkelingstechniek. De oude, meer gekende, en voor kleine projecten niet zo slechte techniek, is de waterval techniek. Het probleem met de waterval techniek is dat het soms niet lukt om een project af te krijgen en de klant misschien niet blij is met het eindresultaat. Scrum heeft een paar belangrijke onderdelen. Sprints Kleine multidisciplinaire teams Flexibiliteit Doorzichtigheid Inspecties Sprints Een sprint is een periode van een maand of minder waarin we afspreken een aantal onderdelen af te werken, bijvoorbeeld het inlogscherm en editscherm van een website. Het team focust zich daar volledig op zodat het volledig functioneel is en er geen fouten meer in zitten. Na deze periode gaat het ontwikkelingsteam een demo geven aan de klant. Die ziet dan waarmee ze bezig zijn en kan feedback geven over wat hij anders wil. Dit is vaak nog snel aan te passen in een volgende sprint. Deze sprints blijven elkaar opvolgen tot het hele project af is. Kleine multidisciplinaire teams Het team bestaat uit een aantal rollen. Figuur 1: scrum in rugby bron: wikipedia Scrum (softwareontwikkelmethode) Product eigenaar Development team Scrum master De product eigenaar is één persoon die alles in goede banen leidt, dit door aan het scrum team te zeggen aan welke onderdelen van het project gewerkt wordt. Het scrum team luistert enkel naar deze persoon, en mag zich niet inlaten door wat andere mensen zeggen. Het Development team bestaat het beste tussen drie tot negen mensen. De product eigenaar en de scrum master tellen hier niet mee, tenzij ze ook mee werken aan het project. De reden dat een team niet kleiner dan drie mag zijn, is dat er problemen kunnen zijn met gebrek aan skills, en hierdoor tijd verloren gaat aan het leren van die skills, waardoor ze mogelijk een sprint niet vervolledigen. 9

10 Te grote teams zijn dan weer lastig qua coördinatie, sommige onderdelen van de scrum (zien we later nog) zouden te lang kunnen duren, en het maakt het ook complexer, wie werkt er aan wat? Wat had de eerste nu weer verteld tijdens de stand up? Een development team bestaat uit mensen die het potentieel hebben om een sprint succesvol af te sluiten. Ze moeten de verantwoordelijkheid van hun werkgever krijgen om zelf hun werk te organiseren en managen, er mag niemand over hun schouder meekijken en commentaar geven. Dat leid hen af, zie scrum master. Ze organiseren zelf hoe ze gaan werken, niemand zegt hun hoe ze het werk omzetten in afgewerkte producten. Ze zijn cross-functioneel, ze hebben meestal verschillende skills nodig om één project te kunnen volbrengen. Er zijn geen titels voor de ontwikkelaars, alle leden in het development team zijn ontwikkelaars. Maakt niet uit wat ze doen in het development team. Er zijn geen sub-teams, of dat nu een tester bent, of een business analyses maakt, iedereen maakt deel uit van datzelfde team. Individuele teamleden zijn mogelijk gespecialiseerd in een bepaald domein, maar de verantwoordelijkheid van een project ligt bij het hele team. Je kan niet zeggen het is zijn schuld dat dit niet werkt. De scrum master is verantwoordelijk voor het in stand houden van de scrum werking. Hij is niet de baas van het team, maar helpt het team ook door afleiding weg te houden. Hij zorgt er bijvoorbeeld voor dat vragen van personen buiten het team niet bij het team zelf terecht komen. Of hij kondigt het stand-up moment aan, en hij is het contactpunt voor buitenstaanders.. Flexibiliteit Als er teveel afgeweken wordt van het doen tijdens een sprint, moeten er zo snel mogelijk aanpassingen gebeuren om te voorkomen dat er teveel afgeweken wordt. Er zijn verschillende manieren om de scrum aan te passen zodat er niet afgeweken wordt. Dit kan je doen door een van onderstaande zaken: Sprint Planning Planning die samen met de product owner en het team wordt afgesproken. Bevat wat er de komende sprint opgeleverd moet worden. Daily Scrum Rechtstaande meeting die maximum 15 minuten mag duren. Is dagelijks en het gemakkelijkste als die op hetzelfde moment en plaats is. We gaan het rijtje af en iedereen verteld wat ze gisteren gedaan hebben, wat ze vandaag gaan doen, en of er moeilijkheden waren. Op deze manier weet iedereen wat er gedaan is en wat er nog te doen is. Sprint Review Aan het einde van een sprint is er een stuk werkende software. Tijdens de sprint review tonen we wat we gemaakt hebben. Dit doen we vaak in de vorm van een demo. We gebruiken geen powerpoint en ook niet meer dan twee uur voorbereidingstijd. Iedereen is welkom, al is het zeker aan te raden dat de product owner en het scrum team aanwezig zijn. Sprint Retrospective Na de sprint review komt de sprint retrospective. Daar gaan we een start-stop-continue meeting houden die maximum een uur duurt. We proberen de volgende sprint vlotter te laten verlopen, hier zegt ieder teamlid wat we moeten starten te doen, stoppen te doen, en waarmee we verder moeten blijven doen. 10

11 Doorzichtigheid Het moet duidelijk zijn voor iedereen die betrokken is in het proces hoever we zijn, en waarmee we bezig zijn. We moeten elkaar kunnen verstaan en begrijpen. Zo weet je wie er met wat bezig is en bij wie jij moet zijn als je een vraag hebt, want soms moet je een waarde aan elkaar doorgeven, en moet de andere weten wat jij gaat geven, of moet jij weten wat hij verwacht. Ook moet duidelijk zijn voor iedereen wat de term van klaar is. Moet iets functioneel werken, of moet het er ook al heel erg mooi uitzien? Moet het enkel met dummy data werken of moet het al volledig met de echte live database werken? Inspecties De gebruikers van scrum moeten af en toe de scrum artefacten en de vooruitgang naar een sprint goal bekijken om te zien of er iets niet klopt. Deze inspecties moeten niet te vaak gebeuren, anders zorgen ze voor afleiding van het echte werk. Deze inspecties zijn wel het zinvolst wanneer de inspecteurs ook weten waar ze mee bezig mee zijn. 11

12 2. HOE SCRUM GEBRUIKEN? hoe moet je er als teamlid, bedrijfsleider, klant mee omgaan. Als we slim gebruik willen gaan maken van scrum moeten we toch met een paar dingen rekening houden. Als we een bestaand bedrijf zijn moeten we eerst en vooral blijven voortwerken op de oude manier. We gaan een klein projectje zoeken waarop we met het team scrum kunnen op proberen. Stap 1: product owner, scrum master & backlog Allereerst zoeken we een product owner. Deze persoon moet een paar dingen zeker kunnen. Hij moet de verantwoordelijk voor de prioriteiten van het project te kiezen. Hij moet weten wat verwacht wordt van het product. Hij moet goed kunnen communiceren over het project. Hij moet 100% voor het slagen van het product gaan, verwacht er dus maar veel tijd in het project te moeten steken. Als we deze persoon niet kunnen vinden, heeft het eigenlijk niet zo veel zin om verder te gaan met scrum uit te testen. De kans van falen is enorm groot zonder goede product owner. Als scrum master hebben we iemand nodig die heel goed weet hoe scrum werkt. De scrum master gaat het team coachen en leren hoe scrum werkt. Hij helpt hun ook door obstakels weg te houden van het team. Dan maken we de product backlog aan. Dit is een lijst van alles wat er moet gebeuren aan het project om het af te krijgen, belangrijkste onderdelen bovenaan. De product backlog kan bestaan uit features, verbeteringen, problemen die moeten opgelost worden, hele projecten, bugs, alles. Iedereen kan onderdelen toevoegen aan de product backlog, maar enkel de product owner kan de prioriteiten van de product backlog kiezen. Een probleem is dat het niet altijd duidelijk is hoe lang de backlog queue is, of hoeveel items er voor het item dat iemand graag gedaan wil hebben staan. Dit kan voor moeilijkheden zorgen. Een oplossing is om de scrum backlog duidelijk zichtbaar te maken. Een goede, fancy, oplossing is post its op de muur, en elke keer als iemand aan iets begonnen is, of afgewerkt heeft, moet hij die post it verplaatsen van de todo naar in progress naar done tabel. Een modernere versie kan natuurlijk ook, door de backlog op een tv te tonen of te projecteren op de muur. Stap 2: schat de benodigde tijd. Om een schatting te kunnen maken van wat er in 1 sprint zou passen moeten we een schatting kunnen maken van hoe lang elk onderdeel in de product backlog is. Als we hier een tijd op zouden plakken en ook al zeggen we dat het een ruwe schatting is, zullen we ooit commentaar krijgen als iets niet in die ruwe geschatte tijd af is. Om hier problemen te voorkomen kiezen we om gebruik te maken van een schaal. We kunnen kiezen voor een schaal van 1 op 21 volgens Fibonacci nummers. Als team bekijken we samen de product backlog en kiezen we het kleinste onderdeel dat we dan het nummer een geven. Samen bekijken we dan ook wat het grootste onderdeel van de backlog is en geven dat een 21. Nu hebben we een schaal en kunnen we samen de overige onderdelen op de product backlog overlopen en een punt geven. Wanneer we dit gedaan hebben vragen we de product owner om nog eens te kijken naar de prioriteiten. Als die ziet dat sommige onderdelen langer zouden duren volgens onze schatting kan hij 12

13 kiezen om de prioriteiten anders te leggen. Dit doen we zodat we ook vaak iets kunnen afleveren, en niet alle grote onderdelen samen in een sprint steken. Stap 3: sprint planning Nadat al het werk opgedeeld is, moeten we gaan beslissen hoe lang onze sprints zijn. Dit doen we samen met iedereen. Iedereen van het scrum team en de product owner. In onze allereerste sprint planning beslissen we hoe lang een sprint duurt. Dit beslissen we als een team en dit wordt niet meer aangepast totdat het we het project afgewerkt hebben. Scrum suggereert ons om 30 dagen te nemen. Dit is iets waar veel teams zich niet aan houden, wat op zich geen probleem is. De optimale sprint duur hangt af van veel factoren. Jonge teams hebben meer tijd nodig omdat ze niet gewend zijn aan de intensiteit van scrum en het werk rond sprints. Daarentegen zijn teams waar ze gebruik maken van geautomatiseerde testen sneller en kunnen hun sprints korter gemaakt worden. De periode schommelt tussen 1 week tot 1 maand. Nooit korter of langer, een week is echt kort, en een maand is te lang om nog te weten wat we aan het begin van een sprint gedaan hebben. Ook hangt het af voor welke markt we werken. Als we voor de snel veranderende web-gebaseerde markt werken, lijkt een maand een enorm lange periode. We kiezen over het algemeen voor de middenmaat, 2 weken. Dit is ook het gemakkelijkste in te plannen voor iedereen. We hebben namelijk na elke sprint een demo voor iedereen die wil komen kijken. Het maakt niet zo heel veel uit welke lengte we gekozen hebben voor onze sprints, we mogen de lengte van een sprint echt niet aanpassen. Dit haalt iedereen uit het ritme. Het is de herhaling van sprint op sprint die het team het inzicht geeft in het plannen van de sprint en hoeveel punten we uit de product backlog in 1 sprint kunnen afwerken. Nu we weten hoe lang een sprint duurt gaan we een target backlog maken. Deze target backlog houd alle onderdelen bij die we gedurende die sprint willen af krijgen. Dit doen we ook als een team. We gaan iets meer taken kiezen dan we denken aan te kunnen tijdens deze sprint. Deze taken noemen we duidelijk stretch taken. We doen dit in het geval dat het team vroeger klaar zou zijn dan gepland en we zeker niet met onze vingers zitten te draaien. Het moet ook heel duidelijk zijn naar de product owner dat hij niet moet verwachten dat deze onderdelen klaar zullen zijn. In komende sprints zullen we beter worden in het inschatten van de duur van onderdelen en zal de target backlog juister worden. Als we scrum nog maar net gebruiken zal het aantal punten dat we volbrengen per sprint heel hard schommelen. Dit stabiliseert naarmate we meer gewend geraken aan het scrum gebeuren. Voor de onderdelen op de product backlog is het ook belangrijk dat iedereen van het team goed weet hoe elk onderdeel er net uitziet en werkt. We overlopen gezamenlijk elk onderdeel stuk per stuk. De product owner legt een onderdeel eerst uit en verteld hoe hij het functioneel ziet. Dan stellen we in detail vragen om zeker te zijn van wat dat onderdeel zou moeten doen en hoe het zou moeten werken. De resultaten van deze discussie schrijven we ergens op, een whiteboard is ideaal omdat er ook tekeningen gemaakt kunnen worden. We kunnen gebruik maken van user stories, schetsen van looks of wireframes. Zo weten we al hoe iets eruit gaat zien en werken voordat we zelfs ook maar begonnen zijn aan het ontwikkelen. Stap 4: sprint planning (taken) Nu dat we de sprint ruw gepland hebben gaan we de sprint in detail plannen. Dit is een aparte meeting van de vorige meeting, en hier moet de product owner ook niet aanwezig op zijn. Hier gaan we hoogstwaarschijnlijk ook over meer technische dingen discussiëren. 13

14 We maken nu een sprint budget, dat is de tijd die we per sprint in het project kunnen steken. We kijken naar hoeveel uur de voltijdse en halftijdse teamleden erin kunnen steken. Uren die we verliezen aan feestdagen, vakantiedagen of meetings mogen we natuurlijk niet vergeten er af te trekken. Het resultaat hiervan maken we ook zichtbaar voor iedereen. Dan moeten we de requirements in de product backlog opdelen in taken. We mogen niet vergeten dat we een feature eerst nog moeten ontwerpen, schrijven, en dan minstens ook nog bug testen. Documentatie schrijven, testen met gebruikers. We mogen al die onderdelen in een scrum omgeving niet vergeten. Het testen gebeurd nu per feature per sprint, zodat we een onderdeel volledig af kunnen afleveren na een sprint. We spreken dan ook een definitie van klaar af. Zodat iedereen weet hoever we moeten staan bij het beëindigen van een sprint. We maken een schatting van hoe lang elke taak gaat duren. Als een taak langer dan een dag zou nemen moeten we proberen dit in kleinere taken op te splitsen. Dat is gemakkelijker om te schatten en hebben we iets te vertellen op de daily standup. Het is motiverend voor iedereen als we beweging zien in de taken. Nu gaan we kijken of de tijd die we hebben om in een sprint te steken ongeveer overeenkomt met de tijd die we nodig denken te hebben voor de taken. Als blijkt dat er een te groot verschil is moeten we taken uit de sprint backlog halen en voor latere sprints houden. We halen de taken met de laagste prioriteiten als eerste uit de sprint backlog, maar we houden nog steeds een aantal taken op overschot als stretch goals! Stap 5: werkplek Nu hebben we een leuke en gemakkelijkere stap, de werkplek. We hebben al een aantal keer gesproken over het zichtbaar maken van taken en processen. Omdat dit gemakkelijk te maken hangen we best zoveel mogelijk whiteboards tegen de muren. Zo kunnen we voor zichtbaarheid zorgen van belangrijke data, issues, of kunnen we snel schetsen maken moest het nodig zijn. We fleuren de werkplek zo ook op, iedereen kan er ideeën bij schrijven, het is allemaal mogelijk! De plaats waar we de whiteboards gehangen hebben is ook de ruimte waar we onze dagelijkse stand ups doen. Zo kunnen we gemakkelijk verwijzen naar dingen die al opgeschreven zijn, of notities opschrijven. Onze backlog onderdelen schrijven we op post its. Op een whiteboard maken we kolommen: todo, in progress, done en on hold. Als we een sprint starten, halen we de post its met de onderdelen die we plannen te doen van het product backlog bord en hangen we dat in de todo tabel van de sprint backlog, we sorteren volgens prioriteit. Als we met een taak starten, verplaatsen we die post it naar de in progress kolom en schrijven we onze naam erbij. Zo doen we geen dubbel werk en weten we bij wie we moeten zijn als we vragen hebben. Figuur 2: whiteboard bron: wikipedia Scrum (softwareontwikkelmethode) Het is heel erg motiverend om de todo kolom te zien leeglopen, en de done kolom vol. Er bestaan hier natuurlijk ook online tools voor als Trello, maar post its blijven een aanrader. 14

15 Stap 6: sprint! Eindelijk hebben we alles klaargezet: de werkplek is af, we weten wat de taken zijn, we kunnen starten! Nu toch nog een paar hele belangrijke gedachten. Het developersteam moet zelf verantwoordelijk voelen. We mogen zelf beslissingen nemen en daardoor is het meer ons product en zijn we erg gemotiveerd. Een manager die beslissingen voor het team neemt, is slecht voor de motivatie. Een manager moet het team helpen, door tips en tricks te geven, of door leden van het team op bijscholing te sturen. Een manager helpt het team, hij doet niet hun werk. De deadline staat vast, het einde van de sprint. We kunnen taken toevoegen als het echt moet, zoals het oplossen van bugfixes van een feature die er al in zat. Maar dan moeten we ook kijken of er andere features van de sprint backlog uit scope gezet kunnen worden, zodat we de deadline halen. Af is af. Omdat we werken met een vaste deadline moeten we zorgen dat we ook iets kunnen laten zien. Als we alles 90% af hebben, kunnen we niets laten zien. Het is beter dat we een paar dingen 100% af hebben. De klant heeft er niets aan als we zeggen dat er veel dingen bijna af zijn. Tijdens de sprint testen we onderdelen ook voordat we het als af beschouwen. Zo zijn we zeker dat alles goed werkt en we er later niet meer naar moeten kijken. In het beste scenario kunnen we als developers team werken zonder dat er iets veranderd aan de backlog of de prioriteiten. Als er constant veranderingen zijn weerhoud dat het team om productief te zijn en dat moeten we dus proberen te voorkomen. Als er echt prioriteiten moeten veranderen tijdens een sprint, is het zo, maar moet een even groot stuk werk uit de sprint worden gehaald om dat te compenseren. Dit zorgt voor langer werk omdat we die nieuwe prioriteiten moeten bespreken omdat we dat niet gedaan hadden tijdens de sprint planning. Een sprint zelf zou nooit afgebroken moeten worden. Het werk dat dan al gebeurd is, ben je gewoon kwijt. Natuurlijk is dat heel erg demotiverend. Stap 7: Stand up! Elke dag, op een vast uur, houden we een stand up. Dit is verplicht voor heel het team. We staan in een halve cirkel rond het whiteboard dat alles in verband met onze sprint inhoud. Elk teamlid verteld en wordt niet onderbroken. We vertellen wat we gisteren gedaan hebben, sinds onze laatste meeting. We vertellen wat we willen doen tegen morgenvroeg, onze volgende meeting. We vertellen als we tegenslagen hadden, wat deze waren. Als er korte vragen zijn kunnen we die daar stellen, maar lange technische vragen melden we even. Deze stellen we dan na de stand up. Leden die hier geen interesse aan hebben kunnen dan verder gaan werken. De scrum master is er om te zorgen dat we on topic blijven en dat de stand up elke dag word uitgevoerd. De scrum master moet niet alle obstakels persoonlijk oplossen, maar kan dat proberen te delegen. "Kan jij hem even uitleggen anders hoe jij dat doet?. De scrum master is verantwoordelijk om ervoor te zorgen dat alles obstakels genoemd zijn. We proberen de stand up dagelijks op hetzelfde uur te houden! 15

16 Stap 8: burn down chart Het kan soms moeilijk zijn om te zien hoe ver we al zitten in een sprint. Hoeveel onderdelen hebben we al afgewerkt, en hoeveel moeten we er nog doen? Zitten we op schema of niet? Een oplossing hiervoor is een burn down chart. Op deze manier kunnen we zien hoeveel taken er zijn, hoeveel we al gedaan hebben, en hoeveel er nog te gaan zijn. Aan de hand hiervan kunnen we ook schatten of we op het voorziene tijdstip gaan klaar geraken met al de onderdelen. Deze burn down chart kan een hele mooie motivatie zijn, iedereen ziet hoe dat het werk gedaan geraakt. Ook kunnen we hiermee problemen ontdekken. Het is beter dat we de problemen op tijd ontdekken zodat we er iets aan kunnen doen. Als een burn down chart niet gestaag zakt weten we dat taken langer nemen dan verwacht en dat we iets aan gaan moeten doen. Anders halen we de deadline niet. Op de burn down chart kan je ook notities met belangrijke momenten aanduiden. Dit helpt zodat we aan het einde van de sprint niets vergeten te vermelden of rekening mee te houden voor de volgende sprint. Als blijkt dat sommige onderdelen net veel meer tijd dan geschat nodig hebben, kunnen we de geschatte tijd voor de komende onderdelen die pas in de komende sprints komen, nog aanpassen. Stap 9: Afwerking Omdat de klok blijft tikken en we er niet altijd in slagen om alle onderdelen af te krijgen, is het heel belangrijk dat de onderdelen die we wel hebben in orde zijn. We kunnen niets doen met onderdelen die voor 80% af zijn. We kunnen een product waar 80% van de onderdelen 100% af zijn mogelijk wel uitbrengen. Om er in te slagen moeten we er voor zorgen dat alle code die we aan het schrijven zijn, omkeerbaar is. Dit doen we zodat je op elk moment kan afleveren. Het werk waar je aan bezig bent is dan niet mee opgeleverd, maar je product werkt wel zonder bugs. Je hebt alle vorige onderdelen namelijk voor de volle 100% afgewerkt. We houden de code proper want we kunnen niet achteraf nog gaan opkuisen. Dat wordt ook afgesproken in de definitie van klaar aan het begin van de scrum. Het kan dus gebeuren dat niet alles in het product zit dat we er in gingen steken, maar wat we al hebben is kwaliteitsvol en afleverbaar. Stap 10: herbekijken, verbeteren en opnieuw Herbekijken Op het einde van een sprint houden we een sprint meeting. Iedereen die wil komen kijken en iets met het project te maken heeft is welkom. Dit zijn ook de toekomstige gebruikers. We vertellen hier wat we gedaan hebben, maar nog belangrijker is een demo. Ook al werkt niet alles volledig, laat toch zien wat je die sprint gedaan hebt. Laat ook elk teamlid de stukken waar zij aan gewerkt hebben zelf voorstellen. We maken dus geen powerpoint van wat we gedaan hebben, maar laten de werkende stukken live zien. Er zijn 3 redenen waarom we dat op deze manier doen: 1. Het laat de team leden toe om te laten zien wat ze hebben behaald en wat hun inbreng in het product is. 2. Het geeft de kans aan de toeschouwers om te zien wat er gebeurd is, en om belangrijke feedback te geven op regelmatige basis. We hebben nog tijd om iets te doen met die feedback. 3. Het helpt het team om te focussen op de deadline. Niemand wil met lege handen op een demo komen. 16

17 Verbeteren Na de sprint review houden we een sprint retrospective meeting. Hier gaan we terug kijken op de voorbije sprint. Enkel de teamleden en de product owner zijn nuttig op deze meeting. De bedoeling van de sprint retrospective meeting is om de afgelopen sprint te bekijken en er uit te leren. Hoe ging het, konden we iets beter doen. Met het hele team bekijken we onderstaande zaken: Burndown chart: Hoe ging het? Hebben we kunnen afleveren wat we gepland hadden? Hoeveel uren hadden we tekort? We houden de overschot of tekort aan uren bij en duiden dat aan op een grafiekje. Zo kunnen we bijhouden of we beter worden in het schatten van de benodigde tijd voor onderdelen. Figuur 3: burndown chart bron: wikipedia Scrum (softwareontwikkelmethode) Teams snelheid: Hoeveel van de Fibonacci punten die we aan de taken hadden gegeven volbrengen we tijdens een sprint? Alleen van de taken die volledig af zijn doen we dat. We kunnen de volbrachte Fibonacci punten ook bijhouden en een grafiekje hiervan maken. Zo kunnen we zien hoe vlot het team taken volbrengt door de scrums heen. Wat ging goed: Bespreek wat goed ging, en hoe dat we dit de volgende scrums ook kunnen bereiken. Wat kon beter gaan: Probeer te begrijpen waarom sommige dingen niet zo vlot gingen. Wat doen we anders tijdens de volgende sprint: Aan de hand van de bovenstaande punten gaan we proberen om de volgende sprints vlotter te laten verlopen. Dit is een leerproces, elke sprint zal beter zijn als de vorige. Opnieuw We hebben nu een hele sprint overlopen, het team heeft nu belangrijke informatie over het product, over hun capaciteiten en over hoe we het ontwikkelproces sneller en beter kunnen laten verlopen. Het duurt een aantal sprints totdat het ritme er in zit en iedereen weet wat er verwacht wordt. De snelheid van het team moet ook nog stabiliseren en we leren beter hoe we moeten communiceren. Dit is hoe we scrum moeten gebruiken om het tot goed einde te brengen. 17

18 4. WAT GAAT ER MIS? Nu loopt het niet altijd van een leien dakje. Hieronder beschrijven we een aantal redenen hoe scrum kan mislukken. Scrum eens willen proberen, maar micromanagen Probleemstelling Een manager hoort dat scrum goede resultaten kan geven. Daarom gaat hij zich verdiepen in hoe volgens het scrum principe te werken. Hij stelt een team samen waarvan hij denkt dat die een project volgens het scrum principe kunnen volbrengen. Hij vertelde hen om dagelijks stands up te doen, hun werktijd in te schatten en elke maand versies van het product te maken. Omdat de manager het nog niet zo goed vertrouwt is hij elke ochtend bij de stand up. Hij let goed op en zegt wat het team goed aan het doen is, en wat niet. De stand ups worden een gewoonte maar al snel gaat het team geen slechte dingen meer vertellen. De manager wijst hen er altijd op en dat is niet motiverend. Het team heeft ook niet het gevoel dat het hun project is, ze worden gewezen op alles dat misloopt en beslissingen worden voor hun genomen. Hierdoor gaan ze zich niet meer gemotiveerd voelen en inzetten voor het project. Tip 1 Micro manage het team niet. Niemand vind het leuk als om gemanaged te worden. Doordat de manager het team op hun fouten wijst, is het bijna alsof hij over hun schouder staat mee te kijken. Veel mensen kunnen niet meer goed functioneren als er heel de tijd iemand zit mee te kijken. Geef het team hun vrijheid, geef ze hun eigen verantwoordelijkheid. Dat is de basis van scrum. Tip 2 Ondersteun het team, de manager mag dan wel weten hoe scrum werkt, gaat een team lid niet zomaar weten hoe scrum werkt door hem te zeggen dat hij dagelijkse standups moet doen. Ontdek het samen zodat iedereen leert hoe je scrum moet gebruiken. Tip 3 Als een team gemotiveerd is gaan ze zichzelf micro managen. Ze gaan elkaar sneller gaan helpen en praten met elkaar. Dit helpt de sfeer vooruit en het project nog meer. Gemotiveerde team leden gaan het hele project als van hun zien waardoor ze het willen dat alle onderdelen van het project in orde zijn waardoor ze elkaar dus in de positieve zin gaan helpen. 18

19 Zichzelf blijven overschatten Probleemstelling 1 Een team dat net begint met scrum te gebruiken en denkt dat ze zes items kunnen afwerken tijdens hun eerste sprint. Dat lukt hun niet, ze kunnen maar vier items afwerken en vallen dus kort. Nu is dat niet zo een groot probleem. De product owner weet ook dat het de eerste keer is dat het development team scrum gebruikt en dat hun productiviteit nog moet stijgen. Ook tijdens de tweede sprint denkt het development team dat ze zes items kunnen afwerken. Deze sprint slagen ze er toch maar in om vijf items af te werken. Sprint na sprint plannen ze meer items in dan ze kunnen afleveren. Dit ondermijnt het vertrouwen van de product owner in het development team. Daardoor krijgt het developers team minder kansen dan ze anders zouden hebben gekregen. Tip 1 Blijf jezelf niet overschatten. Als we merken dat we een sprint niet halen maken we de sprint backlog een beetje lichter. Elke week overuren kloppen om toch maar, helemaal uitgeput, er toch net niet te geraken heeft niet veel zin. Het team moet ook niet uitgeput geraken. Zomaar taken in het begin van de volgende sprint willen afwerken, stapelt zich op. Dat maakt het moeilijk voor de product owner om plannen te maken wanneer het product markt klaar zal zijn. We hebben beter een beetje tijd over tijdens een sprint, dan kunnen we al beginnen aan de stretch goals. Als die niet af geraken is er niemand rouwig om. En dat komt ook veel beter over naar de product owner op de demo. Hij krijgt dan wat hem beloofd was, en je kan al vertellen dat je zelfs net begonnen bent aan een komend stukje. Probleemstelling 2 We kunnen denken dat we genoeg budget en tijd hebben om het hele project, met alle features, toeters en bellen die de klant wil af krijgen. Daarom kunnen we denken dat het niet nodig is om te kijken naar welke onderdelen van het project er belangrijker zijn dan andere. We kunnen denken dat het niet belangrijk is om prioriteiten te geven aan deze onderdelen, in welke volgorde deze ontwikkeld moeten worden. Maar overschat dit niet, als we enkel een inlogscherm maken en daar vast komen te zitten, hebben we niet de hele website die daar achter kan zitten. Terwijl het gedeelte dat achter het inlog scherm kan zitten veel belangrijker is, omdat het de toekomstige gebruikers en betalende ondersteuning van het project kan overhalen. Bij een inlogscherm kunnen ze zich niets voorstellen, bij de website die er achter zit wel. Tip 2 Maak prioriteiten, wat is belangrijker om af te zijn als iets anders? Zorg dat we steeds iets hebben waarmee we naar buiten kunnen komen en mensen overtuigen over dat wij goed bezig zijn. Mensen gaan je niet geloven als je zegt dat je bijna klaar bent met het hele project en dat je enkel nog het zichtbare van het project moet maken. Leg je prioriteiten goed, zorg dat je iets hebt waarmee je mensen kan overtuigen dat je goed bezig bent, dat je ook de product owner kan overtuigen dat het team goed bezig is. Het oog wil ook wat, en dat is heel belangrijk in alle contexten. 19

20 Te grote teams Een groot project heeft ook veel mankracht nodig, er zijn een aantal manieren waarop dit mis kan lopen. Probleemstelling 1 We willen volgens het scrum principe elke dag een stand up houden met het hele team. Het enigste probleem hiermee is dat het enorm lang kan duren om met 40 man een stand up te houden. Eer dat iedereen aan de beurt is geweest zijn we veel te lang bezig om nog te weten wat de eerste verteld heeft. Ook gaan we gewoon niet meer gaan luisteren omdat we niet meer geïnteresseerd zijn of kunnen focussen. De communicatie tussen de verschillende mensen is veel te moeilijk. Na een tijd gaat de stand up ook maar een korte samenvatting worden van iedereen, zonder alles te overlopen wat we moeten overlopen in een stand up. Tip 1 Hou de teams klein, zo houden we de stand up kort maar gaan we toch alles kunnen overlopen dat we moeten overlopen tijdens een stand up. En iedereen gaat zich kunnen blijven focussen en opletten over wat iedereen zegt. Zo blijven we ook onthouden wie aan wat aan het werken was en bij wie we dus moeten zijn voor als we een vraag hebben. Probleemstelling 2 Als we dan toch in kleinere groepjes ingedeeld worden, hebben we de keuze om alle testers in een groepje te steken, alle ontwikkelaars in een groepje te steken en alles designers in een groepje te steken. Soort bij soort. We kunnen denken dat dat een erg goed idee is, voor vragen in verband met hun vakgebied kunnen ze snel bij elkaar terecht. Maar niets is minder waar. Als testers fouten ontdekken, mogen ze immers niet zomaar naar het ontwikkelaarsteam stappen en hun verhaal doen. Alles moet via de scrum masters gebeuren. Dit maakt de weg van de communicatie zoveel langer en maakt de kans groter dat er belangrijke stukken van het verhaal verloren gaan. Daarom tip 2. Tip 2 Houd de teams multidisciplinair. Als de uit de grote groep teamleden die we hebben groepen maken, wat op zich al goed is, moeten we de rollen niet per groep sorteren maar moeten we de rollen door elkaar gooien. Op deze manier kunnen we iets ontwikkelen en meteen testen. De tester kan op deze manier ook veel sneller feedback geven en kan de ontwikkelaar deze problemen sneller oplossen. De tester ka naar de ontwikkelaar gaan en zo kunnen ze samen het project besprek. Er moeten hier namelijk geen scrum masters tussen zitten wat de communicatie dus veel versneld en gemakkelijker maakt. 20

21 Product owner problemen De product owner moet goed weten waar het product naartoe moet zodat de gebruikers er blij mee gaan zijn. Hij geeft de richting van het project aan en kan het project dus heel gemakkelijk de foute richting in sturen. Een aantal manieren waarop de product owner de scrum aanpak kan doen falen. Probleemstelling 1 De product owner denkt dat hij weet hoe het product er uit moet zien. Hij denkt dat het product er uit moet zien zoals hij het ziet. Een grote fout hier is dat hij niet communiceert met de andere gebruikers. Het product gaat dan wel het droom product zijn voor de product owner, maar is dit ook het droom product voor de toekomstige gebruikers? Het is gemakkelijk voor de product owner om de feeling met de realiteit kwijt te geraken. Tip 1 Nodig voor elke demo, of toch zeker voor de demo s waar er een groot deel van het project is veranderd of bijgekomen, een aantal toekomstige gebruikers uit. Op deze manier krijg je ook feedback van mensen die niet het hele ontwikkelproces hebben mee gemaakt. Dit kan slechte feedback zijn, omdat ze vragen voor dingen die technisch niet mogelijk zijn of dat ze meer en meer willen. Maar, dit geeft meer goede dan slechte feedback. Het kan hem soms in de kleine details zitten, iets dat je project maakt of kraakt. En de feedback van deze gebruikers zet de product owner ook weer met beide voeten in de realiteit, in wat het product echt moet zijn. Probleemstelling 2 De product owner heeft een plan met hoe het product er uit moet zien en wil het ook zo plannen dat er verschillende features zijn, die hij het liefst allemaal apart laat ontwikkelen om dan op het einde pas samen te voegen. Het probleem hiermee is dat het veel moeilijker is dan de product owner denkt om deze verschillende onderdelen met elkaar te laten samenwerken. Als we plots moeten opleveren kunnen we eigenlijk niets opleveren want we hebben enkel een aantal onderdelen die op zichzelf niets waard zijn. Tip 2 Het scrum principe werkt met iteraties. We maken iets en breiden het uit. De plannen niet alle onderdelen apart te maken en daarna samen te brengen. In tegendeel, we beginnen met de basis, maken een lichaam, en geven het lichaam daarna een bovenbeen, daar hangen we een onderbeen aan en pas als laatste komen we bij de voet. Als we een lichaam en ledematen apart zouden ontwikkelen en pas op het einde samen zou hangen kan je heel lang bezig zijn met de onderdelen die daar tussen zitten. Als we dan plots zonder budget zitten kunnen we niet tonen wat we al hebben, want voor de buitenwereld is het niets waard. 21

22 Rollen uit elkaar houden Probleemstelling In een klein project hebben we niet genoeg mensen voor alle rollen. Om deze reden beslist iemand om de scrum master en product owner te zijn, op hetzelfde moment. Het probleem hier is dat de product owner heel andere prioriteiten heeft dan de scum master. De product owner wil zoveel mogelijk uit het project halen op zo kort mogelijke tijd. De scrum master wil zijn team zo goed mogelijk laten functioneren voor een goede productiviteit. Het heeft niet veel zin om elke dag 10u te werken als je na 8u werken niets meer opbrengt. Tip Houd rollen gescheiden. De product owner moet zich bezig houden met wat hij wil, en heeft vaak gesprekken hierover met de scrum master. De scrum master houdt in zijn achterhoofd wat er mogelijk is de komende sprint. Als er een feestdag tussen zit, of een teamlid heeft voor vakantie gevraagd en is die sprint niet aanwezig, betekend dit dat er minder opgeleverd gaat kunnen worden. De scrum master weet dat er af en toe een beetje meer inzet van het team nodig is, en zal ze daar ook wel toe aanzetten om eens een dag over te werken. Maar als we het team elke week laten overwerken zal het ook niet lang duren voordat het team helemaal niets waard meer is. Het is dus zeker niet vreemd als er wrevels zijn tussen de product owner en de scrum master. De product owner wil altijd meer, de scrum master gaat proberen realistisch te zijn. Iets dat niet altijd zo gemakkelijk is omdat op het einde van de rit de product owner de scrum master en het team wel moet betalen. Maar als we dit volhouden is het resultaat op het einde van de rit iets waar iedereen tevreden mee kan zijn. Scrum aanpassen Het kan heel vreemd lijken dat je dagelijks moet rechtstaan en vertellen wat je de dag ervoor gedaan hebt en wat je vandaag gaat doen. Het kan vreemd lijken om elke 2 weken met een kleine verandering weer bij de klant en gebruikers te staan om te tonen wat je gedaan hebt. Het kan vreemd zijn om alles meteen te testen na het ontwikkelen en niet pas op het einde alles te testen. Probleemstelling 1 We denken dus dat er onderdelen zijn die we niet nodig hebben. We snappen scrum nog niet helemaal maar denken er toch genoeg van te weten om het aan te passen. Zo kunnen we verschillende onderdelen schrappen, zoals de dagelijkse stand up, want we zitten toch allemaal dicht bij elkaar en zouden de gesprekken die anderen voeren toch wel moeten horen. Tip 1 Als we nog nooit scrum hebben gedaan, is het ook niet zo slim om meteen te beginnen met het proces aan te passen. We weten nog niet wat er goed is, en waarom dat een onderdeel in scrum zit. Hoe kunnen we dan eigenlijk weten of we het willen houden of niet? De eerste keer, keren, dat we scrum gebruiken moeten we dat doen zoals scrum het voorschrijft. Hou elke dag een stand up, hou een burn down chart bij, maak de processen visueel op white boards. Het kan de inzet van de groep zoveel hoger houden. Probleemstelling 2 Het is een nieuw project waar we aan beginnen en denken dat uitgebreid testen niet zo nodig is. We spreken wel af dat we aan elkaars code mogen zitten, en dat dit geen problemen zal geven aangezien de code vers in iedereen zijn geheugen zal zitten. 22

23 Hoe groot is de kans dat er iets misloopt? Tip 2 Een foutje is sneller gemaakt dan we beseffen. En net daarom dat we een onderdeel ook willen testen in dezelfde sprint als deze gemaakt is. Zo spelen we kort op de bal en weten we waar we het probleem moeten zoeken. Als we niet testen, en pas een paar sprints later ontdekken dat er iets niet werkt gaan we veel langer moeten zoeken naar waar het probleem zit, en dat haalt de productiviteit omlaag. Plus, we moeten rekening houden met dat een product schipping klaar moet zijn bij elke sprint, als er dus een fout in zit dat het hele product onbruikbaar kan maken zijn we dat liever kwijt dan rijk. De reden waarom we stukken code die we hebben geschreven ook snel moeten kunnen weg halen. Dit doen we aan de hand van versie beheer systemen. Op deze manier kunnen we snel terugspringen naar een versie die wel werkte. Dit is zeer handig als het misloopt net voordat we een demo moeten gaan geven. Zodat we toch een demo kunnen laten zien met iets dat werkt, dan iets dat niet werkt. 23

24 5. HOE MEER KANS MAKEN OP SLAGEN? In hoofdstuk 4 hebben we al een paar tips gegeven. Wat je in welke situatie moet doen, wat er misloopt. We gaan het hier nog even samenvatten. Allereerst moet iedereen die in het team zit weten hoe scrum werkt en wat er van hem verwacht wordt. Ook de manager komt aan bod, al is dat niet echt een rol in scrum. Maar laten we even rol per rol overlopen. Scrum master Je development team zijn mensen, gun hen rust. Leid je development team niet af met onnodige communicatie. Vang alle communicatie van de product owner op en filter. Durf neen te zeggen tegen de product owner. Vergeet de dagelijkse standup niet. Luister goed naar wat de leden van het development team vertellen. Hou het team in het oog, presteren ze goed, overschatten of onderschatten ze zichzelf niet. Durf Product owner Wees duidelijk in wat je wil. Wissel niet voortdurend van gedachten. Blijf geen features verzinnen als je de uiteindelijke deadline niet wil opschuiven. Houd er rekening mee dat niet elke sprint evenveel opbrengt. Niet alles wat er ontwikkeld is, is meteen zichtbaar. Developer Wees realistisch in je eigen kennen en kunnen. Durf communiceren met teamleden en de scrum master: o Durf technische vragen stellen aan de teamleden. o Durf vragen stellen aan de scrum master in verband met het product. o Durf de scrum master op de hoogte te brengen als er iets is dat je stoort bij het ontwikkelen. Houd er rekening mee dat je soms rust nodig hebt. Onderschat jezelf niet. Manager Laat het team met rust. Vertrouw in de scrum master. Laat ze tenminste 1 project vervolledigen en oordeel dan pas of scrum in gebruik blijft. Voor vragen contacteer de scrum master, niet het team. Volg het op maar geef geen instructies. 24