Scrum

Scrum is een framework voor teams om complexe systemen en producten te ontwikkelen.

---

De oorsprong van Scrum

Jeff Sutherland en Ken Schwaber presenteerden de eerste versie van Scrum op de OOPSLA'95 conferentie.

Jeff Sutherland vertelt: Ken Schwaber vertelt:

De essentie van Scrum is dat het ontwikkelteam zelfsturend is. Dit is voor veel organisaties een nieuw concept dat kan rekenen op weerstand. Dit artikel gaat hier op in.

Een woord vooraf

Scrum is ontstaan in de wereld van de software ontwikkeling, een moeilijk te plannen activiteit met een slechte reputatie voor de kostenontwikkeling en tijdige oplevering. Scrum wordt inmiddels ook toegepast buiten de softwareontwikkeling, juist daar waar de omgeving door competitie of politiek snel verandert en waar snel resultaten moeten worden geboekt tegen minimale risico's. Scrum is het meest populaire framework om de herziene waarden van het Agile Manifesto te verwezenlijken.

Om met Scrum de beloofde resultaten te bereiken in snelle time-to-market, minder risico, lagere kosten en niet te vergeten een grotere betrokkenheid en werkplezier van het uitvoerende team is het niet voldoende alleen de hieronder beschreven rollen toe te wijzen en de Scrum ceremonies toe te passen. Voor een optimaal resultaat moet de organisatie anders, agile, gaan denken. Niet de ceremonies van Scrum zijn bepalend voor het succes maar het consequent wegnemen van de organisatorische beperkingen waar de teams tegenaan lopen. Dit proces verloopt sneller als het top-down en met takt en geduld wordt gestuurd. The Agility Guide beschrijft een aanpak met een verander team. Dat dit proces niet makkelijk zal zijn beschrijft Ken Schwaber in Scrum is Hard and Disruptive.

Wat is Scrum

Scrum is een iteratief, incrementeel framework voor de ontwikkeling van een product of het management van een opdracht. Een Scrum project kan van start als de belangrijkste requirements in de vorm van user stories zijn vastgelegd in een product backlog. Een user story beschrijft het 'wat' en 'waarom' van een requirement en heeft als vorm:

Als <mijn rol in de organisatie> wil ik <het wat> zodat <het waarom>.

Het 'waarom' geeft de business value aan. Van de drie variabelen is alleen <het wat> open voor discussie. Het uitvoerende team heeft wellicht nog betere ideeën om het doel te bereiken. Een user story gaat altijd vergezeld van een 'definition of done'. Dat zijn de acceptatiecriteria. Dit kan een hele lijst zijn voorzien van voorbeelden.

Het maken van goede user stories vereist ervaring. De Scrum master helpt de product owner daarbij. Een goede user story voldoet aan de eisen samengevat in het INVEST acroniem dat staat voor Independent. Negotiable, Valuable, Estimable, Small en Testable. Zie dit artikel.

Scrum is geen uitgewerkte managementmethode zoals Prince2 en RUP met hun uitgebreide set van templates en check lists. Het gevaar bij deze methoden dat de projectmanager vooral bezig is met administratieve taken kent Scrum dan ook niet. In deze Scrum Reference Card wordt Scrum kort en bondig beschreven. Zie ook mijn Scrum Q&A met vragen en antwoorden over de invoering van Scrum.

De rollen

Er zijn drie rollen, de product owner, de Scrum master en het ontwikkelteam. Samen vormen zij het Scrum team:

• De project owner vertegenwoordigt de belanghebbenden en houdt een wensenlijst met user stories bij op volgorde van belang.
  
  Bovenstaande YouTube clip van Henrik Kniberg geeft goed weer voor welke uitdagingen de product owner staat. De rol van de product owner is de zwaarste van de drie: visie, onderhandelingsvaardigheid met de stakeholders en de durf om 'nee' te zeggen zijn vereiste eigenschappen.
• Het ontwikkelteam is verantwoordelijk voor de realisatie en bepaalt zelf welke items het van de de top van de product backlog in de volgende interatie zal realiseren.
• De Scrum master coached het team en zorgt er voor dat het team gefocust blijft op het doel en helpt blokkades (impediments) in de organisatie op te heffen.

De events of ceremonies

