![\"\"](\"https:\/\/scrum-agile.nl\/wp-content\/uploads\/2019\/08\/evan.jpg\")
<\/figure>\n\n\n\nAls je kijkt naar de gedachten achter\ndit manifest, dan werkt het prima. Kijk je alleen naar deze regeltjes en pas je\ndie blind en rigide toe, dan kun je in onderstaande situaties terecht komen.<\/p>\n\n\n\n
Requirements zijn\noverbodig. We hebben een userstory en dat is voldoende.<\/em><\/strong><\/strong><\/p>\n\n\n\n \u201cAls je aan Scrum doet, is het schrijven\nvan requirements overbodig. Je stelt de userstory op en dat is genoeg om te\nbeginnen met ontwikkelen.\u201d Binnen Agile wordt gesproken over \u201cjust enough\u201d\nbeschrijven. Dit betekent echter niet dat je niets beschrijft. Een story is\naltijd het begin van een conversatie. Dat is het doel van de user story. Soms\nkan het voldoende zijn om op een hoog niveau de story op te stellen. Denk\nhierbij aan een eenvoudige aanpassing zoals het verplaatsen van een button in\neen scherm. De functionaliteit van de button blijft gelijk alleen de plaats\nwordt anders. Op zo\u2019n moment is een printscreen met daarin aangegeven wat de\nnieuwe locatie van de button wordt voldoende.<\/p>\n\n\n\n Echter als een story onderdeel is van\neen epic, zal er een overall view moeten zijn wat het doel is van de epic. Het\nis wenselijk om te beschrijven welke afhankelijkheden er zijn. Denk hierbij aan\nnoodzakelijke volgorde van ontwikkeling. Als er een story is voor het inlezen\nvan data en een story voor het verwerken van deze data, is het handig om eerst\nin te lezen en daarna de verwerking te realiseren. Als het hier data van een\nexterne partij betreft, wil je wel weten hoe die data eruit ziet die\naangeleverd wordt. Als het een XML betreft kan dit met behulp van een schema of\ndtd, maar er is wel een beschrijving van nodig. Een beschrijving als:<\/p>\n\n\n\n \u201cAls administratief medewerker wil ik de betaal\ngegevens die door Bank A als XML bestand aangeleverd worden in\nons financi\u00eble pakket kunnen inlezen zodat deze gegevens niet\nhandmatig ingevoerd dienen te worden.\u201d<\/em><\/p>\n\n\n\n is niet voldoende om te kunnen starten\nmet ontwikkelen. Ook omdat deze gegevens bij een latere story naar alle\nwaarschijnlijkheid nog gebruikt worden is het verstandig om ze in dit stadium\nal te beschrijven. En zo zijn er meer zaken die handig zijn om nu al uitgezocht\n\/ bekend te hebben voordat er ontwikkeld gaat worden.<\/p>\n\n\n\n Let wel, niet het hele traject hoeft nog\nin detail bekend te zijn. Ook kan het zijn dat er nog zaken met stakeholders\nafgesproken moeten worden. Zolang de lege plekken maar gevuld zijn op het\nmoment dat er met de ontwikkeling van dat stuk gestart wordt.<\/p>\n\n\n\n Een hulpmiddel om te zien of iets klaar\nis, is de Definition of Ready (D.O.R.). Hierin beschrijft het team wat zij aan\ngegevens nodig hebben om te kunnen starten met een story. In de D.O.R. staat\nbeschreven tot welke niveau het \u201cWaarom\u201d, \u201cWat\u201d en \u201cHoe\u201d van de story\nbeschreven dient te worden om het op te kunnen pakken. De SCRUM master helpt\nhet team bij het proces van het opstellen van de D.O.R.. Dit ook om te\nvoorkomen dat de D.O.R. beperkt blijft tot Just Enough en niet tot een volledig\nuitgewerkt ontwerp.<\/p>\n\n\n\n Het doel van een sprint is ook niet om\nmeteen kant en klare software op te leveren. Het doel is werkbare software\nopleveren. Daarnaast zullen er altijd wensen blijven van gebruikers. Hoe\nuitgebreid je je ontwerp ook maakt.<\/p>\n\n\n\n Ook is het geen probleem dat er zaken\nnog besproken worden tijdens het traject als dingen niet volledig duidelijk\nzijn. Dit overleg kan met de Product Owner of met een Business Analist of\nFunctioneel Ontwerper. Dat hangt er vanaf welke afspraken er gemaakt zijn\nbinnen de organisatie. De Product Owner heeft altijd het laatste woord. De\nBusiness Analist of Funtioneel Ontwerper geven alleen invulling aan de visie\nvan de Product Owner.<\/p>\n\n\n\n Als ik een auto ga bouwen, wil je weten\nwat voor auto je gaat bouwen. Als ik een eenvoudige handkar maak, kan ik met\ntwee wielen en het nodige hout en wat vindingrijkheid toe om de kar te maken.\nEen auto daarentegen zal ik willen weten wat voor soort auto het wordt, hoe\ngroot wordt de auto, wat voor motor komt erin, etc.. Als je een grote pick-up\nwilt maken, moet je niet beginnen met een bodemplaat van een kleine stadsauto.\nAls je met de carrosserie komt bij de kleine bodemplaat, zou je eigenlijk\nweer opnieuw moeten beginnen met een nieuwe bodemplaat.<\/p>\n\n\n\n De beste vergelijking is te leggen met\nde bouw wereld. Als ik een schuur bouw weet ik dat ik aan een fundering die\nsterk genoeg is voor 1 bouwlaag voldoende heb. Het is over het algemeen niet\nnodig om te heien. Echter als ik een flat ga bouwen, moet ik meer weten. Het is\nvan belang dat ik weet hoeveel verdiepingen de flat wordt. Ik kan niet na het\nbouwen van de eerste verdieping er achter komen dat de boel gaat verzakken en\ndan alsnog de fundering aanbrengen. Het afbreken van de bouwlagen en dan\nopnieuw een fundering leggen en opnieuw opbouwen zou een te tijdrovend proces\nzijn. De kleur van de tegels in het trappenhuis hoeft nog niet bekend te zijn.\nDeze kan bepaald worden op het moment dat de tegelzetter de tegels gaat\nbestellen.<\/p>\n\n\n\n We schrijven geen\ndocumentatie. Zo gaat dat in scrum.<\/em><\/strong><\/strong><\/p>\n\n\n\n \u201cWorking software over\ncomprehensive documentation\u201d is een van de regels uit het Agile Manifest. Deze\nregel wordt vaak ge\u00efnterpreteerd als \u201cDocumentatie is niet nodig want we\nhebben werkende software\u201d. Documentatie hoeft niet uitgebreid te zijn maar er\ndient wel documentatie opgesteld te worden. Er zijn verschillende vormen van\ndocumentatie die hieronder vallen. Het ontwerp (functioneel en technisch),\nsoftware documentatie (wat is er gedaan en waarom) en\ngebruikers documentatie (hoe werkt de software). De reden waarom een\nontwerp \/ visie van belang is, is hierboven beschreven.<\/p>\n\n\n\n De voorkeur gaat uit naar werkende\nsoftware. Bij traditionele ontwikkelmethoden wordt de helft van de tijd besteed\naan het schrijven van documentatie. Deze tijd kan niet gebruikt worden om te\nontwikkelen. Hou bij het schrijven daarom in gedachten of het document\nbijdraagt aan de ontwikkeling van de software, nu of in de toekomst, of dat het\ndocument opgesteld wordt voor het (ronde) archief.<\/p>\n\n\n\n We werken goed samen\nmet de klant en daarom is een contract overbodig.<\/em><\/strong><\/strong><\/p>\n\n\n\n In een ideale wereld zou dit werken.\nEchter de wereld is niet altijd ideaal. Daarom is het van belang dat je ook\nafspraken maakt over wat je oplevert of welke inzet je levert. Je kunt deze\nafspraken ook Agile insteken. Denk hierbij aan het opdelen van de opdrachten in\nstories. Aan het einde van iedere sprint is de review waarbij de klant aanwezig\nis. De Product Owner geeft aan welke stories nog in de backlog staan en welke\nstories, gezien de velocitiy, er ongeveer in de volgende sprint opgenomen\nworden. De klant ziet dan hoeveel inspanning er nog nodig is om iets te\nrealiseren en hoeveel van het budget al gebruikt is. Op dat moment kan de klant\neen Go of No Go geven. Een Go betekent dat de volgende sprint opgepakt wordt,\neen No Go betekent dat het project gestopt wordt. Het restant van het budget\nkan dan bijvoorbeeld gedeeld worden en de klant behoudt 50% en de ontwikkelende\npartij behoudt 50% van het restbedrag. Een reden voor een No Go kan zijn dat er\nalleen nog functionaliteit ligt die niet, meer, belangrijk is of waarbij de\nontwikkelkosten niet in verhouding staan tot hetgeen de functionaliteit\ntoevoegt. De klant is op deze manier minder kwijt aan ontwikkelkosten. Dit\nzijn afspraken die je vooraf dient te maken.<\/p>\n\n\n\n Maar ook, hoe ga je om met wijzigingen\nin behoeften. Als een story niet meer hoeft maar daarvoor in de plaats komt een\nandere story. Of er komen aanvullende stories. Wanneer is een story Done. Er\nzijn genoeg gevallen bekend waar het goed was dat hierover vooraf afspraken\ngemaakt waren. Vertrouwen is heel belangrijk. Communicatie met je klant ook.\nMaar er kunnen altijd situaties zijn waar afspraken op papier prettig zijn.<\/p>\n\n\n\n We zijn Agile want we doen\nalles volgens het boekje.<\/em><\/strong><\/strong><\/p>\n\n\n\n Als bedrijf zijnde, zijn we Agile want\nwe doen alles volgens de regeltjes. Je komt steeds meer bedrijven tegen die\nzeggen dat ze volgens Agile werken want ze volgen het boekje op de letter.\nEchter houden ze dusdanig krampachtig vast aan deze regeltjes dat ze hierdoor\nniet meer flexibel zijn. Een voorbeeld hiervan is: er wordt in de sprint aan 1\ngrote story gewerkt door het hele team. Echter op dag 3 van de sprint van 2\nweken wordt duidelijk dat deze story door een plotselinge verandering in de\nmarkt eigenlijk overbodig is. Maar ja, de sprint staat vast en zo staat het in\nde regels dus we maken de sprint af. Terwijl je op zo\u2019n moment ook door de\nProduct Owner de sprint kan laten afbreken en het team gaat een nieuwe sprint\nbacklog opstellen.<\/p>\n\n\n\n Ook is het wel gebeurt dat het team de\nsprint backlog had afgewerkt. Alle stories waren Done. Heel mooi natuurlijk. Er\nwaren nog 3 dagen over tot het einde van de sprint. Ik zou best een Euro willen\nkrijgen voor de teams die op dat moment rustig \u201cmet hun armen over elkaar\u201d\nzitten te wachten totdat de sprint afgelopen is. Want volgens de regels zijn we\nklaar want we hebben alle punten verbrand. Terwijl ook de volgende sprint\nalvast voorbereid kan worden of er kan, in overleg met de Product Owner, een\nstory van de backlog opgepakt worden.<\/p>\n\n\n\n Binnen een Agile\nomgeving moet iedereen met scrum werken.<\/em><\/strong><\/strong><\/p>\n\n\n\n Scrum is geen doel, het is een middel.\nMaar maak als bedrijf wel een keuze !! Wil je als bedrijf Agile werken? Werk\ndan ook Agile en zeg niet alleen dat je Agile werkt terwijl je eigenlijk \u201cmini\nwatervalt\u201d. Als je als bedrijf Agile wilt werken, betekend dat niet dat je moet\nScrummen. Er zijn nog meer Agile manieren van werken die wellicht beter binnen\njullie organisatie passen. Ook kan er binnen het bedrijf op verschillende Agile\nmanier gewerkt worden als daar aanleiding voor is. Belangrijk is dat de keuze bewust\ngemaakt wordt en dat je de regels op een gezonde manier met gezond verstand\ntoepast. Daarom wil ik aan het Agile Manifest nog 1 regel toevoegen:<\/p>\n\n\n\n Agile en Scrum zijn hot en trending. Iedereen moet tegenwoordig volgens Scrum of op een andere manier Agile werken. Als een methode populair genoeg is, komen er vanzelf steeds meer mensen die zich expert noemen. Maar is dit altijd wel terecht? Is het rigide toepassen van de Scrum regels voldoende om jezelf expert te noemen? … <\/p>\n