Onze collega Marjolein van Gelderen is enige tijd geleden als Scrum Master met een, voor haar, nieuw team begonnen. Hoewel het team in het verleden al successen behaald had merkte ze al snel dat het niet meer zo lekker liep. Wat er aan de hand was en hoe ze hier samen met het team een oplossing voor vond beschrijft ze in deze blogpost!

Bij sommige teams is de lijst van problemen lang. Teamleden die hun rol niet goed vervullen, onderlinge fricties, planningen die niet gehaald worden, werk dat niet naar tevredenheid wordt opgeleverd, vingerwijzen naar elkaar dat daardoor ontstaat en zo kan ik nog wel even doorgaan.

Er zijn gelukkig voldoende instrumenten om dit aan te pakken. Vaak wordt er gegrepen naar de varianten die direct ingaan op samenwerken en onderlinge relaties, en inzoomen op onderlinge communicatie. Maar wat als het vertrouwen er simpelweg nog niet is? En hoe kom je tot vertrouwen?

Bij teams waar deze basis ontbreekt kan het heel effectief zijn om opnieuw te beginnen en hardop uit te spreken dat we gaan werken aan vertrouwen met het doel om als team weer in staat te zijn ons te committeren aan onze afspraken.

En zo was de praktijk in mijn team: Omdat we ons realiseerden dat waar we als team stonden ons niet beviel, spraken we af om het de komende program increment (periode) compleet anders te doen. Kortom: veel aandacht aan de verbetering van onze teamdynamiek in een overzichtelijke periode. In onze situatie hebben we afgesproken dat één persoon zich committeerde om aandacht te geven aan onze teamdynamiek en ons zo te faciliteren dat we samen een nieuwe basis voor vertrouwen konden leggen. En zo geschiedde…

Om onze doelen te realiseren was er commitment nodig. Van het team zelf, maar ook van de omgeving, zoals andere teams en het management. Het moest ook duidelijk worden dat bij een zuchtje tegenwind of een ongewenste uitkomst er door ons niet weer van de route afgeweken zou worden. Want: onze voorspelbaarheid moest verbeteren. Mijn collega’s konden dit commitment echter alleen geven wanneer er sprake is van vertrouwen, en dat was precies wat er ontbrak. Dus daar heb ik met het team als eerste aan gewerkt.

De eerste stap naar het vertrouwen die wij gezet hebben is zorgen voor transparantie. Een nieuw bord werd gemaakt en een helder overzicht gecreëerd van waar elk teamlid mee bezig was. Elke stand-up werd weer teruggebracht naar de basis: wat is er gedaan, wat ga je doen, heb je nog hulp nodig of verwacht je problemen? Hierdoor bleef het bord up-to-date en kon iedereen de status van het werk voor het team zien. Een eenvoudige en herkenbare actie die al heel snel tot verbetering leidde.

Nu de transparantie er was konden we aan de slag om afspraken te maken over samenwerking met onze omgeving. Door duidelijkheid te scheppen over hoe wij als team werk aangeleverd willen hebben en actief samen met onze omgeving te prioriteren kwamen we tot een basis om betrouwbaar te leveren. Doordat wij als team vervolgens onze producten weer volgens verwachting opleverden aan onze gebruikers, creëerden wij een basis voor een hernieuwde samenwerking. Dus door duidelijk af te spreken aan welke eisen een userstory of feature moet voldoen en daar ook geen concessies meer op te doen zorgden we ervoor dat we betrouwbaar konden leveren en daardoor een betrouwbare partner werden.
Juist die betrouwbaarheid werd voor ons de belangrijkste basis voor het vertrouwen waar het team en onze stakeholders behoefte aan hadden.

