23 jun

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 de 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. 

1. Denken dat de rol van PO gemakkelijk is

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, heb je ook nog een aantal verantwoordelijkheden: 

- Stakeholder management. Jij bepaald welke issues op de Product Backlog komen
- Je maakt keuzes, zodat het development team aan de slag kan
- Je bent verantwoordelijk voor het succes van het opgeleverde product

Lijkt het je wat om deze rol aan te nemen? Kom dan eens naar onze Scrum-training, zodat je voorbereid bent.

2. Inzetten van meerdere Product Owners

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. 

3. Een Retrospective overslaan wegens tijdgebrek

Wat je regelmatig ziet gebeuren bij organisatie is het overslaan van een Retrospective. Het wordt gezien als een saaie en zinloze meeting die weinig oplevert. Het wordt gemakkelijk gecanceld als het druk is. Als je stopt met de Retrospective, ontneem je jezelf en het team een mogelijkheid om de totale productie 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 Sprint 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 Sprint Retrospective het gevoel dat je met elkaar daadwerkelijk aan de slag kan. 

3. Organiseer een keer een Retrospective Sprint op een andere locatie
Wanneer je merkt dat de Sprint 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. 

4. Haal niet alle technische risico's naar voren

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. 

5. Je eindgebruiker niet bij het proces betrekken

Bij Scrum ga je er vanuit 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.  

6. Het 'Waarom?' niet toetsen

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? 

7. De Sprint Demo meeting gebruiken als acceptatiemoment voor de PO

Wat je weleens ziet gebeuren, is dat de Sprint Demo 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 demo is bedoeld om te kijken wat er bereikt is gedurende de Sprint. Op basis van deze bevindingen wordt er gekeken hoe 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 tijdens de sprint. De Demo 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. 

8. Lange daily stand-up

Van een lange daily stand-up wordt niemand blij. Zorg er daarom voor dat je stand-up maximaal 5 á 10 minuten duurt. Hoe je hiervoor zorgt? Door met elkaar te gaan staan. Het is namelijk bewezen dat je op deze manier effectiever communiceert. Behandel tijdens de daily stand-up alleen de volgende vragen:

  1. Wat heb je sinds de laatste stand-up gedaan?
  2. Wat ga je tot de volgende stand-up 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 stand-up ook maximaal 10 minuten duurt. Ook moet de Scrum-master ervoor zorgen dat er elke dag een stand-up plaats vindt. Het team is natuurlijk zelf verantwoordelijk voor de uitvoering ervan. Beschouw de Scrum Master niet als een projectleider. De stand-up is niet voor hem bedoelt, maar juist voor het team. 

9. Tijdens sprints de sprint backlog aanpassen

De backlog is de ruggengraat van Scrum. Het is een to do list die uitgevoerd moet worden. De backlog wordt vastgesteld tijdens de sprint planning meeting en wordt met het gehele Scrum Team vastgesteld. 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 al opgenomen. Is dit niet het geval, dan moeten de nieuwe prioriteiten meegenomen worden in de volgende backlog. Het is zeer af te raden om de 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).

10. Scrum te implementeren zonder de bedrijfscultuur, managementstijl en projectmethode te veranderen

Het is té 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 de scrum methodiek toe te passen en dat er vertrouwen is in deze methode. 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 is dus een iets andere manier van denken. Voor sommige organisaties betekent dit wellicht een cultuurverandering. Als iedereen het snapt en het ermee eens is, dan is het er zeker een die de moeite meer dan waard zal 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.

Conclusie

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.

Geschreven door:

  • Manon van de Laar

    Scrum master