Checklist voor Scrum Masters

Een goede Scrum Master kan twee of drie teams tegelijk begeleiden. Als je er tevreden mee bent om je rol te beperken tot het organiseren van meetings, het bewaken van tijdsafspraken en het oplossen van problemen van het team, dan kan de rol als Scrum Master prima in deeltijd werken. Het team zal zeker de verwachtingen overtreffen die er in je organisatie waren vóór Scrum, en waarschijnlijk zullen er ook geen grote rampen plaatsvinden.

Maar als je je kunt voorstellen dat een team er plezier in heeft om dingen te bereiken die niemand ooit voor mogelijk had gehouden, dan moet je ook de ambitie hebben om een geweldige Scrum Master te zijn.

Een geweldige Scrum Master kan zich maar op één team tegelijk richten.

Vooral in de beginfase raden we daarom aan om een gemotiveerde en toegewijde Scrum Master in te zetten voor een team van ongeveer zeven personen.

Als je nog geen overzicht hebt van al het werk dat gedaan moet worden, probeer dan meer te weten te komen over de Product Owner, het team, de ontwikkelmethoden van het team en de organisatie als geheel. Ook al bestaat er geen wondermiddel, ik heb hier toch een aantal punten op een rij gezet waar een Scrum Master op zou moeten letten:

Scrum Master Checklist voor de Product Owner

Je kunt de effectiviteit van de Product Owner vergroten door hem te helpen bij het beheren van de Product Backlog en het releaseplan. (Houd er wel rekening mee dat alleen de Product Owner de Backlog zou moeten prioriteren.)

• Komt de prioritering van de Product Backlog overeen met de meest recente inzichten en ideeën van de Product Owner?

• Zijn alle eisen en wensen van alle stakeholders opgenomen in de backlog? Houd er rekening mee dat de backlog voortdurend kan veranderen.

• Heeft de Product Backlog een goed hanteerbare omvang? Om een overzichtelijk aantal items te behouden, moeten de gedetailleerde items bovenaan de backlog staan en de meer algemene onderwerpen onderaan. Het is contraproductief om bij meer dan alleen de bovenste items te veel in detail te treden, want de eisen zullen voortdurend veranderen door de doorontwikkeling van het product en de constante uitwisseling met klanten/stakeholders.

• Zijn er eisen (vooral die bovenaan de backlog), die beter geschreven kunnen worden als onafhankelijke, onderhandelbare, waardevolle, inschatbare, kleine en testbare User Stories (INVEST-criteria)?

• Heb je je Product Owner voorgelicht over technische schuld en hoe die te vermijden is? Het kan daarbij helpen om geautomatiseerde tests en refactoring toe te voegen aan de Definition of Done van elk Backlog Item.

• Is de backlog als informatiebron goed inzichtelijk voor alle stakeholders?

• Heb je een geautomatiseerde tool om de backlog te beheren? En zo ja, levert het je ook daadwerkelijk iets op? Zulke tools brengen namelijk het risico met zich mee dat je moeilijk de gezochte informatie kunt vinden als de Scrum Master deze informatie niet actief communiceert.

• Kun je helpen om de informatie te communiceren door deze uit te printen en aan alle betrokkenen uit te delen?

• Kun je helpen om deze informatie te communiceren door grote, goed zichtbare overzichten en diagrammen te maken?

• Heb je de Product Owner geholpen om de Backlog Items op te delen in passende releases? (Bijv. in huidig werk (Front Burner), aankomend werk (Back Burner) en zaken die wel in de backlog zijn opgenomen, maar nog niet verder zijn voorbereid (Fridge).)

• Weten alle stakeholders (inclusief het team) of het releaseplan – gemeten aan de huidige velocity (bijv. Story Points per Sprint) – nog steeds overeenstemt met de werkelijkheid?

