Uitdagingen van Hardwareteams met Scrum

Agile en de Agile frameworks

Maar Scrum is slechts één van de Agile frameworks die organisaties kunnen helpen om agile te worden. Wat alle Agile frameworks gemeen hebben, is dat ze allemaal empirisch zijn. Dit betekent dat ze waarde leveren door dingen transparant te maken zodat je kunt inspecteren en aanpassen waar nodig.

Naast het Scrum framework zien we vaak dat Kanban wordt gebruikt. Kanban gaat over visualisatie en het beperken van het aantal dingen dat tegelijkertijd wordt gedaan. "Stop met starten en begin met afronden" is een vaak gehoorde uitspraak. Een video die dit proces perfect beschrijft, is de "Resource Utilization Trap" van Henrik Kniberg. Hier legt Henrik uit over flow, het beperken van werk in uitvoering en het pull-systeem.

In dit artikel zal ik twee uitdagingen beschrijven die ik vaak hoor van hardwareteams die Scrum gebruiken. Vervolgens zullen we zien of Kanban wellicht beter geschikt is voor teams die met deze uitdagingen worden geconfronteerd.

Ons werk past niet in een sprint

Bij Scrum spreken we van een sprint, een vaste periode die 1 tot 4 weken duurt. Een Scrum-team stelt een sprintdoel op waarop ze zich gezamenlijk kunnen concentreren tijdens de sprint. Aan het einde van de sprint levert het team een waardevolle toevoeging aan het werkende product.

Een uitdaging voor veel hardwareteams is dat het proces van het maken van een nieuw hardware-onderdeel gedetailleerde tekeningen, documentatie en afspraken met leveranciers vereist voordat het wordt besteld. Na de daaropvolgende wachttijd wordt de hardware ontvangen en kan het team beoordelen of het hardware-onderdeel aan de eisen voldoet. Dit proces past bijna nooit in een tijdsbestek van 4 weken of minder. Met Scrum zou dit betekenen dat het item van de ene naar de andere sprint zou gaan, mogelijk zelfs meerdere keren. Dit is vaak niet prettig voor teams. Het kan voelen als falen, omdat Scrum zich richt op het afronden van alles tijdens de sprint.

Maar hoe verschilt dit als we Kanban gebruiken? Bij Kanban werken we niet met een sprint, maar in een continu proces. Dit betekent dat de items worden opgepakt door een teamlid wanneer hij/zij ruimte heeft om iets nieuws op te pakken. Er is geen begin of einde van een sprint om rekening mee te houden bij het oppakken van een item. Dit lijkt misschien een direct antwoord op teams die klagen dat hun werk te groot is voor een sprint, maar zo eenvoudig is het niet. Bij het werken met Kanban proberen we de werkitems nog steeds zo klein mogelijk te houden. Bij Kanban ligt de focus op het creëren van flow, wat in feite betekent dat je regelmatig een stuk werk afrondt. Eén groot werkitem betekent minder flow omdat het een team langer duurt om het af te ronden.

Een ander voordeel voor hardwareteams die Kanban gebruiken, is dat de wachttijd transparant kan worden gemaakt op het Kanban-bord. Bij het ontwikkelen van hardware zien we deze wachttijd nadat het onderdeel bij een leverancier is besteld. Het team kan deze items visualiseren om er zicht op te houden en actie te ondernemen als iets langer duurt dan verwacht.

Ons team bestaat uit specialisten

Een Scrum-team is het meest flexibel wanneer de teamleden een brede vaardigheidset hebben, waardoor ze het werk met de hoogste prioriteit kunnen oppakken en het als team kunnen afronden. In hardwareontwikkeling zien we vaak dat organisaties veel specialisten hebben. Deze specialisten worden meestal 'gedeeld' over meerdere projecten. Hoewel het de bedoeling is van het Scrum-framework om een team zich te laten concentreren op het creëren van een kleine, verbeterde versie van het product, werken specialistenteams vaak aan verschillende en onsamenhangende taken. Je zult merken dat de events in Scrum gaan over het delen van informatie in het team om samenwerking mogelijk te maken. Maar is dit waardevol als je alleen aan je eigen taak werkt? We horen vaak teams van specialisten klagen dat deze events aanvoelen als tijdverspilling omdat wat het andere teamlid doet, er niet echt toe doet. Ze geven soms gewoon niet (hoeven te) geven...

Als we naar Kanban kijken, zien we dat alle teamleden het werk oppakken dat bij hun vaardigheden past. Alleen als er een knelpunt ontstaat, zullen ze een experiment starten om het op te lossen. Het experiment kan gaan over kennisdeling of iets heel anders, zolang ze maar denken dat het het probleem zal oplossen. Bovendien schrijft Kanban niet voor welke vergaderingen je moet hebben. Het is belangrijk om te weten dat je nog steeds moet investeren in zaken als het verfijnen van werk, feedback krijgen en het proces verbeteren. Dus Kanban gebruiken is geen goed excuus om alle vergaderingen die je niet leuk vond toen je met Scrum werkte, te annuleren.

Omdat Kanban een methodologie is die stelt dat je begint met wat je nu doet en van daaruit verbetert, begin je met het nemen van je huidige proces en neem je kleine stappen om dat te verbeteren. Als voorbeeld kun je de retrospective gebruiken om een experiment te bedenken over wat er zal gebeuren als je stopt met het verfijnen van de backlog als team en het meer op individuele basis gaat doen. Als team bedenk je het doel dat je wilt bereiken met de verandering en hoe je gaat meten of je in de richting van dit doel beweegt. Op deze manier kun je, op basis van daadwerkelijke metingen, je teamproces verbeteren.

Dus, zal Kanban de uitdagingen oplossen?

Persoonlijk denk ik dat Kanban frustraties kan verminderen die kunnen ontstaan wanneer hardwareteams met Scrum werken, hoewel het altijd afhankelijk zal zijn van de omgeving van het team. Daarom is het antwoord niet eenvoudig, maar vereist het leren en ervaring opdoen. Onthoud ook de vier waarden van Agile: individuen en interacties boven processen en tools. Als mensen gefrustreerd zijn omdat het proces (in dit voorbeeld Scrum) niet bij hen past, leef je dan echt volgens deze waarden?

Uiteindelijk is het doel niet om Scrum of Kanban perfect te doen, maar om de beste klantwaarde te realiseren, en wendbaarheid kan je daarbij helpen.