10 dingen die je niet moet doen tijdens Scrum

Scrum, bijna iedereen heeft er wel van gehoord. Het is dan ook niet gek dat steeds meer bedrijven starten met Scrum om te experimenteren. Sommige bedrijven denken al snel dat het Scrum framework niet past bij hun bedrijf en stoppen ermee. Helaas heeft dit vaak te maken met een verkeerde aanpak. Werken met Scrum is namelijk niet gemakkelijk en vraagt om een goede aanpak. Wij behandelen in deze blogpost 10 fouten die vaak gemaakt worden. Uiteraard vertellen we je ook wat je wel moet doen. 

Een grote fout is denken dat je de wel 'even' de rol van Product Owner (PO) aanneemt. Deze rol vervul je niet zomaar. Het is bijna een fulltime baan. Naast dat het veel tijd kost, vervul je meerdere rollen en heb je bepaalde karakter eigenschappen nodig. 

• Stakeholder management. Je moet met belanghebbende praten. Waar hebben de gebruikers behoefte aan? 
• Besluitvaardig zijn is belangrijk. Je bepaalt welke issues er op de Product Backlog komen. Soms moet je dus ook 'nee' zeggen. 
• Om besluiten mogen te nemen is mandaat belangrijk. 
• Je bent verantwoordelijk voor het succes van het opgeleverde product.

Een absolute don't is het inzetten van meerdere Product Owners (PO's). Misschien lijkt het slim, omdat je je dan ook nog op andere werkzaamheden kunt focussen, maar uiteindelijk snijd je jezelf hiermee in de vingers. Wanneer je met meerdere PO's gaat werken, creëer je verwarring en verlies je het totale overzicht. Omdat elke PO zijn eigen manier van werken heeft, krijg je steeds meer discussies en ben je niet meer efficiënt aan het werk. Er hoort daarom maar één PO te zijn, die precies weet wat er speelt, zorgt voor afstemming met diverse partijen en zo de juiste beslissingen kan nemen. 

Wat je regelmatig ziet gebeuren is het overslaan van een Retrospective. Het wordt gezien als een saaie en zinloze meeting die weinig oplevert. Het gevolg hiervan is dat het gemakkelijk gecanceld wordt als het druk is. Het gevaar wat men niet ziet, is dat je op dat moment het team niet de mogelijkheid biedt om te verbeteren. Tijdens de Retrospective komt namelijk het hele Scrum Team (Product Owner, Scrum Master en developers) bij elkaar om te reflecteren op de afgelopen sprint. Samen bekijken ze wat er goed ging en welke verbeteringen aangebracht kunnen worden in de volgende sprint. Sla je de Retrospective over, dan snij je de continue improvement uit Scrum. Het is dus een noodzakelijke stap. We geven je drie tips die ervoor zorgen dat je de Retrospective niet meer overslaat:

1. Gebruik een andere techniek
Gebruik je altijd dezelfde Sprint Retrospective techniek? Dan kan het zijn dat de Retrospective saai wordt. Wissel af en toe eens van techniek. Heb je bijvoorbeeld de 'Starfish' al eens geprobeerd? Of de 'Sail Boat' of de 'Mad Sad Glad'?  https://waynedgrant.wordpress.com/2012/04/01/sprint-retrospective-techniques/

2. Kijk alleen naar verbeterpunten die haalbaar zijn
Wat je regelmatig ziet, is dat er veel verbeterpunten geopperd worden, waarvan maar 30% daadwerkelijk opgepakt kan worden. Het is daarom goed om echt alleen te kijken naar punten die haalbaar zijn. Er is altijd wel één verbetering te vinden die direct uitgevoerd kan worden. Focus daar met elkaar op. Op die manier houd je de meeting korter en heb je na de Retrospective het gevoel dat je met elkaar daadwerkelijk aan de slag kan. 