• Heeft de Product Owner het releaseplan na het laatste Sprint Review Meeting bijgewerkt? Slechts weinig Product Owners die op tijd voldoende geteste producten opleveren, werken het releaseplan elke Sprint bij. Vaak schuiven ze bepaald werk door naar toekomstige releases zodra er belangrijker werk opduikt. Probeer het eens met de Product/Release Burndown Charts van Mike Cohn, die je aan alle betrokkenen kunt presenteren nadat in de Sprint Review Meetings bevestigd is dat de items "done" zijn. Hieraan zijn vroegtijdig veranderingen in scope of planning goed te herkennen.

Scrum Master Checklist voor het team

1.) Zijn de teamleden het grootste deel van de tijd in een „flow"? Enkele kenmerken van deze toestand zijn: duidelijke doelen (verwachtingen en regels zijn herkenbaar; de doelen zijn haalbaar en passen bij de vaardigheden van de individuele personen); concentratie en focus (focussen op een bepaald zwaartepunt); verminderde onzekerheid (handelen en bewustzijn versmelten); het tijdsbesef verdwijnt (de subjectieve tijdsbeleving verandert); direct en onmiddellijk feedback (successen en mislukkingen tijdens het handelen zijn goed herkenbaar, waardoor het gedrag indien nodig kan worden aangepast); een evenwichtige verhouding tussen vaardigheden en uitdaging (het is niet te moeilijk en niet te makkelijk); een gevoel van persoonlijke controle over de situatie/handeling (de handeling is een intrinsiek belonende en daarom moeiteloze taak).

1.) Lijken de teamleden goed met elkaar overweg te kunnen? Ondernemen ze samen dingen? Vieren ze samen met hun collega's elkaars successen?

2.) Letten de teamleden erop dat iedereen zich aan de hoge standaarden houdt? Moedigen ze elkaar aan om zich te verbeteren?

3.) Zijn er problemen of kansen waar het team niet over praat, omdat ze zich er niet comfortabel genoeg bij voelen? Je kunt een professional inschakelen die je kan helpen om ongemakkelijke gesprekken gemakkelijker te maken. (Of lees meer over dit onderwerp in het boek Crucial Conversations: Tools for Talking When Stakes are High)

4.) Heb je al verschillende formats en locaties voor je Sprint Review Meetings uitgeprobeerd? Enkele ideeën vind je in het boek Agile Retrospectives: Making Good Teams Great van Esther Derby en Diana Larsen.

5.) Heeft het team zich aan de acceptatiecriteria gehouden? Misschien moet je tijdens de Sprint nog eens de acceptatiecriteria van de Product Backlog Items voor deze Sprint controleren.

6.) Weerspiegelt de Sprint Backlog daadwerkelijk waar het team op dit moment aan werkt? Onderbrekingen en afleidingen die niet bijdragen aan het bereiken van het Sprintdoel zijn obstakels.

7.) Zijn de inschattingen voor de taken en het taskboard up-to-date?

8.) Zijn de artefacten voor het zelfmanagement van het team (taskboard, Sprint Burndown Chart etc.) voor het hele team goed zichtbaar, praktisch en doelmatig?

9.) Zijn deze artefacten voldoende beschermd tegen micromanagement?

10.) Melden teamleden zich vrijwillig voor bepaalde taken?

11.) Zijn er items om technische schuld af te lossen opgenomen in de Backlog (om problemen op te lossen die de Velocity schaden) of zijn deze in ieder geval met de Product Owner besproken?

12.) Laten de teamleden hun functietitels buiten de teamruimte?

13.) Voelt het hele team zich verantwoordelijk voor tests, gebruikersdocumentatie etc.?

Checklist voor de ontwikkeling van het product

1.) Heeft jullie systeem in de ontwikkeling een "push-to-test"-knop, zodat iedereen (in hetzelfde of een ander team) eenvoudig kan achterhalen of hij iets kapot heeft gemaakt? Dit wordt normaal gesproken bereikt met het xUnit Framework (JUnit, NUnit enz.).

2.) Hebben jullie een evenwichtige verhouding tussen geautomatiseerde end-to-end systeemtests (functionele tests) en geautomatiseerde unit tests?

