Één van mijn vorige opdrachtgevers heeft als motto: ‘Alleen ga je soms sneller, maar samen kom je verder’. Dit motto komt van onderstaand Keniaans gezegde:

Als je snel wilt gaan, ga dan alleen.

Als je ver wilt komen, ga dan samen.

Dat is mij tot op heden bijgebleven. Het is namelijk heel erg waar, en zeker een mooi motto om af en toe bij stil te staan. De meest voorkomende valkuilen die ik in de scrumpraktijk heb gezien, komen namelijk allemaal terug bij deze ene zin. In deze blog schets ik heel kort een paar van deze praktijkvoorbeelden.

  • Stel jezelf open voor multidisciplinair werk.

Een voorbeeld: Sommige zaken zijn relatief snel te ontwikkelen, terwijl het testen heel veel tijd vraagt (of vice versa). Wanneer je als lid van een development team uitsluitend werkzaamheden verricht die bij een rol horen, dan kom je langzamer vooruit. De valkuil: werk stapelt zich op bij één persoon, de trechter loopt vol, je kunt niet releasen, er zitten mensen met weinig tot geen werk, terwijl anderen overlopen met werk. Hou altijd het gezamenlijke sprintdoel voor ogen.

  • Vraag om het waarom / vertel het waarom.

Soms denk je te begrijpen wat er gevraagd wordt, maar blijkt in een laat stadium dat er met aannames is gewerkt. Of je denkt als stakeholder dat je verzoek duidelijk is overgekomen. Dit kan ervoor zorgen dat iets snel ontwikkeld is, maar uiteindelijk wordt het niet gereleased doordat het niet  voldoet aan de klantwens. Het waarom zorgt ervoor dat iedereen weet wat het doel is dat je gezamenlijk wilt bereiken. Dit doel staat centraal; hoe het doel bereikt wordt, daar kunnen de experts zich over buigen, te weten het scrumteam. Deze vrijheid geven zorgt voor creatief denken. Zo kan de uiteindelijke oplossing voor positieve verrassingen zorgen, bijvoorbeeld minder ontwikkelkosten dan verwacht. Daarnaast is het een feit dat een team dat zich creatief kan uiten en veel autonomie ervaart, over het algemeen meer betrokken en efficiënt is.

  • De Product Owner stelt de prioriteiten.

Behulpzaam als we zijn, willen we altijd wel even tijd maken voor iemand. Maar ongemerkt is al dat ‘even’ bij elkaar opgeteld al snel een paar uur werk. Neem daarbij de tijd die je nodig hebt om je focus te verplaatsen van, en later weer terug te krijgen óp je scrumwerk, en je loopt het risico dat jullie sprintdoel in gevaar komt. Verwijs een ‘inbreker’ altijd naar de Product Owner, zodat deze de prioriteit kan afstemmen. Vaak zal het gevraagde werk dan via de backlog het team bereiken. Gepland, gerefined, gepokerd én beschreven voor het nageslacht…. Of eventuele audits. Daarnaast kan de Product Owner beoordelen of het verzoek in lijn is met de koers die het bedrijf als geheel wil varen. Ik zeg niet dat je mensen moet wegsturen. Dat is niet hoe je je team wilt representeren. Ook hier geldt: vertel waarom. Door dit alles uit te leggen aan degenen die een ad hoc verzoek hebben, help je de hele organisatie bij de adaptie van Scrum. En zo kom je samen verder.

Eigenlijk heel logische zaken, maar toch soms erg lastig om consequent vast te houden. Want we weten: Scrum is Easy to understand, but difficult to master.

Ik ben erg benieuwd waar jullie tegenaan lopen in de praktijk? En zou je datgene kunnen verbeteren door af en toe stil te staan bij dit ene zinnetje?

Leave a Reply