Scrum is een framework wat voortkomt uit het Agile denken. Het is daarmee een vorm van Agile en dus geen op zichzelf staand gedachtegoed. Agile is een ontwikkelmethode die is gestoeld op een iteratieve en incrementele aanpak. Scrum past deze methode toe, met een incrementele manier van bouwen en leveren aan de klant elke twee of drie weken. De definitie en regels betreffende Scrum zijn samengevoegd in de zogenaamde Scrum guide. Opgesteld door de bedenkers van Scrum: Ken Schwaber en Jeff Sutherland (scrum.org).
Toch zijn er veel misvattingen over de regels zoals die in de Scrum guide te vinden zijn. En ook over hoe die toe te passen. Voorbeelden van die misvattingen betreffende de Scrum regels zoals (maar niet beperkt tot):
- de product owner mag niet aanwezig zijn bij Scrum meetings,
- voor het inschatten van Product Backlog items dient er altijd gebruik te worden gemaakt van storypoints en
- met Scrum is een planning vooraf niet nodig.
Generally Accepted Scrum Practices (GASPs)
Naast de regels zoals die in de Scrum-guide worden omschreven, zijn er ook andere middelen of tools die vaak in combinatie met het Scrum framework worden ingezet. Dit worden zogenaamde Generally Accepted Scrum Practices genoemd. Technisch gezien zijn ze geen onderdeel van het Scrum framework, maar worden ze wel vaak toegepast binnen een Scrum project.
Een voorbeeld van een GASP is het gebruik van User stories: “Als… Wil ik… Omdat..”. Hiermee krijg je een veel beter beeld wat je in een Scrum project in een Sprint (zoals een increment binnen Scrum wordt genoemd) probeert op te leveren aan werkende software voor de gebruikers. Het wordt veelvuldig gebruikt door Scrum teams, maar eigenlijk komt het niet voor in de Scrum guide. Zodoende is het een Generally Accepted Scrum Practice geworden. Zo zijn er nog veel meer GASPs die worden ingezet binnen Scrum teams.
Scrum binnen Enrise
Binnen Enrise werken we volgens verschillende Agile frameworks. Geregeld wordt hierbij gekozen voor Scrum. We volgen de regels van het Scrum framework, maar wijken daar ook vanaf of voegen onze eigen GASPs toe. We geven er onze eigen draai aan, met invloeden van o.a. Less en DevOps.
De keuze voor de inzet van verschillende nieuwe GASPs en de reflectie op de bruikbaarheid van GASPs die we al toepassen komen met name terug in onze Retrospectives. Een Retrospective vindt plaats na elke Sprint. Het team kijkt dan terug op de afgelopen Sprint om te reflecteren op: Wat ging er goed en wat kan er beter? Dit kan in veel verschillende vormen. Vaak wordt een GASP ingezet om iets op te pakken waar we in de Retrospective tegenaan zijn gelopen.
Praktijkvoorbeeld: De 3e lijns support voor een klant werd opgepakt door iedereen van een team. Er was geen onderlinge afspraak wie wanneer wat ging oppakken. Daardoor was er soms te weinig focus op het oppakken van support tickets.
Als oplossing starten we nu onze daily stand-up met het bijbehorend support Kanban bord. Hierdoor is een vorm van visueel management ontstaan. Er wordt onderling afgesproken wie die dag primair verantwoordelijk is voor het oppakken van support tickets. Daarnaast kan iedereen in een oogopslag op het bord zien wat de stand van zaken is.
Visueel management in de vorm van een Kanban bord komt voort uit Lean. Het heeft niets met het Scrum framework te maken. Maar het helpt ons en verrijkt ons eigen proces.
Continue verbetering in ons eigen proces
Doordat we binnen onze teams niet bang zijn om veranderingen door te voeren in ons eigen proces, ondanks dat het niet direct binnen het Scrum framework valt, zijn we veel slagvaardiger. Dit zie je indirect terug in de resultaten voor de klant. De zogenaamde velocity chart (ook een GASP) is een manier om als Product owner de slagvaardigheid en consistentie van je team in opgeleverde storypoints te meten. Hierdoor is ook goed de tendens voor een project door de tijd heen te zien op bepaalde vlakken.
De aanpassing in de spelregels die je onderling afspreekt maken dat je als team beter kunt acteren op de veranderende omgeving.
Ook de communicatie met business stakeholders aan de klantzijde zijn we anders aan gaan pakken. Binnen Scrum dient een stakeholder precies aan te geven welke wensen zij hebben ten aanzien van het product. Vervolgens is het aan de Product owner om de juiste prioriteit hieraan te geven aldus de scrum guide.
Om zeker te zijn dat we de juiste user stories oppakken binnen de beschikbare capaciteit in de volgende Sprint werken teams vaak met een sprint planning. Tijdens de sprint planning wordt een select gezelschap gevraagd of de juiste prioriteiten zijn ingepland op de volgende Sprint. Dat zijn vaak de stakeholders met mandaat vanuit de klant en het ontwikkelteam van Enrise. En dit gebeurt in de vorm van een overleg. Met als discussiepunt een concept Sprint die door de Product owner is voorbereid.
Dit is wellicht geen GASP, omdat het geen algemeen geaccepteerde manier van prioriteren en meenemen van de business is. Maar voor ons werkt het prettig om op deze manier samen met de klant de prioriteit te bepalen voor de volgende Sprint.
Conclusie
GASPs maken het verschil tussen een team dat met Scrum functioneert en een team dat met daarbij zelf gekozen GASPs echt kan excelleren.
Door puur volgens de Scrum methodiek te werken, zonder andere toevoegingen, beperk je je eigen werkwijze. Naast dat je continu een beter resultaat wilt behalen aan het einde van je Sprint, wil je ook als team continu een beetje beter functioneren. Om tegenmaatregelen te nemen voor de verbeterpunten die uit de Retrospective komen, kun je GASPs heel goed inzetten als middel.
Dit hoeven dan niet perse Scrum gerelateerde GASPs te zijn, maar denk ook aan toevoegingen uit andere methoden als Lean / Six Sigma, Agile PM of DevOps die geschikt kunnen zijn. Dit hangt helemaal van het projectteam, het project en de fase van de samenwerking af.
