{"id":45,"date":"2019-08-14T14:58:30","date_gmt":"2019-08-14T14:58:30","guid":{"rendered":"http:\/\/scrum-agile.nl\/?page_id=45"},"modified":"2019-08-15T10:43:09","modified_gmt":"2019-08-15T10:43:09","slug":"5-misvattingen-van-scrum","status":"publish","type":"page","link":"https:\/\/scrum-agile.nl\/?page_id=45","title":{"rendered":"5 Misvattingen van Scrum"},"content":{"rendered":"\n

Onderstaande blog is door gastschrijver Rogier den Dulk geschreven.<\/em><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

Deze misvattingen\nlijken soms onschuldig, maar ze leiden allemaal naar slecht Scrum, met als\ngevolg dat Scrum een slechte naam krijgt binnen een organisatie.<\/p>\n\n\n\n

\u201cWe hebben Scrum geprobeerd, maar het werkte totaal\nniet voor ons\u2026\u201d<\/em><\/p>\n\n\n\n

Als je iemand dat\nhoort zeggen is het een goede indicatie dat Scrum slecht is ge\u00efmplementeerd.\nVaak genoeg zijn een of meerdere van de volgende misvattingen de oorzaak\nwaarom Scrum niet werkt in de organisatie.<\/p>\n\n\n\n

\u201cScrum is voor projecten\u201d<\/em><\/p>\n\n\n\n

Ondanks dat het waar\nis dat je Scrum kan gebruiken in projecten, is het belangrijk de realiseren dat\nScrum is richt op de volledige product life-cycle en niet een deel ervan.<\/p>\n\n\n\n

Het scrum\nuitsluitend te zien in kader van projecten legt ook een traditioneel\nproductontwikkel-denken bloot, namelijk het revolutionair opleveren, in plaats\nvan een evolutionair, op ervaring gebaseerde ontwikkeling van producten.<\/p>\n\n\n\n

Daarnaast zijn\nprojecten per definitie een tijdelijke organisatie structuur die wordt\nopgeheven zodra een project klaar is. Onderhoud wordt dan vaak overgeheveld\nnaar een ander team, dat dan verantwoordelijk wordt gemaakt voor de operatie en\nproblemen in productie op te lossen. Dit resulteert in een enorme\nverspilling van tijd en moeite om kennis en ervaring over te dragen van het ene\nteam naar het andere, waar men vaak maar deels in slaagt.<\/p>\n\n\n\n

Het is slimmer om\nteams toe te kennen aan een product, ze expert te maken van dat\nproduct en ze verantwoordelijk te maken voor onderhoud en doorontwikkeling\ngedurende de levenscyclus.<\/p>\n\n\n\n

\u201cDe Scrum Master is de (project-) manager\u201d<\/em><\/p>\n\n\n\n

Omdat Scrum vaak wordt\ngezien in kader van projecten wordt de projectmanager rol vaak geprojecteerd op\nde Scrum Master. De verantwoordelijkheden van de traditionele projectmanager\nkomen echter niet overeen met dat die van de Scrum Master. Een goede indicatie\ndat wanneer dit gebeurd, is wanneer van de Scrum Master wordt verwacht dat hij\nplanning en voortgang moet bijhouden.<\/p>\n\n\n\n

Alhoewel beide rollen\nzijn sterk gefocust op het process, is de projectmanager meer directief en\nverantwoordelijk voor productlevering, terwijl de Scrum master eerder een\nfaciliterende coach is van een team dat zelf verantwoordlijk is voor\nproductlevering, en zich meer richt op het bewaken van de kaders van het\nframework. De verantwoordelijkheden van het plannen, monitoren, en\nrapporteren van de resultaten wordt gedeeld door de product owner en het\ndevelopment team.<\/p>\n\n\n\n

\u201cDe Product Owner is de manager van\nhet team\u201d<\/em><\/p>\n\n\n\n

Deze misvatting komt\nvaak voort uit het feit dat de Product Owner de autoriteit is binnen het team\nop het gebied van wat moet worden gemaakt (en met welke prioriteit). Het is een\nmakkelijke fout te begaan voor een traditionele organisatie om hem als\n\u201cleidinggevende\u201d te kenmerken, zeker als deze persoon oorspronkelijk de manager\nwas van de developers.<\/p>\n\n\n\n

Ondanks dat het waar\nis dat de Product Owner het mandaat heeft de (volgorde van) ontwikkelingen te\nbepalen, is er geen sprake van een hi\u00ebrarchische positie binnen of macht over\nhet team. Beide hebben hun eigen rol en verantwoordelijkheden binnen het Scrum\nteam en het is goed erbij stil te staan dat de Product Owner deel uitmaakt<\/em> van het team en er niet buiten of\nboven staat.<\/p>\n\n\n\n

In praktijk hoort het\nScrum team de manager te zijn van het team; zowel de Product Owner als het\ndevelopment team zijn verantwoordelijk voor hoe ze de belangen van de\norganisatie het beste kunnen dienen binnen hun eigen doelgebied.<\/p>\n\n\n\n

\u201cScrum is een gereedschapskist\u201d<\/em><\/p>\n\n\n\n

Helaas kom ik deze\nmisvatting te vaak tegen: \u201cScrum\u201d implementaties waarbij een deel van het\nframework is gewijzigd of achterwege gelaten om beter aan de sluiten bij de\n(oude) organisatie. Voorbeelden hiervan zijn part-time Scrum, teams met\nmeerdere Product Owners of (te kleine) teams die zijn opgeknipt over\nverschillende producten en\/of stakeholders vanwege \u201cresource verdeling\u201d. Veel\nwordt hier voor gekozen om de organisatie niet te hoeven veranderen om beter\naan te sluiten op een nieuwe manier van werken.<\/p>\n\n\n\n

Ondanks dat Scrum heel\nveel zaken niet benoemd en makkelijk kan worden verrijkt met allerlei good\npractices, zijn de regels van het framework \u2013 de events, de artefacts en de\nrollen \u2013 niet optioneel. Alle elementen die Scrum vormen zorgen dat het werkt\nals geheel. Het deels inzetten van het framework staat gelijk aan de wielen of\nde motor verwijderen van een auto en vervolgens verwachten dat hij nog rijdt.<\/p>\n\n\n\n

Wanneer je Scrum\nimplementeert is er heel veel mogelijk binnen de kaders van het framework, maar\nde kaders zelf, zoals deze door de Scrum Guide worden bepaald, zijn heilig.<\/p>\n\n\n\n

Mocht je om wat voor\nreden denken dat een adaptatie toch beter werkt in jouw situatie, zeg ik:\nleef je uit, maar noem het geen Scrum<\/em>. Door een adaptatie\nScrum te noemen wek je valse verwachtingen bij anderen en veroorzaak je\npotentieel verwarring.<\/p>\n\n\n\n

\u201cJe kan niet op langer termijn plannen met Scrum\u201d<\/em><\/p>\n\n\n\n

Als je iemand dit\nhoort zeggen dan weet je dat deze persoon een slachtoffer is, of een\nslachtoffer kent, van een slechte Scrum-implementatie.<\/p>\n\n\n\n

Het idee dat je niet\nop langer termijn kan plannen met Scrum komt vaak voort dat alle items op de\nbacklog potentieel onderhevig is aan verandering.<\/p>\n\n\n\n

Ondanks dat dit waar\nis op story-niveau, is het strategische doel (wat men wil bereiken met het\nproduct) vrij stabiel. Wat verandert is de manier waarop het product de\ndoelstellingen probeert te behalen, op basis van bewijs, ervaring, nieuwe\ninzichten en veranderende omstandigheden. Net als een kleurplaat staan de lijnen\nvast, maar het materiaal en de kleuren waarmee wordt gewerkt kunnen veranderen\nwaar dat wenselijk is.<\/p>\n\n\n\n

Ook kan een gebrek van\nhet begrijpen van een product backlog een oorzaak zijn van de stelling dat je\nniet op langer termijn kan plannen met scrum. Het zichtbaar maken van de\nproduct backlog is niet voldoende; hij moet ook door iedereen worden begrepen<\/em>. Dit in onderdeel van de transparantie dat\nScrum beoogt te realiseren.<\/p>\n\n\n\n

Een goede techniek die\nken helpen bij het visualiseren van product roadmaps is story boarding. Met\ndeze methode organiseer je een overzichtelijker beeld van de product\nvisie zonder dat dit afdoet aan de flexibiliteit nodig om op veranderende\nomstandigheden in te kunnen springen.<\/p>\n\n\n\n

\n\n\n\n

Ten slotte, een\nvijftal punten die je nooit meer moet vergeten over Scrum:<\/p>\n\n\n\n