Na iedere iteratie, een 'sprint' van 2 tot 4 weken, wordt een productierijp product opgeleverd. Gedurende een sprint mag de product owner geen wijzigingen in de specificaties eisen. Bij de definitie van de volgende sprint is hij geheel vrij nieuwe prioriteiten te stellen en specificaties aan te passen. Een procedure voor 'change requests' is hiermee overbodig. De Scrum aanpak garandeert dat steeds aan de op dat moment meest relevante aspecten van de opdracht wordt gewerkt. Een Scrum project eindigt als de project owner met zijn achterban tevreden is met het resultaat.

De sprint planning meeting bestaat uit twee delen. In het eerste deel geeft de product owner een toelichting over zijn verwachtingen t.a.v. de top backlog items. Het team bepaalt, geheel zelfstandig, hoeveel backlog items zij in de volgende sprint wil realiseren. In het tweede deel bespreekt het team het globale ontwerp en bepaald welke activiteiten nodig zijn en in welke volgorde. De activiteiten worden als geeltjes op het planning bord gekleefd.

Aan het begin van iedere dag verzamelt het ontwikkelteam zich rond het planning bord voor de daily scrum of standup. Onder leiding van de scrum master beantwoord ieder teamlid drie vragen: wat realiseerde ik sinds de laatste standup om het doel van de sprint dichterbij te brengen, wat ben ik van plan vandaag te doen en wat zijn de obstakels die mij hinderen in de voortgang.

Al weken van te voren wordt de sprint review gepland. Iedereen is aanwezig inclusief de business vertegenwoordigers (opdrachtgever en eindgebruiker). De review gaat altijd door, ook als het ontwikkelteam er niet in is geslaagd alle doelstellingen te bereiken. Het team demonstreert wat af is en de product owner bepaalt of de oplevering voldoet aan de definition of done. Er is ruimte voor discussie, zeker als er tegenvallers waren waardoor voorgenomen opleveringen niet af zijn.

Na de sprint review neemt de scrum master zijn team even apart om te bespreken hoe de afgelopen sprint is gegaan. Tijdens deze sprint retrospective maakt het team een plan om de belangrijkste problemen in de huidige en volgende sprints het hoofd te bieden.

Voor een succesvolle sprint planning meeting is het nodig dat de product backlog is uitgewerkt in kleine behapbare user stories. Gedurende de backlog refinement gaat het team top down door de backlog om de user stories met de product owner door te nemen en de hoeveelheid werk in te schatten. Een user story die door het hele team begrepen wordt en is ingeschat krijgt de status ready. Alleen ready user stories kunnen in de volgende planning meeting geselecteerd worden voor realisatie. Niet de hele backlog hoeft te worden doorgenomen. Het is voldoende als er een ruime voorraad is voor de volgende sprint.

