Blog

2 agile boek cmmi dus goed management meer mijn organisatie planning product project projecten requirements scrum software sprint stories story team user vaak veel waar

Scrum rammelt – #1 – Team pakt zelf geen taken 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.

Deze punten zijn Quick Wins omdat ze volledig in handen liggen van het Scrum Team. We zijn van niemand afhankelijk om dit te gaan verbeteren.

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?

« Terug naar het nieuwsoverzicht

Comments

Add Comment

Zoeken

Laatste nieuws

Volgorde van de backlog

De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder.

In het algemeen wordt als advies gegeven dat de items op volgorde van waarde...

» lees meer

Events

27-05-2013

Training Veranderproject ism. NOVI en veranderproject.nl

We moeten sneller en gerichter veranderen". “Onze organisatie verandert continu, maar lost dat alle problemen op?” “Er lopen zoveel veranderingen, ik mis het overzicht!” Herken je deze uitspraken? Dan weet je vast hoe...