A rugby union scrum between the British and Irish Lions and the All Blacks. (Photo credit: Wikipedia)
Een Scrum master die ik vorige week sprak verzuchtte: “mijn teamleden pakken nog steeds niet zelfstandig taken op van het Scrumboard”. Een duidelijk signaal dat er iets grondig mis is. Een nader gesprek leverde het volgende op:
De teamleden gaan dus steeds als ze ergens mee klaar zijn naar de Scrum Master en vragen hem wat ze nu eens moeten gaan doen. Scrum zou toch moeten leiden tot een zelf-organiserend team. Wat ging er mis?
Oorzaken:
- de teamleden werkten grotendeels niet full-time in het team;
- de teamleden werkten op 2 locaties (Amsterdam en Den Bosch);
- sprints hadden geen duidelijke sprint goal, waardoor het lastig was om je echt aan een concreet resultaat te committeren;
- veel sprints werden niet afgesloten met een demo (sprint review), doordat er vaak “onderwater” functionaliteit werd opgeleverd die toch niet goed te demo-en was;
- het werk in de sprint werd vaak verstoord door binnenkomende bugs (op dit product of op producten uit het verleden waar teamleden nog verantwoordelijk voor waren).
Oplossingen
Gemakkelijke oplossingen bestaan er niet in zo’n situatie, waar het team al 20 sprints gedaan heeft en zelf het gevoel heeft best wel goed aan het Scrummen te zijn. Maar er kunnen wel stappen gezet worden.
Quick Wins
- het definiëren van een duidelijke Sprint Goal helpt vaak sterk bij het krijgen van meer focus in het team en daardoor bij het krijgen van meer team spirit; volgens Dan Pink ontstaat motivatie vanuit purpose, mastery en autonomy; een sprint goal levert de purpose voor een sprint;
- iedere sprint MOET met een demo worden afgesloten! Dat gaat gemakkelijker als de user stories goed zijn gekozen, als vertical slices die ieder voor zich waarde hebben voor een gebruiker. Maar zelfs als je nog even moet leven met minder goede user stories is het altijd mogelijk een demo te doen;
- als bugs snel, door dit team, moeten worden opgelost, is het een idee om bijvoorbeeld 2x in de week een bug-sprint-planning meeting te houden. Op die manier weet het hele team wat er binnengekomen is, hoe ernstig de bugs zijn en wat de prioriteitsverdeling is tussen bugs en user stories.
Volgende stappen
- Ga een discussie aan met het management over de toewijzing van mensen aan het Scrum team. Scrum is veel krachtiger met full-time, co-located team members dan met part-timers die niet op één locatie zitten. Soms is dit gemakkelijk te regelen, soms zitten specialismen je in de weg. Het zoeken naar een T-Profiel kan dan nog helpen;
- Herschrijf je User Stories zodat iedere story iets van waarde voor een user oplevert. Elke user story zou een vertical slice uit het product moeten zijn, dus èn een beetje user interface èn wat middleware code èn wat database informatie.
Tot zo ver mijn consultancy bijdrage na 1 uurtje werken met de Scrum Master. Hebben jullie verder nog adviezen voor dit team?
Andre Heijstek's Blog 
Kan dit bedrijf niet beter een andere methode gebruiken zoals RUP (of AUP is dan misschien nog beter voor ze).
Hallo Sander,
Als een methode niet goed werkt is het vaak verleidelijk om dan maar een andere methode te gaan gebruiken. Toch is dat meestal niet de oplossing. De methode is meestal niet de oorzaak van de problemen, maar het onjuiste of onvolledige gebruik van de methode is de oorzaak.
In lijn met de Shu-Ha-Ri aanpak is het zaak om door te zetten met de methode. Eerst strak volgens het boekje, en later met aanpassingen aan de eigen context (geleerd in de retrospectives bijvoorbeeld).
Of zie jij in bovenstaande case punten die aangeven dat Scrum overduidelijk de foute methode is, en RUP/AUP duidelijk beter?
Beste André,
De eerste stap is volgens mij juist: Wat is het probleem dat een bedrijf heeft? En dan, hoe kan dat opgelost kunnen worden? Scrum zou een oplossing kunnen zijn voor dit bedrijf. Maar andere methoden zouden dat net zo goed kunnen zijn. Dat kan ik ook niet beoordelen op basis van dit blogje 🙂 Maar de Shu-Ha-Ri aanpak heeft natuurlijk weinig zin als ze de Shu niet eens goed kunnen uitvoeren doordat hun organisatie niet past bij Scrum. Als ik die eerste 4 punten bij ‘Oorzaken’ lees, vraag ik me sterk af of Scrum wel de handigste oplossing voor hen is voor een bedrijf dat op deze manier georganiseerd is. De reden dat ik dan bij RUP of AUP aankom, is met name dat die meer geschikt zijn voor gedistribueerde omgevingen waarin de verschillende teamleden niet altijd tegelijk aanwezig zijn of op dezelfde dagen/uren werken (overigens brengt dat ook een nadeel met zich mee: de benodigde documentatie). Bovendien is daar meer ruimte voor “onderwater functionaliteit” (oa door het ontwikkelen van een kern architectuur op basis van op risico geprioriteerde requirements).
Mijn stelling is dan ook: zoek de juiste oplossing voor een probleem, en probeer niet elk probleem op te lossen met dezelfde oplossing. Of pas het probleem (lees: bedrijf) zodanig aan dat dezelfde oplossig wel past 😉