In deel 3 hebben we de taken van de Scrum Master bekeken. We hebben de combinatie met de PO besproken. Daarbij gezien dat Scrum de twee rollen duidelijk apart beschreven heeft en met goede redenen. De rollen hebben taken die elkaar netjes in balans houden, elk zorgen voor een eigen stukje meerwaarde voor de organisatie, stakeholders, het team en het product. De meerwaarde van die twee vervalt wanneer men ze combineert.
We hebben nog een aantal mogelijke combinatierollen – teamlid, team lead, manager of C-rol. Laten we daar nu in dit laatste deel van deze serie naar kijken.
Nu dus de rol van Scrum Master…
... gecombineerd met teamlid of team lead
Voor een team lead zou het een goede mogelijkheid zijn om zich te ontwikkelen tot een betere manager. Dit werkt echter alleen als hij die ambitie al heeft en zich daarin richt op de menselijke aanpak waarbij hij zijn team coacht. Daarbij zal vrijwel altijd de developer-rol, de Scrum Master steeds overtroeven aangezien dit eenvoudiger meer tijd en aandacht vraagt en de team lead gemakkelijker afgaat doordat hij veel meer ervaring met de materie van programmeren heeft. Hij zal dus waarschijnlijk zijn tijd vaak kwijt zijn aan de ontwikkeltaken vooral als deze wat geavanceerder en kritischer zijn. Het geldt dus voor zowel een team lead als een teamlid en developer, in het beste geval is hij een goede ontwikkelaar maar heeft geen tijd om goed zijn taken als Scrum Master te doen. In het ergste geval is het ook nog zo dat hij geen tijd heeft om zijn vakgebied bij te houden en taken technisch correct uit te voeren wat leidt tot technical debt of zelfs kleine (maar cruciale) foutjes.
... gecombineerd met rol van manager of zelf C-rollen
Hierbij is er een natuurlijke overlap in benodigde vaardigheden. Beide rollen vereisen een ‘servant leader’-mindset. Een Scrum Master moet daarbij uiteraard de kennis hebben van Scrum en Agile-werken. Heeft een manager de tijd om goed te zorgen voor het team, voor het faciliteren van de events, meetings en het wegwerken van de hindernissen die het team ondervindt bij hun werk? Heeft hij de tijd om de organisatie daarbij te helpen groeien in Scrum? In de praktijk blijkt dat zij hier vaak niet voldoende aandacht aan kunnen besteden waardoor de meerwaarde van bijvoorbeeld de events sterk verminderd. Is iedereen wel uitgenodigd? Zijn alle faciliteiten geregeld?
Verder ontstaan er situaties die zeer ongewenst zijn. We hebben hier in een eerder deel al aandacht aan geschonken maar dat geldt ook voor de rol van Scrum Master. De puntjes nog eens op een rijtje: Het team kan zich onveilig en niet op hun gemak voelen zich bij een manager te uiten. Dit staat de groei en verbetering van het team en het proces in de weg. Men kan zichzelf, het team en Scrum niet naar het volgende niveau krijgen en blijven dus steken. Ook al zit de manager in de officiële rol van Scrum Master in de meetings, hij is wel degene die beoordelingen geeft en beslissingen mag nemen over je eventuele bonussen en zelfs je baan. Daarnaast voelt het team zich hoogstwaarschijnlijk minder geneigd om zelf eigenaar te zijn van hun werk. Zij hebben immers constant een manager erbij die de eindverantwoordelijkheid heeft en het team kan dus nooit groeien naar een zelfsturend, zelf-organiserend team. Het is eenvoudiger om je achter de keuzes van de manager te verschuilen. Dit is echter niet iets dat professionals graag doen. Het kan dus snel tot ongenoegen en een onvervuld gevoel leiden. Dit op zijn beurt zorgt ervoor dat de medewerker op zoek gaat naar een andere baan waar hij zijn professionaliteit en kwaliteit wel mag inzetten. Als bedrijf verlies je hiermee dus een hoop kennis en ervaring.
Een team zal zich dus nooit sterk genoeg voelen omdat er niemand is die achter of naast hen gaat staan en hen steunt. Denk hierbij aan een situatie waarin de Manager-ScrumMaster tijdens de Refinements of planningsmeetings zegt: ‘Jongens, dit moet echt in minder tijd want ik heb niet zoveel begroot. Dan gaan we verlies draaien als het zo blijft’. Wat doet een team dan? Zijn ze sterk genoeg, of volgens de Scrum-waarde moedig genoeg om daar toch vast te houden aan hun eigen inschatting? Of wat als ze overruled worden door de Scrum Master in hun technische keuzes, keuzes voor tijdsinschattingen, volgorde van werk en story-readiness? Telkens blijkt hierin dat de dubbelrol van de Manager-Scrum Master er dan voor zorgt dat het team voorzichtig is met hun uitingen en meestal meegaat met de uitspraak van de manager. Dit resulteert uiteindelijk in nog meer ongenoegen want het team haalt het bijvoorbeeld niet in minder tijd, of levert mindere kwaliteit aangezien ze het wel binnen de tijd wilden afhebben maar die mindere kwaliteit gaat opvallen. Dan denkt de manager dat hij het team niet kan vertrouwen in hun werk en er nog meer bovenop moet zitten, waardoor je in een neerwaartse spiraal terecht gekomen bent. Het probleem is in dit geval niet je ontwikkelaars. Het is het micro-managen en het gebrek aan vertrouwen, respect volgens de Scrum-waarde, dat je team een groep professionals is die hun werk kunnen organiseren en weten wat ze doen.
Samenvattend
We hebben nu over twee delen alle combinaties voor de Scrum Master besproken. We hebben gezien dat alle gevallen de combinatie leidt tot negatieve effecten zoals verminderde kwaliteit van het product, stakeholders die niet tevreden zijn of krijgen wat ze nodig hebben, verminderde kwaliteit in de werkzaamheden van de Scrum Master, gedemotiveerde medewerkers.
Conclusie
We kunnen niet multitasken. We kunnen onze tijd maar een keer besteden. We willen allemaal onze kwaliteiten volledig in kunnen zetten en daarmee de beste resultaten kunnen leveren. In de combinatierollen ontnemen we onszelf die mogelijkheden. Of het dus gaat over het combineren van de rol van Product Owner of Scrum Master met andere rollen, laten we onszelf en iedereen die door onze resultaten beïnvloed worden, een plezier doen en de focus en commitment afgeven naar organisatie, team, product en stakeholders vanuit één rol, één focus. Ondanks dat het niet ‘verboden’ is om rollen te combineren, zullen we het er allemaal mee eens zijn dat alle negatieve effecten het niet waard zijn en we deze normaal gesproken vermijden in bedrijfsvoering. Laten we dat dan ook doen als het gaat om het combineren van de rol van Scrum Master en Product Owner.
Wil je meer weten over Scrum, blijf dan de site en social media in de gaten houden, Ik deel hier regelmatig nieuwe artikelen. Je kunt je ook aanmelden voor een van mijn workshops.