3. Organiseer een keer een Retrospective op een andere locatie
Wanneer je merkt dat de Retrospective eentonig begint te worden, kun je altijd besluiten om het een keer te organiseren op een andere locatie. Dit betekent niet dat je ergens ver van huis moet gaan. Je kan ook gewoon even naar buiten gaan, of de meeting in een andere ruimte plannen. De locatie bepaalt immers ook voor een deel de sfeer. 

De mens wil altijd alles beter, complexer en groter hebben. Dit zorgt ervoor dat we ons boerenverstand verliezen. Scrum helpt ons om logischer en helderder na te denken. In korte cycli sturen op een werkend product met maximale waarde, dat is waar Scrum om bekend staat. Zo lever je iedere sprint een werkend product op. Kies voor de meest simpele oplossing. Uitbreiden kan later altijd nog. Wanneer je wel een complexe vraag hebt, zorg er dan voor dat deze opgeknipt wordt in diverse fases. Op die manier splits je de technische risico's. Wat je ook nog kunt doen, is de risico's vooraf testen. Dit wordt ook wel Proof-Of-Concept (POC) genoemd. Het product wordt hierbij niet volledig uitgewerkt/gemaakt, maar er wordt alleen gekeken of het mogelijk is. 

Bij Scrum ga je ervan uit dat alles wat je doet, de grootste meerwaarde heeft voor je eindgebruiker. Het is daarom belangrijk om je eindgebruiker in het proces te betrekken. Je hebt immers geen glazen bol. Dit raakt de kern van het ontwikkeltraject. Wanneer je je eindgebruiker op afstand houdt, loop je de kans dat het ontwerp, functionaliteit en de interface van het eindproduct totaal niet aansluiten bij de wensen van deze gebruikers.  

Het is belangrijk om een Product Vision te maken. Een Product Vision is een soort elevator pitch van het product dat je gaat bouwen. Het beschrijft de aanleiding en de doelen van het te bouwen product. Het is dus belangrijk dat je dit als uitgangspunt gebruikt. Het is immer je antwoord op de vraag: "Waarom wil ik dit laten bouwen?".  Wanneer je een lastige keuze moet maken, kun je hier altijd naar terug grijpen. "Waarom doen we het ook al weer en sluit het aan bij mijn Product Vision Statement?". De Product Vision komt voort uit de volgende vragen:

• Waarom wil ik dit product?
• Waarom word ik daar blij van?
• Wat moet het teweeg brengen?
• Waar moet het aan bijdragen?
• Voor wie is het bedoeld?
• Wat is de concrete behoefte van de doelgroep?
• Wat gaan we ontwikkelen?
• Wat zijn de voordelen ervan?
• Wat wil ik juist niet?
• Wat maakt het onderscheidend? 

Wat je weleens ziet gebeuren, is dat de Review meeting gebruikt wordt om feedback te krijgen van de PO, met als gevolg dat er een hele to do list overblijft bij het afronden van de sprint. Dit is niet de bedoeling. Een review is bedoeld om te kijken wat er bereikt is gedurende de Sprint. Op basis van deze bevindingen wordt er gekeken hoe er nog meer waarde kan worden toegevoegd. Dit toetsen doe je met alle stakeholders die erbij betrokken zijn. De PO weet immers allang wat er speelt en wat er bereikt is gedurende de Sprint. Sterker nog, hij heeft zelfs akkoord gegeven en zijn feedback is als het goed is al verwerkt. De Review meeting moet draaien om de feedback van belanghebbenden. Het is dus belangrijk dat je juist aan hen om feedback vraagt, in plaats van aan de PO. 

Van een lange daily wordt niemand blij. Voor een daily staat een timebox van 15 minuten. Zorg dat iemand deze timebox in de gaten houdt. Vaak wordt de daily ook wel een daily stand-up genoemt. De naam is niet heel gek. Mensen gaan vaak tijdens een daily staan. Het is bewezen dat je op deze manier effectiever communiceert. Behandel tijdens de daily alleen de volgende vragen:

