De 10 Scrum mythes

Scrum is bedoeld als een simpel, maar efficiënt framework voor het opleveren van complexe producten. Zie het niet als een one-size-fits-all oplossing, een directe uitkomst van een probleem of complete methodologie. In plaats daarvan verschaft Scrum de grenzen waarbinnen teams zelf-organiserend kunnen zijn om een probleem op te lossen vanuit een empirische benadering. Deze eenvoud is een grote kracht binnen Scrum, maar tegelijkertijd ook een bron van verkeerde interpretaties en mythes rond deze methodiek. In deze blog worden 10 mythes binnen Scrum behandeld.

1. De Product Owner is de proxy voor stakeholders
Momenteel communiceert slechts de Product Owner met alle stakeholders, zoals de klant. Uiteindelijk zorgt dit ervoor dat Scrum teams een stuk minder Agile worden, terwijl deze wendbaarheid juist is waar de Agile Scrum methodiek voor staat. Vanuit het oogpunt dat Scrum een proces is van collaboratieve ontdekking, is het aan te bevelen de Product Owner niet als volmacht te zien, maar als een persoon die verantwoordelijk is voor de taak stakeholders in het gesprek te betrekken.

Leer meer over de Product Owner in onze animatie video.

2. De Sprint Backlog kan niet gewijzigd worden tijdens een sprint
Hoewel het doel van een bepaalde sprint vast staat, is het een mythe dat de Sprint Backlog ongewijzigd moet blijven tijdens een sprint. Het flexibele karakter van de Sprint Backlog zou omarmd moeten worden, onder de voorwaarde dat veranderingen in de backlog effect hebben op de focus van het Development Team, waarbij het sprintdoel het belangrijkste focuspunt is.

3. Oplevering van een product of dienst gebeurt slechts aan het einde van een sprint
Ondanks dat de mythe veronderstelt dat producten aan het einde van een sprint opgeleverd dienen te worden, zet het Scrum Framework juist aan tot het verbeteren van het werkproces, de infrastructuur en werkwijzen waarbij opleveringen ook tijdens de sprint kunnen plaatsvinden. Dit vergroot de kwaliteit van de feedback van het empirische proces dat Scrum probeert te implementeren.

4. De Scrum Master moet elk probleem oplossen
De mythe luidt dat de Scrum Master ieder probleem moet oplossen waar het Development Team, tijdens het behalen van het sprintdoel, tegenaan loopt. In plaats daarvan zou de Scrum Master het team moeten helpen in staat te zijn soortgelijke problemen zelf op te lossen, daar het Development Team zelf-organiserend is. De Scrum Master kan dit bewerkstelligen door zich niet te richten op ieder probleem dat zich voordoet, maar slechts de focus te leggen op problemen die het algemene werkproces van het team vertragen. Daarbij geldt: “Een Scrum Master zou een probleem aan het licht moeten brengen, niet oplossen.”

5. Story Points zijn verplicht in Scrum
De mythe luidt dat in Scrum alle taken moeten worden ingeschat op basis van tijd door middel van het toewijzen van Story Points. Vaak gaat het mis wanneer teamleden het inschatten van Story Points als een doel op zich gaan zien. Ondanks dat het een handige techniek is, gebruikt door vele Scrum teams, is het in geen geval de enige techniek.

Een belangrijk inzicht is dat accurate inschattingen vrijwel onmogelijk zijn; tijdens het werkproces kan het Scrum team in onverwachte situaties terecht komen, wat veranderingen in de huidige Story Point teweeg brengt.

6. De Product Backlog moet bestaan uit User Stories
Ondanks dat het geen voorwaarde is dat de Product Backlog volledig moet bestaan uit User Stories, zijn User Stories onmisbaar en een belangrijk onderdeel van Scrum. Ze zijn een goede techniek om de functionele voorwaarden van een product vast te leggen, zodat duidelijk wordt wanneer een taak op een bepaald moment goed genoeg is. Tegelijkertijd blijft er ruimte voor conversatie tussen teamleden. Echter verplicht noch schrijft Scrum het opstellen van User Stories voor. Het is mogelijk andere technieken te gebruiken, mits deze de volgende drie zaken begunstigen:

