Agile + Scrum ≠ Teamwork

Columns

Wat vind je cooler: Battlestar Galactica of Startrek? Je hoort erbij als het de laatste is. Dan ben je een geek en geen IT-nerd. Daar kwam ik achter toen ik me als adviseur verdiepte in wat software ontwikkelaars zoal drijft.Hoewel ik helemaal niks heb met science fiction, werd ik hierdoor wel getriggerd om me meer in de wereld van software ontwikkelaars te verdiepen.

In die wereld word steeds meer ‘agile’ gewerkt, vaak in de vorm van Scrum. De basis ligt in het Manifesto for Software Development. Ik vind scrum een fantastische iteratieve methode van projectmanagement die eenvoud, voortschrijdend inzicht, co-creatie, multidisciplinariteit, zelforganisatie en teamwork faciliteert, alles met als doel zo veel mogelijk toegevoegde waarde te leveren voor de klant.

Toch kan het nog steeds voorkomen dat het teamresultaat achter blijft. Hoe goed en fanatiek deze IT-ers ook zijn in hun vak, hoe nauwgezet ze het ideale scrumproces ook volgen, hoe ervaren de Scrum Master (Scrum-procesbegeleider) ook is, hoe agile de werkcontext ook is. Hoe dat komt? Dat komt door het feit dat we te maken hebben met mensen.

'Mensen'. Generaliserend: mensen die graag mooie software bouwen, vaktechnisch zeer ambitieus zijn en vaak ook nog kritisch en eigenwijs. Die, als ze moeten kiezen, inhoud boven relatie kiezen. Ruimte nodig hebben. En allerlei andere menselijke deugden en ondeugden hebben. Die meestal niet gewend zijn aan samenwerken, verantwoordelijkheid nemen voor het teamresultaat, elkaar feedback geven, aanspreken, hulp vragen, noch aan het geven van updates over de voortgang. Want daar was de(project-) manager meestal verantwoordelijk voor.

En zet die mensen dan in een resultaatverantwoordelijk Scrum team. Dan vertonen ze hetzelfde groepsgedrag als in ieder ander resultaatverantwoordelijk team. Tuckman onderscheidt vier fasen van teamontwikkeling, waar ieder team doorheen moet: forming, storming, norming en performing.

De patronen in de samenwerking verschillen per fase en hebben een ding gemeen: het gaat altijd over de kwaliteit van de interactie tussen mensen. En die kun je niet in een scrumtool of -proces gieten, dat lukt zelfs een Scrum Master niet. Tastycupcakes.org biedt dan geen soelaas. Om als team te kunnen groeien heb je weken, maanden of nog langer van samenwerken, conflicten en problemen nodig, die dienen als leermateriaal. Geen scrumtool kan dat versnellen. Je moet er gewoon doorheen.

Dus, beste scrummende mensen, als resultaten achterblijven, zou je ook es naar de kwaliteit van de samenwerking kunnen kijken. Los van het werken aan een goed scrumproces, een opdrachtgever die agile ‘is’ en een fijne Scrum Master.

Onderstaand de  vragen waarmee je gezamenlijk kunt onderzoeken wat er nou eigenlijk echt aan de hand is.

De kwaliteit van de samenwerking?

  1. Meetlat: User stories geven aan wat het gewenste teamresultaat is op korte termijn. Is ook duidelijk wat er op langere termijn wordt verwacht van het team? En door wie? Weet iedereen dat? Is ook duidelijk wat er van elkaar wordt verwacht? Is duidelijk welke samenwerkingscompetenties nodig zijn? Wat is ieders persoonlijke belang in de sprint en hoe verhoudt deze zich tot het gemeenschappelijke (klant-) belang?
  2. Eigenaarschap: In hoeverre voelt een ieder zich verantwoordelijk voor de kwaliteit van de samenwerking? Uit welk gedrag blijkt dat? Neem je verantwoordelijkheid voor je eigen gedrag of ligt het aan de ander? Is het willen of moeten?
  3. Doen, denken, willen: Is datgene wat je als teamlid doet in de samenwerking, in lijn met wat je denkt en voelt? Zo nee, wat in jou is daarvan de oorzaak?
  4. Zie je patronen in de samenwerking die niet effectief zijn?Waarin zit je ‘gevangen’ als team? Wat is de winst om het lekker zo te blijven doen, wat levert het op?

Moeilijke vragen nietwaar, vooral de laatste vraag is. De Scrum Master voelt zich vaak de meest aangewezen persoon om hiermee aan de slag te gaan. Dat kan prima, mits hij zich bewust is van zijn eigen invloed op de teamdynamiek. Hij is onderdeel van het systeem. Soms kan het dan helpen om een buitenstaander in te schakelen. Die als een nieuwsgierig, buitenaards wezen oprechte vragen kan stellen over datgene wat het team als normaal is gaan beschouwen.

Heel veel succes mensen! Van welke planeet komen jullie?

Kom met uw praktijkervaringen op het terrein van managen en organiseren

Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)

Word een pro!

SCHRIJF MEE >>

Ben Linders
Een mooi compact en praktisch artikel, waarmee teams direct aan de slag kunnen. En ook zeer herkenbaar, Esther!

De vragen die je noemt kan een team zichzelf stellen, bv. tijdens of direct na een stand-up, of in een retrospective als teruggekeken wordt hoe de sprint is gegaan. Het leuke van Agile & Scrum is dat je de acties die je als team afspreekt nog dezelfde dag, of in de volgende sprint al doet. Continu verbeteren dus, op een efficiënte manier.
Esther Visser
Fijn Ben, het was ook bedoeld als praktisch artikel. En ja, zeker kun je hier zelf als team mee aan de slag. Wel kan het voorkomen dat het team nog niet toe is aan dit soort vragen, of nog niet de vaardigheid heeft om er als team aan te werken, of niet de veiligheid in zich heeft die nodig is voor dit soort vragen. Scrum vraagt nogal wat aan samenwerkingscompetenties, taakvolwassenheid en reflectievermogen in teams. Dus ja, de retrospective lijkt met een prima moment om deze vragen te stellen. Ze zijn dan echter alleen effectief als het team al een behoorlijke 'maturity' heeft. Voor veel teams geldt dat iemand van buiten het team beter in staat is om te zien wat er daadwerkelijk aan de hand is. In het echie gaat alles niet meteen de volgende dag beter en efficienter, de interactie tussen mensen is geen bug die je in 1 retrospective kunt fixen:)!

Meer over Team ontwikkeling