Immers, als je goed weet wat je van de ander mag verwachten en het komt volgens verwachting, dan wordt elkaar vertrouwen eenvoudig(er). Hierbij is het belangrijk om te weten dat je van de ander op aan kan, ook als het even minder makkelijk is. Doordat we betrouwbaar gingen leveren, werden we ook opener voor onze omgeving en was iedereen continu tijdig op de hoogte van wat er gaat gebeuren. Hierdoor hebben we onze omgeving werkelijk de kans gegeven om ons te steunen en mee te besluiten wanneer er obstakels zijn, en groeide het draagvlak. Het werkelijk open zijn was een onderdeel dat in het begin nog best lastig was, maar waar we goed mee hebben geoefend. Het zo snel mogelijk delen van (potentieel) negatieve uitkomsten geeft onze omgeving de kans te anticiperen en samen risico’s te mitigeren.

De uitkomst was dat het team al na een aantal weken een meer ontspannen samenwerking liet zien. Problemen werden aangekaart en twijfels over aanpak werden besproken. Men ging elkaar om hulp vragen en er werd hulp aangeboden. We konden tijdig ingrijpen op frustraties en creëerden daarmee ruimte om het weer over de oplossing te hebben. Maar het mooiste effect is dat in en rondom het team er steeds meer plezier in het werk was en de humor weer terug is gekomen.

Omdat het team nu weer vanuit vertrouwen werkt hoeft niet elk detail meer besproken te worden met iedereen. Niet iedereen hoeft meer bij elke e-mail of afspraak betrokken te worden. Immers: als je nodig bent dan weten wij je te vinden en als het belangrijk voor je is dan brengen we je op de hoogte. Al deze tijd en energie kunnen we nu gebruiken op het effectief leveren.

Al het bovenstaande heeft uiteindelijk bijgedragen aan een behoorlijke boost van de kwaliteit. Het werk wordt op tijd opgeleverd (dit kostte mij taart, want al het werk uit de sprint was aan het einde af). Dat maakte de gebruikers zo blij dat er complimenten tijdens de demo werden geoogst omdat men blij is met de realisatie van goede producten. En onze gebruikers worden op hun beurt weer gemotiveerd om steeds vaker spontaan in de lucht te komen om te zorgen dat hun wensen op een goede manier aangeleverd worden en echt begrepen worden.

Het allergrootste compliment kwam van één van de “uitgebluste” teamleden die ik aan de start van mijn opdracht aantrof: “We zijn sinds jaren echt een team!”

De aanpak vanuit één persoon die aan de verbetering van het team werkt is vandaag de dag verdwenen. De komende periode werk ik minder en de waarneming van mijn taken heb ik vol vertrouwen overgedragen aan het team, dat de smaak van het continu verbeteren helemaal te pakken heeft.

Mocht je een keer met Marjolein willen sparren over dit, of een ander onderwerp, stuur dan een mail naar info@towson.nl of neem telefonisch contact met ons op!

Onze collega’s lopen in hun opdracht regelmatig tegen zaken aan die de moeite van het delen waard zijn.
Zo stapte Flip de Vries onlangs bijna in de valkuil van té klantgericht te willen zijn met het gevaar dat je hierdoor helemaal niet meer zo klantgericht bent.

Ondanks dat ik denk over een ruime mate van kennis en ervaring als Product Owner in het Agile werken te beschikken, ben ik kortgeleden toch bijna in een traditionele valkuil gestapt. Namelijk die van het opbreken van de incrementplanning om een stakeholder tevreden te stellen. Een kortetermijn win met grote gevolgen voor de betrouwbaarheid van het ontwikkelteam en tevredenheid van het stakeholdersveld.

Omdat ik denk dat het iedereen op een onbewaakt moment ook zou kunnen gebeuren, wil ik jullie in dit artikel kort meenemen in onze situatie.

Enkele weken geleden hebben we tijdens onze PI planning een goede planning voor de komende 4 sprints uitgewerkt met commitment van het hele team. Deze planning was inclusief enkele externe koppelingen ten behoeve van een belangrijke mijlpaal voor één van onze stakeholders. Kortom: geheel in lijn met wat alle stakeholders van ons verwachten.