• Ze maken de Product Backlog begrijpelijk voor het Scrum team en alle stakeholders.
• Het vereiste detailniveau behoort aan te sluiten bij de onzekerheid van de productontwikkeling.
• Ze zouden een voortdurende communicatie en conversatie moeten bevorderen tussen het Scrum team en de stakeholders, hier vallen ook de eindgebruikers onder.

7. De Scrum Master moet altijd aanwezig zijn tijdens de Daily Scrum
De mythe dat een Scrum Master fysiek aanwezig behoort te zijn bij een Daily Scrum is niet waar. Echter is het wel zo dat het tot het takenpakket van een Scrum Master behoort deze meeting in te plannen en het team daarvan op de hoogte te brengen. Het is daarna de verantwoordelijk van het team de meeting uit te voeren.

Leer meer over de Scrum Master in onze animatie video.

8. De Product Backlog is geprioriteerd
Door de Product Backlog als een geprioriteerde lijst neer te zetten, lijkt het alsof de taken op een vaste volgorde blijven staan. Hiermee wordt de actieve rol van een Product Owner beperkt. Deze persoon is verantwoordelijk voor het voortdurend (her)ordenen van de Product Backlog wanneer nieuwe inzichten en werkprocessen zich voordoen, zodat de waarde van een sprint wordt gemaximaliseerd. Er zijn namelijk ontelbaar veel factoren die een rol spelen in de potentiële volgorde waarop taken in de Product Backlog komen te staan, denk aan risico’s, kosten en zakelijke omstandigheden.

9. De Scrum Master is een Junior Agile Coach
Aangezien de meest effectieve veranderingen van binnenuit worden aangedreven, is de Scrum Master – die onderdeel is van het Scrum team – in een betere positie deze verandering te faciliteren dan een externe Agile Coach. Dit is in lijn met hoe de Scrum Guide de rol van Scrum Master heeft bedoeld.

Wanneer organisaties ervoor kiezen het empirische proces middels Scrum uit te voeren, zou er haast geen behoefte moeten zijn aan Agile Coaches. Daarentegen zouden Scrum Masters ingeschakeld en ondersteund moeten worden om het werkproces op alle levels van de organisatie te bevorderen. Als zij dit kunnen, én als zij dit doen, zouden er geen andere rollen nodig zijn organisaties te helpen waardevolle resultaten te genereren door middel van Scrum.

10. Binnen Scrum bestaat er geen planning
Hoewel de mythe ons vertelt dat Scrum geen planning kent, blijkt daarentegen dat er veel plannen worden gemaakt. Door de verscheidene Scrum Events worden nogal wat plannen gemaakt, deze worden uitgedrukt in onder andere de Product Backlog, Sprint Backlog en de Definition of Done. De plannen die gemaakt worden in Scrum zijn anders dan wat er traditioneel wordt verstaan onder plannen, waarbij wordt gedacht aan zware documenten die gedetailleerde beschrijvingen bevatten. In plaats daarvan wordt tijdens het plannen van een taak de focus gelegd op het creëren van een gedeelde verstandhouding over de volgende stap.

Belangrijk om in gedachten te houden: “Plannen zijn nuttig. Gedetailleerde plannen zijn tijdsverspilling.”

Vrij vertaald en gebaseerd op: A Summary of the 10 Scrum Myths, door Barry Overeem.

Meer weten over Scrum? Bekijk onze animatie.

Updates ontvangen van de laatste ontwikkelingen?
Onze Agile Coaches voorzien je één keer in de twee weken van een informatief artikel. Zo blijf je altijd op de hoogte van de nieuwste inzichten binnen Scrum. Schrijf je via onderstaand formulier gemakkelijk in en ontvang artikelen, fijne tips en templates.

Ook interessant:
Begrippen binnen Scrum
De Sprint Backlog
Scrum sprints

Vind je dit artikel interessant? Volg ons dan op LinkedIn en blijf op de hoogte van onze blogs.

Of deel deze blog in je netwerk.
[addtoany]