5 misvattingen over Scrum

In steeds meer bedrijven wordt een vorm van Scrum gebruikt. Ik schrijf bewust een vorm, omdat veel bedrijven aanpassingen doorvoeren die ze goed uitkomen. Ik ben niet tegen aanpassen van Scrum. Zelfs in de Scrum guide staat dat je best zaken aan mag passen. Helaas zijn veel aanpassingen juist zaken die het leveren van waarde tegenwerken.

5 ideeën, die je tegenhouden in je verbetering

In dit blog ga ik in op 5 verschillende zaken die ik in praktijk tegengekomen ben, die Scrum of agile werken juist tegenwerken in het leveren van meer waarde naar je klanten.

Je kunt alleen aan het einde van de sprint een release naar productie brengen

Dit is niet waar, maar ik snap waar het vandaan komt. Volgens de Scrum guide moet je aan het einde van je sprint een “working increment” hebben. Daarnaast zijn we als we net begonnen zijn met Scrum nog gewend aan die grote projecten, die 3 maanden of langer duurden. Dus 2-4 weken is al best snel.

Scrum verbiedt echter niet dat je meerdere keren per sprint nieuwe functionaliteit naar productie zet. Sterker nog, het Agile manifesto zegt zelfs:”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Je kunt dus zelfs elke user story (product backlog item in Scrum) direct als je er klaar mee bent naar productie brengen, als je er klaar mee bent.

Het is toch mooi om tijdens de sprint review te kunnen vertellen dat de functionaliteit al op productie staat. En wat de eindgebruikers er van vinden.

Iedereen moet alles kunnen binnen het Scrum team

Teams moeten cross-functioneel en zelf-organiserend zijn. Dit zorgt ervoor, dat het team meer betrokken is bij het product dat ze opleveren en dat risico in continuïteit verminderd wordt.

Dit is door veel organisaties geïnterpreteerd als: iedereen moet alles kunnen (en soms zelfs overal expert in zijn). Dus als er ontwikkeld wordt in meerdere talen, dan moet iedereen dat kunnen. En dat geldt ook voor bijvoorbeeld testen, de verschillende testtools, ontwerp en documentatie.

Is het handig, dat mensen meerdere skills binnen het team hebben? Jazeker. Is het handig, dat elke skill door verschillende mensen bezit wordt? Jazeker. Moet iedereen alles kunnen? Zeker niet! Het t-shaped model, of pi-shape model geven heel mooi aan hoe je om kunt gaan met een of twee skills, die je erg goed kan en de rest heb je op zijn best een basis kennis van.

Het is dus niet nodig, dat iedereen alles kan, het is wel zeker nodig, dat alles gedaan kan worden door minimaal twee teamleden, zodat je niet afhankelijk bent van één persoon.

De techniek dicteert de manier van werken

Dit is niet perse een bewuste keuze, maar ik zie dit wel vaak onbewust gebeuren binnen bedrijven.

Binnen de organisatie is ooit begonnen met de aanschaf van apparatuur; specifieke servers, infrastructuur en werkstations. Dat is allemaal gedaan met het idee om het beste te kunnen werken in die specifieke omgeving.

Wat ik heb zien gebeuren, is dat binnen de organisatie begonnen wordt met Scrum en dat het team maar op die nieuwe manier moet gaan werken. Het team moet op een andere manier werken, die meer op zou moeten leveren dan de oude manier van werken. Het probleem is dat alle ondersteuning daarvan, en dan vooral de techniek, is afgestemd op die oude manier. We proberen dus een nieuwe mindset en een nieuwe manier van werken in te voeren en passen dan maar de zaken aan in het team die niet kunnen. Denk daarbij aan bijvoorbeeld het aantal beslispunten waar je langs moet voordat iets naar productie gezet kan worden.

De techniek is ooit ingesteld om de processen van dat moment te ondersteunen. Nu moeten ze aangepast worden naar de nieuwe processen. Dit hoeft niet in één keer, dat kan ook niet altijd, maar in het proces van continue verbeteren kan ook de omslag naar de nieuwe manier van werken meegenomen worden voor de ondersteunende zaken.

Velocity is een goed meetinstrument voor voortgang

Zoek in Google op velocity bij scrum, dan wordt duidelijk waarom het vaak niet juist gebruikt wordt. Velocity is niet meer dan een inschatting van wat het team denkt te kunnen doen in een sprint. Dit is geen belofte of een verplichting, dit is puur een inschatting vooraf. Het sleutelbegrip in deze zin is: het team. Het team bepaalt hoeveel werk ze denken te kunnen doen op basis van de informatie die ze hebben (bijvoorbeeld met ervaring met vorige sprints, diepte van de user stories).

Wat te veel gebeurt, is dat het team afgerekend wordt op lagere velocity en waarom ze minder hebben gedaan, of zelfs vergeleken worden met andere teams. Er zijn zelfs organisaties, die (het verhogen van) velocity gebruiken als KPI tijdens beoordelingsrondes. Dit is raar, want het team bepaalt zelf haar velocity en velocity als KPI zal de verbetering van het team tegengaan.

Velocity is maar voor twee zaken goed te gebruiken:

1.       Voor het team om te bepalen hoeveel ze denken te kunnen opleveren in deze sprint

2.       Voor de product owner om een inschatting te kunnen maken wanneer een bepaalde functionaliteit klaar zou kunnen zijn met de huidige informatie.

“Wij kunnen het zelf wel”

De voorgaande vier punten zijn signalen, dat dit idee waarschijnlijk wel leeft binnen de organisatie. We hebben namelijk jarenlang projectmanagers gehad en de mensen, die beslissen zijn vaak ervaren managers. Dus dat Scrum implementeren en Scrum master zijn, dat kunnen we zelf wel. Daar hebben we niemand van buiten voor nodig.

Scrum ( of agile in het algemeen) is simpel te begrijpen, maar om het goed te doen moet je meer dan alleen die 19 pagina’s kennen van de Scrum guide. Het is voor de meeste organisaties een compleet nieuwe manier van werken. Door de verandering te laten doen door mensen die gewend zijn op de huidige manier te werken, zal de verandering niet of niet op de juiste manier in de organisatie landen. Als daarna toch een Scrum master of Agile coach van buiten moet komen om te helpen, duurt het alleen maar langer. Niet alleen omdat diegene de oude manier van werken moet veranderen, maar ook om de problemen op te lossen die door de verandering zijn ontstaan. Dit levert veel frustratie en vertraging op binnen de organisatie, maar zeker binnen de teams, die het meeste met Scrum moeten werken.

Dus 5 ideeën, die je tegenhouden in je verbetering. Herken je één of meerdere van deze voorbeelden uit je eigen organisatie? Neem dan eens contact op om echt te verbeteren.

Alex Roos, DevOps Consultant/Agile coach