Onderstaand overzicht in ontleend aan de Scrum papers (ruim 200 pagina's). De Scrum primer is met 20 pagina's wat beknopter.

De 'artefacts'

Scrum kent een aantal documenten die voor iedereen zichtbaar zijn en voortdurend worden aamgepast. De project owner is eigenaar van de product backlog. Hij bepaalt met de stakeholders welke user stories de hoogste prioriteit hebben. De sprint backlog omvat de activiteiten die het ontwikkelteam denkt te moeten uitvoeren om de doelstellingen voor de sprint te realiseren. Hiervoor wordt doorgaans een planning bord gebruikt waarop de activiteiten als stickers worden gekleefd en verplaatst als ze opgepakt worden en wanneer ze gereed zijn. Optioneel wordt in de sprint burndown chart bijgehouden voor welke user stories alle aktiviteiten volledig zijn afgerond. In één oogopslag kan iedereen zien of de voortgang voldoende is om alle voorgenomen werk in de sprint af te krijgen. Voor korte sprints en kleine teams is dit overigens ook direct af te lezen van het planning bord. Optioneel houdt de Scrum master een impediment list bij met daarin de geconstateerde blokkades en de stand van de oplossing daarvan. Voor iedere user story in de backlog moet vastgelegd zijn wat de definition of done is. Dit zijn de functionele, niet-functionele acceptatiecriteria en de QA standaarden waaraan voldaan moet worden. Voor de meeste user stories is die definitie grotendeels het zelfde. Het is dan ook handig om per project het generieke deel van de definition of done vast te leggen.

De impact op de organisatie

Iedere dag vraagt de Scrum master de teamleden niet alleen om aan elkaar te vertellen wat ze de vorige dag hebben bereikt en wat ze deze dag denken te bereiken maar ook om aan te geven welke blokkades de voortgang hinderen. Veel problemen kunnen door het team worden opgelost of omzeild. Wat overblijft zijn beperkingen door de organisatie. De Scum master zal de obstakels in volgorde van impact voor de voortgang met het management bespreken en zo mogelijk aanpakken. Het is aan de organisatie om haar commitment waar te maken en de gevonden opstakels op te ruimen.

Wanneer geen Scrum

Scrum is bedoeld voor risicovolle, complexe en grote projecten. Kleine kortdurende aanpassingen, projecten met weinig stakeholders en rotsvaste requirements kunnen als vanouds prima met de watervalmethode worden gerealiseerd. Betreft het project een vervanging van een systeem dat onmogelijk in stappen kan worden opgeleverd maar 'big bang' moet worden opgeleverd zonder de mogelijkheid dit in een schaduwomgeving te laten 'groeien' dan is Scrum ook niet geschikt. Alleen het gebruik van een planning bord en de dagelijkse stand-up blijft zinvol, maar is geen Scrum, want niet incrementeel noch iteratief. Het blijft een waterval project met bijbehorende risico's.

Scrum documentatie

De regels voor Scrum zijn hier (2011) en hier (2013) beschreven. In dit begeleidend schrijven van 2011 wordt nadrukkelijk een onderscheid gemaakt tussen de regels van het spel, naar analogie met het schaakspel, en de toegepaste strategie. Interessant is te zien dat regels opnieuw zijn aangescherpt in de update van 2013. De 2016 versie Scrum Guide 2016 geeft aandacht aan de Scrum waarden. In het persbericht van scrum.org over de update schrijft Ken Schwaber: "When the values of Commitment, Courage, Focus, Openness, and Respect are embodied and lived by the scrum team, the agile pillars of Transparency, Inspection and Adaptation come to life. We added these values to The Scrum Guide because successful use of scrum depends on people becoming more proficient in living these five values." De meest recente versie is de Scrum guide 2020. Interessant zijn de veranderingen die de auteurs in de loop van de tijd hebben aangebracht.

Scrum verbetert de organisatie

Wat doet de Scrum master als hij niet bezig is met het ondersteunen van de product owner of het faciliteren van de Scrum meetings? Een hoofdtaak van de Scrum master is om impediments samen met het management op te lossen. Hij overlegt met andere Scrum masters om de gemeenschappelijk en meest dringende veranderingen als eerste onder de aandacht van het management te brengen. Dit is een bottom-up aanpak en niet altijd de meest effectieve. Een door de top geleide 'task force' die met Scrum de aangeleverde impediments structureel oplost is vaak effectiever.

Scrum in de praktijk

Uit een onderzoek van Forrester Research blijkt dat grote organisaties veelal een Water-Scrum-Fall mix van Scrum en de Waterfall aanpak kiezen.

Let op de aanbeving uit dit onderzoek:

This model is not inherently bad, and it does at least afford some level of agility at the development-team level, but if application development professionals want to maximize the value of agility, they should:

• Push back on the water-Scrum side of the model. Spending too much time upfront will not increase the quality of the release; on the contrary, it is wasteful. Documents are a poor proxy for working software, and thus any documents created should be just enough to introduce the problem area and allow high-level planning and development work to commence.
• Ensure they have built a truly Agile team for the middle of the process. Just calling a team Agile is not enough; Agile teams should include all the people necessary to deliver working software, coupled with clear measures that allow the team to focus on delivering the right software that maximizes business value.
• Increase the frequency of the releases to production. Application development professionals should challenge the status quo of infrequent releases and push to better integrate release processes into the development team.

Organisaties die voortdurend Scrum teams optuigen om projectmatig deeloplossingen te realiseren dienen zich af te vragen of zij niet beter af zijn met de introductie van langlevende feature teams. Deze stelling wordt ondersteund door dit Scrum pattern.

Scrum certificering

Er zijn nu twee instanties die Scrum developers, masters, product owners en trainers opleiden, de Scrum Alliance en Scrum.org. Hier legt Ken Schwaber uit waarom hij Scrum.org heeft opgericht.

Zie ook de valkuilen van Scrum.
Zie ook mijn Scrum Q&A