Onderstaande blog is door gastschrijver Rogier den Dulk geschreven.
Als je werkt in een organisatie waar ontwikkeling traditioneel in projecten plaatsvindt is het niet ongebruikelijk om tegen een aantal hardnekkige misvattingen aan te lopen wat Scrum nu precies is. In dit artikel wil ik de 5 meest voorkomende misvattingen de revue laten passeren.
Deze misvattingen lijken soms onschuldig, maar ze leiden allemaal naar slecht Scrum, met als gevolg dat Scrum een slechte naam krijgt binnen een organisatie.
“We hebben Scrum geprobeerd, maar het werkte totaal niet voor ons…”
Als je iemand dat hoort zeggen is het een goede indicatie dat Scrum slecht is geïmplementeerd. Vaak genoeg zijn een of meerdere van de volgende misvattingen de oorzaak waarom Scrum niet werkt in de organisatie.
“Scrum is voor projecten”
Ondanks dat het waar is dat je Scrum kan gebruiken in projecten, is het belangrijk de realiseren dat Scrum is richt op de volledige product life-cycle en niet een deel ervan.
Het scrum uitsluitend te zien in kader van projecten legt ook een traditioneel productontwikkel-denken bloot, namelijk het revolutionair opleveren, in plaats van een evolutionair, op ervaring gebaseerde ontwikkeling van producten.
Daarnaast zijn projecten per definitie een tijdelijke organisatie structuur die wordt opgeheven zodra een project klaar is. Onderhoud wordt dan vaak overgeheveld naar een ander team, dat dan verantwoordelijk wordt gemaakt voor de operatie en problemen in productie op te lossen. Dit resulteert in een enorme verspilling van tijd en moeite om kennis en ervaring over te dragen van het ene team naar het andere, waar men vaak maar deels in slaagt.
Het is slimmer om teams toe te kennen aan een product, ze expert te maken van dat product en ze verantwoordelijk te maken voor onderhoud en doorontwikkeling gedurende de levenscyclus.
“De Scrum Master is de (project-) manager”
Omdat Scrum vaak wordt gezien in kader van projecten wordt de projectmanager rol vaak geprojecteerd op de Scrum Master. De verantwoordelijkheden van de traditionele projectmanager komen echter niet overeen met dat die van de Scrum Master. Een goede indicatie dat wanneer dit gebeurd, is wanneer van de Scrum Master wordt verwacht dat hij planning en voortgang moet bijhouden.
Alhoewel beide rollen zijn sterk gefocust op het process, is de projectmanager meer directief en verantwoordelijk voor productlevering, terwijl de Scrum master eerder een faciliterende coach is van een team dat zelf verantwoordlijk is voor productlevering, en zich meer richt op het bewaken van de kaders van het framework. De verantwoordelijkheden van het plannen, monitoren, en rapporteren van de resultaten wordt gedeeld door de product owner en het development team.
“De Product Owner is de manager van het team”
Deze misvatting komt vaak voort uit het feit dat de Product Owner de autoriteit is binnen het team op het gebied van wat moet worden gemaakt (en met welke prioriteit). Het is een makkelijke fout te begaan voor een traditionele organisatie om hem als “leidinggevende” te kenmerken, zeker als deze persoon oorspronkelijk de manager was van de developers.
Ondanks dat het waar is dat de Product Owner het mandaat heeft de (volgorde van) ontwikkelingen te bepalen, is er geen sprake van een hiërarchische positie binnen of macht over het team. Beide hebben hun eigen rol en verantwoordelijkheden binnen het Scrum team en het is goed erbij stil te staan dat de Product Owner deel uitmaakt van het team en er niet buiten of boven staat.
In praktijk hoort het Scrum team de manager te zijn van het team; zowel de Product Owner als het development team zijn verantwoordelijk voor hoe ze de belangen van de organisatie het beste kunnen dienen binnen hun eigen doelgebied.
“Scrum is een gereedschapskist”
Helaas kom ik deze misvatting te vaak tegen: “Scrum” implementaties waarbij een deel van het framework is gewijzigd of achterwege gelaten om beter aan de sluiten bij de (oude) organisatie. Voorbeelden hiervan zijn part-time Scrum, teams met meerdere Product Owners of (te kleine) teams die zijn opgeknipt over verschillende producten en/of stakeholders vanwege “resource verdeling”. Veel wordt hier voor gekozen om de organisatie niet te hoeven veranderen om beter aan te sluiten op een nieuwe manier van werken.
Ondanks dat Scrum heel veel zaken niet benoemd en makkelijk kan worden verrijkt met allerlei good practices, zijn de regels van het framework – de events, de artefacts en de rollen – niet optioneel. Alle elementen die Scrum vormen zorgen dat het werkt als geheel. Het deels inzetten van het framework staat gelijk aan de wielen of de motor verwijderen van een auto en vervolgens verwachten dat hij nog rijdt.
Wanneer je Scrum implementeert is er heel veel mogelijk binnen de kaders van het framework, maar de kaders zelf, zoals deze door de Scrum Guide worden bepaald, zijn heilig.
Mocht je om wat voor reden denken dat een adaptatie toch beter werkt in jouw situatie, zeg ik: leef je uit, maar noem het geen Scrum. Door een adaptatie Scrum te noemen wek je valse verwachtingen bij anderen en veroorzaak je potentieel verwarring.
“Je kan niet op langer termijn plannen met Scrum”
Als je iemand dit hoort zeggen dan weet je dat deze persoon een slachtoffer is, of een slachtoffer kent, van een slechte Scrum-implementatie.
Het idee dat je niet op langer termijn kan plannen met Scrum komt vaak voort dat alle items op de backlog potentieel onderhevig is aan verandering.
Ondanks dat dit waar is op story-niveau, is het strategische doel (wat men wil bereiken met het product) vrij stabiel. Wat verandert is de manier waarop het product de doelstellingen probeert te behalen, op basis van bewijs, ervaring, nieuwe inzichten en veranderende omstandigheden. Net als een kleurplaat staan de lijnen vast, maar het materiaal en de kleuren waarmee wordt gewerkt kunnen veranderen waar dat wenselijk is.
Ook kan een gebrek van het begrijpen van een product backlog een oorzaak zijn van de stelling dat je niet op langer termijn kan plannen met scrum. Het zichtbaar maken van de product backlog is niet voldoende; hij moet ook door iedereen worden begrepen. Dit in onderdeel van de transparantie dat Scrum beoogt te realiseren.
Een goede techniek die ken helpen bij het visualiseren van product roadmaps is story boarding. Met deze methode organiseer je een overzichtelijker beeld van de product visie zonder dat dit afdoet aan de flexibiliteit nodig om op veranderende omstandigheden in te kunnen springen.
Ten slotte, een vijftal punten die je nooit meer moet vergeten over Scrum:
- Scrum organiseert zichzelf rond het product en de product-levenscyclus;
- De Scrum Master is de facilitator van het proces en niet van de uitkomst;
- Het Scrum Team is een zelf-organiserende en zelf-sturende entiteit, waar de Product Owner deel van uitmaakt;
- Scrum werkt als één geheel en je kan verwachten dat het niet meer werkt zodra je aan de kaders zit;
- Deel de productvisie met je stakeholders en neem ze mee op reis naar het einddoel.