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 steeds als ze ergens mee klaar zijn naar de Scrum Master en vragen hem wat ze nu eens moeten gaan doen. Scrum zou echter 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 twee 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 twee keer 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 een uurtje werken met de Scrum Master.
Andre Heijstek, Improvement Focus
Dag Andre,
Het lijkt erop dat agile methoden zoals scrum alleen maar goed werken als er strakke regels worden nageleefd en mensen fysiek dicht bij elkaar zijn. Dit principe van strakke regels en fysieke aanwezigheid staat haaks op de ontwikkeling die bedrijven momenteel doormaken. Aangejaagd door ontwikkelingen zoals Het Nieuwe Werken zijn mensen steeds minder vaak fysiek samen en worden samenwerkingsvormen steeds flexibeler en vluchtiger.
Zijn agile methoden binnen deze context wel goed toe te passen?
Vriendelijke groet,
Leon Dohmen
Hallo Leon,
Je observaties zijn correct: Scrum werkt het allerbeste met een zogenaamd co-located team. Een stuk of 7 ontwikkelaars samen in ‘een hok’ werkt in mijn ervaring het allerbeste.
En dus heeft Scrum best een beetje een hekel aan het-nieuwe-werken. En zeker aan die vorm van het nieuwe werken die jij beschrijft, waar het individualisme wel vanaf spat. Ik vind het more-agile manifesto van Geert Bossuyt erg sterk, waarin hij stelt dat “teamwork and responsibility” belangrijker zijn dan “individuals and interactions”, en die zijn natuurlijk weer belangrijker dan “processes and tools”.
Dat wil niet zeggen dat andere settings helemaal niet kunnen werken. Ik heb een paar keer een Scrum team gezien dat deels uit een team in Nederland en deels uit een team in Oost-Europa bestond. Continue de webcam aan aan beide kanten, een groot scherm, waardoor het toch leek dat beide teams in 1 grote kamer zaten te werken.
Het team waar ik zelf op dit moment mee werk heeft 1 vaste dag van thuiswerken. Op die dag is het hele team thuis, op andere dagen zitten we bij elkaar. Die vorm is een aardig compromis tussen het nieuwe werken en Scrum.