Sinds het begin van 2010 ontwikkelen wij onze productlijnen met behulp van Scrum. Scrum is een iteratief incrementele methodologie voor agile software development… Mmm, begrijp je wat ik bedoel? Misschien wel, maar laat me uitleggen hoe wij en onze klanten profiteren van Scrum.
De kracht van Scrum is dat het continue focust op de snelst mogelijke levering van maximale business waarde. Door middel van het zo vroeg mogelijk in het ontwikkelproces ontvangen en verwerken van feedback, kunnen wij sneller reageren, zodat wij de kwaliteit, de inzichtelijkheid en de voorspelbaarheid van de ontwikkeling van onze software verbeteren. Dit geeft ons een ‘agile development process' waarin wij betere oplossingen kunnen leveren in een korter tijdsbestek.
Hoe?
Scrum bestaat uit praktische richtlijnen en vooraf gedefinieerde rollen. De belangrijkste rollen in Scrum zijn:
1. de Scrum Master, de facilitator. Een belangrijk onderdeel van de rol van de Scrum Master is om het Team te ‘beschermen' en hen gefocust te houden op de onderhanden taken.
2. de Product Owner, vertegenwoordigt de stem van de klant en de markt. Hij of zij zorgt ervoor dat het Scrum-team werkt aan de ‘juiste dingen' vanuit de business waarde van de klant.
3. Het Team heeft de verantwoordelijkheid het product te leveren. Een Team bestaat uit vijf tot negen personen met cross-functionele kennis en vaardigheden die het werk uitvoeren (ontwerp, ontwikkelen, testen, et cetera).
Tijdens elke ‘sprint' – wij gebruiken een periode van twee weken – creëert het Team een productverbetering (werkende, geteste software). De set van productverbeteringen die in een sprint terecht komen, komen van de ‘product back log', dat is een gepriotiseerde lijst met high level productverbeteringen die in het product gerealiseerd moeten worden. Welke productverbetering van de back log in de sprint terechtkomen, wordt bepaald tijdens de sprint planning. Tijdens deze bijeenkomst informeert de 'product owner' het 'Team' over de productverbeteringen in de product back log, die hij of zij wil ontwikkelen. Het Team bepaalt vervolgens hoeveel van deze productverbeteringen zij kunnen realiseren binnen de sprint, waaraan zij zich dan ook committeren. Tijdens een sprint mag niemand de sprint back log wijzigen, dat betekent dat de productverbeteringen voor die betreffende sprint vaststaan. Na de voltooiing van een sprint demonstreert het Team de werkende software aan de product owner en andere stakeholders.
Voordelen!
Een belangrijk voordeel van de Scrum aanpak is dat planning en de verbetering van het proces een continue herhalende activiteit is. Na elke sprint doet het Team een 'retrospective' door de beantwoording van drie simpele vragen: 'wat ging er goed en blijven we dus doen?', 'waarmee gaan we stoppen?' en 'waarmee gaan we starten?'. Net zo belangrijk is dat Scrum de toekomst bij de start van een project niet tot in detail probeert te voorspellen, maar erop is gericht om continue de schattingen op basis van ervaring te verbeteren en te verfijnen. Na elke sprint kun je de productiviteit van het Team bepalen en deze kennis gebruikt je om een meer accurate schatting te maken voor de volgende sprint. Bovendien doet het Team zelf de schattingen; het hele Team doet hier actief aan mee.
Dit heeft twee belangrijke voordelen. Ten eerste worden schattingen gebaseerd op de kennis en de visie van alle Teamleden en deze zijn daarom dus realistischer. Ten tweede committeert het gehele Team zich aan de schattingen, want ieder Teamlid moet instemmen met een schatting tijdens de planning.
Een ander belangrijk voordeel van Scrum is dat het altijd focus heeft op de ‘business waarde' van de klant. Een Scrum-team werkt altijd aan de op dat moment belangrijkste productverbeteringen, dus die met de hoogste business waarde. En omdat een Scrum-project aan het einde van elke sprint werkende software moet opleveren en de product owner bepaalt welke functionaliteit moet worden afgeleverd, is het niet mogelijk om problemen en moeilijke vraagstukken naar achteren te schuiven!
Door de centrale rol van het Team zien we de teams steeds meer zelfsturend opereren met een groeiende mate van empowerment. Ten slotte heeft de Scrum-aanpak een aantal financiële voordelen; Met Scrum kunnen belangrijke functionaliteiten snel in productie worden genomen. Het rendement op de investering is hoger, en de financiële gevolgen van een vertraging zijn kleiner. Dat is de kracht van scrum!
Mijn ervaring is dat scrum/agile zich voornamelijk richt op het bereiken van doelen op de korte termijn (door continue maximaal aan de business verwachtingen te voldoen). Voor snelle levering van software met een kote levensduur (zeg max 1 jaar), kan dit werken.
Voor andre projecten (de meeste anderen), heb je toch meer structuur, en een visie op ontwikkelgebied nodig, dan kan je niet per 2 weken iets werkends opleveren.
Soms moet je een ‘stap terug’ doen, of bijvoorbeeld nee zeggen, om langere termijn doelen veilig te stellen. Of iets vergt meer onderzoekstijd, dan in 2 weken gedaan kan worden.
Ik zou iedereen willen adviseren kritisch naar de toepasbaarheid van agile/scrum te willen kijken voordat men zich hieraan compromitteerd. (en niet zomaar blindelings aan deze ‘hype’ meedoen).
Ik zou scrum niet als een hype betitelen. Eerder een verfijning en een professionalisering van het productieproces van een relatief jonge industrie, die de software industrie feitelijk is. Scrum biedt een structuur om de alom bekende valkuilen van traditionele softwareproductie te omarmen en te minimaliseren.
Scrum biedt structuur en bestaat natuurlijk niet zonder een visie op het grotere geheel! Ik ben het ermee eens dat het onontkoombaar is dat men soms nee moet zeggen en soms een stap terug doet. Juist scrum faciliteert dat!
Mathijs: het klinkt alsof je geen echte agile projecten bent tegengekomen
Ik kom regelmatig projecten tegen, die claimen scrum te doen, maar het eigenlijk faken. De volgende twee problemen spelen dan:
– De product owner die zijn rol niet goed speelt.
– Een slechte definition of done.
De product owner moet een afweging maken tussen de belangen van alle stakeholders, en daarbij de lange termijn business value in de gaten houden, zonder de cash flow en korte termijn uit het oog te verliezen. Deze prioritisering is moeilijk.
Als features steeds maar opgeleverd worden zonder dat ze goed getest zijn en zonder dat het systeem goed gerefactored wordt, ontstaat op termijn een te grote technical debt. Het systeem wordt dan steeds moeilijker te onderhouden en het duurt steeds langer om nieuwe feature op te leveren met een acceptabel kwaliteitsniveau.
Ik kan me goed voorstellen dat je wat van dit soort projecten bent tegengekomen, en die worden inderdaad vaak na ongeveer een jaar geconfronteerd met de realiteit. De conclusie dat je meer structuur (je bedoelt meer werk vooraf en achteraf? Requirements, FO, TO, test documenten) en een visie op ontwikkelgebied (architectuur?) nodig hebt bij de meeste projecten, kun je hiermee echter niet onderbouwen.
Natuurlijk is het wel zo dat grotere projecten met een langere levensduur meer documentatie zullen moeten opleveren om informatie te kunnen overdragen, maar er is geen enkele reden om dat niet gewoon in de product backlog mee te nemen.
Juist bij grotere projecten is het iedere twee weken werkend blijven opleveren cruciaal. Ook grote refactorings en grotere onderzoeken kunnen in kleine stukjes worden opgeknipt, en het is van levensbelang voor een groot project om continu inzicht te verschaffen in de voortgang. Hoe wil je er anders aan sturen?
Hmmm. Deja-vu. RAD. Prototyping. Incrementeel ontwikkelen. Deden we 15 jaar geleden ook al. Niets nieuws onder de zon. De problemen die optreden zijn ook nog hetzelfde als ik het zo lees.
Misschien moet het UWV dit ook maar eens overwegen. ipv meer dan 100 miljoen uit te geven aan automatisering gewoon max. 9 werknemers de hele samenvoeging van de verschillende instanties en het programma van de uitkeringen op een scrum manier laten maken.
Volgens mij heb je wel iets van een masterplan nodig voor de grote lijnen. Wel een grote verantwoordelijkheid voor de productowner lijkt me.
Ik ben wel eens betrokken geweest bij het bouwen van een applicatie waarbij 40 mensen een jaar lang allemaal delen van software zaten te bouwen met als eindresultaat een werkend maar gebruikersonvriendelijk product. het FO was zo dik dat het ook niet meer te overzien was voor een gewoon mens. Uiteindelijk is het ook mislukt. Hiervoor zou scrum denk ik wel een verbetering zijn geweest.