In onze eerste sprint bleek de externe partij haar deel van de koppeling eerder klaar te hebben. Het leek ons (SM en PO) een goed idee om deze partij te belonen voor de snelheid en de feature met de externe koppelingen direct op te pakken. Hiermee wilden we ruimte creëren in de volgende sprint, zodat we tegenvallers, die mogelijk naar voren zouden komen in opgeleverde koppelingen, op konden vangen. Daarnaast zou er meer tijd ontstaan voor testen en het aanpakken van test bevindingen. De andere werkzaamheden vanuit sprint 1 zouden dan doorschuiven naar sprint 2 of 3, waarin de koppelingen aan onze kant gereed zouden zijn. Voor ons een logische stap, aangezien de koppelingen het belangrijkste doel waren voor het increment en we daarmee een belangrijke stakeholder heel blij zouden maken.

Toen we dit plan bespraken met onze RTE en Product Manager bleken die minder enthousiast. Zij wezen ons op het feit dat we niet zomaar de planning aan kunnen passen, om één van onze stakeholders tevreden te stellen. Hiermee zouden we als team onbetrouwbaar worden in onze huidige en toekomstige leveringen. Ook zouden we onrust creëren in het team door niet alleen een PI planning om te gooien, maar tevens ook een sprintplanning; beide onderdelen die in nauw overleg met het team zijn opgesteld en waar het team haar commitment voor had uitgesproken.
Daarnaast hadden we de afhankelijkheid van de kwaliteit van de externe koppelingen en daarmee samenhangende mijlpalen voor de stakeholder duidelijk besproken tijdens de risicosessie van de PI planning- met als uitkomst enkele maatregelen om het risico te mitigeren.

Al met al dus geen enkele reden om de planning te wijzigen voor kortetermijngewin; het leverde risico’s voor de toekomst met betrekking tot commitment en moraal van het ontwikkelteam, en daarnaast ook voor onze zorgvuldig opgebouwde relatie van betrouwbare partner richting het stakeholderveld.

Blij dat we het niet gedaan hebben en blij met de niet gemaakte fout 😉

Neemt jouw team verantwoordelijkheid of neemt men genoegen met vrijblijvendheid?

Elk individu of elke groep was of is wel ergens verantwoordelijk voor (geweest). In het geval van teamontwikkeling is het nemen van verantwoordelijkheid het op een na hoogste niveau dat een team moet overwinnen voordat het als team echte resultaten kan boeken.
Het nemen van teamverantwoordelijkheid blijkt voor teams een lastige, maar ook bevredigende stap om te maken. Het is een constante paradox waar ik steeds weer mee te maken krijg tijdens mijn coaching, waarbij het geen verschil maakt of ik managers of medewerkers coach, een kleine afdeling of een groot team in een grotere organisatie.

In alle gevallen is de regel dat het team eerst de eerder besproken complicaties van Lencioni heeft moeten overwinnen (vertrouwen en aanspreken) om de horde “verantwoordelijkheid nemen” te kunnen overwinnen. Daarnaast zal het team afscheid moeten nemen van de lage standaard van vrijblijvendheid en hiertoe eerst moeten begrijpen wat begrijpen wat verantwoordelijkheid echt is.

Wat betekent verantwoordelijkheid:

In de basis houdt het dragen van verantwoordelijkheid in dat er verantwoording moet worden afgelegd waarbij je verantwoordelijkheidsgevoel ervoor zorgt dat je je persoonlijke plicht naar behoren wil uitvoeren. Maar wat betekent verantwoordelijkheid nemen nu eigenlijk in een team? Want: eerlijk is eerlijk, verantwoordelijkheid nemen is een van de meest verwarrende begrippen in de onderlinge communicatie binnen teams.
In teams kun je mensen tegenkomen die een zeer hoog verantwoordelijkheidsgevoel hebben. Zo hoog zelfs dat het gevaar ontstaat dat ze bewust of onbewust het “duik”-ontwijk) gedrag van anderen compenseren omdat ze het alleen voor het hoogste doel gaan. Dit zorgt ervoor dat niet iedereen zijn of haar verantwoordelijkheid kan of wil nemen.