3.) Schrijft het team zowel "functionele tests" als unit tests in de taal van het systeem dat ze ontwikkelen (in plaats van propriëtaire scripttalen of capture & playback tools, waar slechts een klein deel van het team mee overweg kan)? Het is namelijk mogelijk!

4.) Heeft jullie team al de uiterst nuttige grijze zone tussen systeemtests en unit tests ontdekt?

5.) Slaat een Continuous-Integration-Server automatisch binnen een uur (of enkele minuten) alarm zodra iemand een regressiefout heeft veroorzaakt?

6.) Komen alle tests samen in het resultaat van de Continuous-Integration-Server?

7.) Hebben de teamleden al de voordelen van evolutionair design (Continuous Design) en "meedogenloos refactoring" als alternatief voor Big Design Upfront (BDUF) ontdekt? Refactoring heeft een duidelijke definitie: het wijzigen van de interne structuur van een systeem zonder het van buitenaf waarneembare gedrag te veranderen. Bij redundante code, complexe logica, slechte naamgevingsconventies, excessieve koppeling tussen objecten enz. zou refactoring meerdere keren per uur uitgevoerd moeten worden. Geautomatiseerde testdekking is zeer geschikt als vangnet voor refactoring. Gaten in de testdekking en uitgestelde refactoring zijn kwalen die ook wel technische schuld worden genoemd.

8.) Bevat jullie Definition of Done voor elk functioneel Product Backlog Item een volledig geautomatiseerde testdekking en refactoring? Het is onwaarschijnlijk dat je in elke Sprint een potentieel leverbaar product kunt opleveren zonder methoden van eXtreme Programming te leren (zoals bijvoorbeeld beschreven door Kent Beck, Ron Jeffries enz.).

9.) Werken de teamleden grotendeels met pair programming? Pair programming kan de onderhoudbaarheid van code dramatisch verbeteren en het aantal bugs verminderen. Het kan je echter tot het uiterste drijven en soms lijkt het iets langer te duren (als we kwantiteit boven kwaliteit stellen). In plaats van teamleden ertoe te dwingen, kun je beter het goede voorbeeld geven en voorstellen om op bepaalde dagen in de week in paren te werken. Sommige teamleden zullen deze manier van werken al snel verkiezen.

Scrum Master Checklist voor organisatieontwikkeling

1.) Is er voldoende coördinatie tussen de afzonderlijke teams? Een Scrum of Scrums is de enige manier om dat te bereiken. Daarnaast kun je vertegenwoordigers uit je team naar de Daily Standup-meetings van andere teams sturen.

2.) Wordt de coördinatie binnen het team echt – zoals aanbevolen – uitgevoerd door degenen die dagelijks het werk doen?

3.) Komen de verschillende Scrum Masters samen om aan de lijst met organisatorische belemmeringen te werken?

4.) Worden belemmeringen aan de ontwikkelingsmanager gemeld wanneer dat gepast is? Kan de prijs daarvan worden uitgedrukt in geld, verloren time-to-market, verloren kwaliteit of gemiste kansen voor de klant?

5.) Is jouw organisatie een van de weinige waarvan de carrièremogelijkheden verenigbaar zijn met de collectieve doelen van de teams? Dat is niet het geval als er prikkels bestaan die ertoe verleiden om te programmeren of aan de architectuur te werken ten koste van tests, testautomatisering of gebruikersdocumentatie.

6.) Help je mee aan het creëren van een lerende organisatie?

7.) Staat jouw organisatie in de vakpers of bij andere onafhankelijke bronnen bekend als een aantrekkelijke werkplek of marktleider?

Angst is je vriend

Zodra je je realiseert wat je allemaal kunt doen om iets in beweging te zetten, kan dat best beangstigend zijn. Maar dat is juist een teken dat je op de goede weg bent.

Deze tekst is afkomstig van de blog van de Scrum Alliance en door ons vertaald naar het Nederlands.