1. Wat heb je sinds de laatste daily gedaan?
2. Wat ga je tot de volgende daily doen?
3. Tegen welke knelpunten loop je aan? Of welke obstakels denk je tegen aan te gaan lopen? Kan het team je daarbij helpen?

Zorg ervoor dat er geen ruimte is voor andere discussies of gesprekken die niet werkgerelateerd zijn. De taak van de Scrum-master is om te zorgen dat dit niet gebeurd en dat de daily ook maximaal 15 minuten duurt. Ook moet de Scrum-master ervoor zorgen dat er elke dag een daily plaats vindt. Het team is natuurlijk zelf verantwoordelijk voor de uitvoering ervan. Beschouw de Scrum Master niet als een projectleider. De daily is niet voor hem bedoelt, maar juist voor het team. De Product Owner haakt alleen op uitnodiging van het team aan. 

Scrum kent twee belangrijke artefacten. De Product Backlog en de Sprint Backlog. De Product Backlog is een verzameling van alle to do's die zowel op korte als lange termijn uitgevoerd kunnen worden. De Sprint Backlog is een lijst met items die geselecteerd is uit de Product Backlog en tijdens de Sprint opgepakt moet worden. De Sprint backlog wordt, door het hele Scrum Team, vastgesteld tijdens de Sprint planning meeting. De PO is verantwoordelijk voor de prioriteiten van de backlog. In de backlog wordt antwoord gegeven op de vragen:

• Wat kan er worden opgeleverd aan het einde van de komende Sprint?
• Hoe gaan we het uitvoeren, zodat we het product aan het eind van de sprint kunnen opleveren?  

De backlog voor een sprint staat vast na de planningsmeeting. Als het goed is heeft de PO alle nodige prioriteiten opgenomen. Is dit niet het geval, dan moeten de nieuwe prioriteiten meegenomen worden in de volgende planningsmeeting. Het is zeer af te raden om de Sprint Backlog tijdens de sprint te veranderen. Hierdoor verliest het team focus en commitment. Daarnaast is dit slecht voor de productiviteit. De algemene Product backlog blijft uiteraard een dynamische backlog die altijd aangepast en geprioriteerd mag worden (refinement).

Het is te makkelijk gedacht dat je Scrum zomaar even introduceert in het bedrijf. Zie het als een zware kar die door meerdere personen getrokken moet worden. Met één persoon krijg je het niet voor elkaar. Het is van belang dat je er allereerst voor zorgt dat iedereen het ermee eens is om Scrum toe te passen en dat er vertrouwen is in dit framework. Het management moet erop vertrouwen dat de juiste mensen samen zullen zorgen voor de beste oplossingen. De medewerkers moeten de ruimte en mogelijkheden krijgen om zichzelf te ontplooien en mee te beslissen. Een deel van de besluitvorming komt iets lager in de organisatie te liggen. Het management houdt zich bezig met zaken die teams niet zelf kunnen oplossen. Scrum brengt dus een andere manier van denken met zich mee. Voor sommige organisaties betekent dit wellicht een cultuurverandering. Als iedereen het snapt en het ermee eens is, dan zal het zeker de moeite waard zijn.

Zie jij net als wij voordelen van Scrum, maar heb je je baas nog niet kunnen overtuigen? Lees dan eens onze blogpost. Zo overtuig jij gemakkelijk je baas.

Dit is een kleine greep uit de fouten die gemaakt worden tijdens Scrum. Heb je behoefte aan meer informatie over de Scrum methode? Neem dan eens contact met ons op.

MaxServ werkt al ruim 15 jaar aan het creëren van digitale oplossingen. We zijn gespecialiseerd in TYPO3en Magento 2 platformen waarmee we Digitale Meesterwerken creëren voor onze klanten. Lijkt het je leuk om bij ons te werken? Bekijk dan onze openstaande vacatures. Ben je op zoek naar een originele MaxServ? Neem dan contact met ons op.