Beter is het om juist dat te doen doen wat vooraf is afgesproken in het team: zo kan iedereen zijn of haar verantwoordelijkheid nemen op basis van de gemaakte afspraken.
Dat biedt een basis om met elkaar te evalueren of afspraken gehaald worden, maar ook wat iedereen er individueel aan doet om de afgesproken bijdrage aan het resultaat daadwerkelijk te leveren.

Gebrek aan verantwoordelijkheid in een team:

Vanuit de rol van leidinggevende hoort het bij je taak medewerkers aan te spreken op hun verantwoordelijkheid. Het aanspreken van je directe collega’s in het team is vaak een stuk lastiger. Werk daarom ook continu aan de lagere complicaties van Lencioni; vertrouwen en aanspreken (“healthy conflict”). Dit leidt tot de echte betrokkenheid binnen het team.

Door gebrek aan echte betrokkenheid en engagement gaan teamleden het nemen van verantwoordelijkheid mijden. Het teamplan moet daarom duidelijk zijn en van harte worden ondersteund want als dit niet het geval is leidt dat er toe dat collega’s minder vaak of aarzelend tot verantwoording geroepen zullen worden. Door elkaar niet meer ter verantwoording te roepen ontstaat het gebrek aan verantwoordelijkheid in het team en zakt het weg naar vrijblijvendheid.

Hoe help je een team verantwoordelijkheid te nemen

Om een team zover te krijgen dat de leden hun verantwoordelijkheid nemen of zich op dit punt ontwikkelen kan je aan de volgende mogelijkheden denken:

• Duidelijk communiceren van doelstellingen en maatstaven: Wanneer hier keer op leer over gesproken wordt kunnen teamleden deze niet meer negeren.
• Door structureel overleggen in te plannen waarin teamleden elkaar feedback geven en bespreken hoe de teamleden functioneren teneinde de vastgestelde doelstellingen te behalen.
• Stoppen met individuele beloning en vervangen voor een teambeloning. Dit kan dan weer zorgen voor een gezamenlijke verantwoordelijkheid. Wanneer een teamlid niet goed functioneert, wordt het belang om diegene aan te spreken groter om te voorkomen dat doelstellingen niet gehaald worden.

De werkelijke sleutel is zorgen dat teamontwikkeling voortdurend aandacht heeft. Het is van belang dat het team zich continu realiseert dat het succes een teameffort betreft, maar ook dat het falen eveneens een teamwanprestatie betreft.

Goal:
Identify, classify and effectively manage your stakeholders

Duration
45-90 minutes

Group size
Game could be played with individuals, pairs or groups and is easy to scale up. Ideal group size is up to 6 people. More Participants? Just make two groups and do the game in parallel

Preparation
Buy a brown paper or white board paper and markers. Bring lego figurines or play mobile, chess pieces with you. Draw a stakeholder map with two axes ‘interest’ and ‘influence’

Game description
Start the game with a short discussion about what customers and stakeholders are and discuss what the benefit of good customer and stakeholder management is. Explain the game and stakeholder map to the group so all the participants understand the goal and rules of the game. Subsequently ask the participants the following questions:<!— wp:paragraph –>

1. What is your general stakeholder message?
2. Who are your stakeholders?
3. How would you qualify the stakeholders in terms of influence and interest? Plot your stakeholders on the stakeholder map (as-is).
4. What is the desired state/qualification of your stakeholders? Draw a line on the map which displays the direction in which your customers and stakeholders should move (to-be).
5. How would you manage your customers and stakeholders? Determine a strategy for each stakeholder (group).

If there is more time you could ask how you would like to go about with your communication strategy towards your stakeholders.

Let participants share their insights and summarise the goal and outcomes of the game.
Enjoy and success with managing your stakeholders.