Skip to main content
De valkuil van te klantgericht willen zijn: Onze collega’s lopen in hun opdracht tegen zaken aan die de moeite van het delen waard zijn. De valkuil van te klantgericht willen zijn: Onze collega’s lopen in hun opdracht tegen zaken aan die de moeite van het delen waard zijn. De valkuil van te klantgericht willen zijn: Onze collega’s lopen in hun opdracht tegen zaken aan die de moeite van het delen waard zijn.

De valkuil van te klantgericht willen zijn

Geschreven door admin op . Gepost in Blog, Coaching, Teamontwikkeling.

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 😉

Pyramide van Lencioni: Verantwoordelijkheid. Neemt jouw team verantwoordelijkheid of neemt men genoegen met vrijblijvendheid? Lencioni's.. Pyramide van Lencioni: Verantwoordelijkheid. Neemt jouw team verantwoordelijkheid of neemt men genoegen met vrijblijvendheid? Lencioni's.. Pyramide van Lencioni: Verantwoordelijkheid. Neemt jouw team verantwoordelijkheid of neemt men genoegen met vrijblijvendheid? Lencioni's..

Pyramide van Lencioni: Verantwoordelijkheid

Geschreven door admin op . Gepost in Blog, Coaching, Teamontwikkeling.

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.

Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik

Teamcoaching met Lencioni: Commitment; ook wel “betrokkenheid”

Geschreven door admin op . Gepost in Blog, Agile, Coaching, Teamontwikkeling.

Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding.

Te allen tijde wil ik voorkomen dat gegevens verborgen blijven. Ik heb liever openhartige debatten. Pas wanneer iedereen zijn standpunten en perspectieven naar voren brengt, kan een team met vertrouwen een beslissing nemen.
Tijdens mijn coaching gebruik ik de piramide van Lencioni (elk niveau komt voorbij in een aparte post): in mijn eerdere posts heb ik mijn kijk gedeeld op vertrouwen en constructieve conflicten.
Deze blog gaat over betrokkenheid, het derde niveau binnen de pyramide van teamontwikkeling. Wat heeft het ontbreken hiervan te maken met de volgende frustratie in een team? Een niet te onderschatten invloed!

In elk team heeft elk teamlid een zekere mate van oppervlakkigheid. Anders zou er ook geen mode industrie- of schoonheidsindustrie bestaan: we vereren jeugd, en willen daar zo lang mogelijk deel van uitmaken. Als ik eerlijk ben heb ik dit ook eerder als mechanisme ingezet om mij te beschermen tegen alles wat pijn zou kunnen doen of niet leuk is. Maar klopt mijn aanname wel? Oppervlakkigheid behoedt je namelijk wel voor heel wat teleurstellingen.
Als je ‘meer’ verwacht, loop je ook het risico dat dingen tegenvallen (en dat doen ze vaker wel, dan niet). Dat gaat op voor kunst, aspiraties, de liefde, noem maar op. Maar hoe oppervlakkig dit ook voelt- in de hedendaagse maatschappij toont Schoonheid je geschiktheid als partner, collega en/of geschikte medewerker en vormt zo de basis van onze evolutie. Je moet er niet aan denken hoe we eruit zouden hebben gezien als onze voorouders.

Tijdens mijn coachopdrachten loop ik (dagelijks) in de omgang tegen oppervlakkigheid aan. Wat is dat precies? Zodra men niet wil of durft om zaken met diepgang te bespreken, te schrijven of te bedenken. Het kan naar voren komen tijdens oppervlakkige gesprekken of onderzoeken. Wanneer zaken letterlijk aan de oppervlakte blijven, of men het gevoel krijgt dat we als team oppervlakkig blijven. Als er bij de samenwerking oppervlakkig wordt gesproken, geschreven of besloten.

Binnen de context van teams is betrokkenheid een functie van twee zaken; duidelijkheid en steun. Bij goed functionerende teams worden tijdige en duidelijke beslissingen genomen.
In echte teams wordt met volledige instemming gewerkt van alle teamleden, ook van de teamleden die tegen besluiten hebben gestemd. Na het einde van elke meeting/vergadering beseft iedereen dat er geen enkel teamlid twijfelt over de genomen keuzes.

De twee belangrijkste oorzaken van gebrek aan betrokkenheid zijn het verlangen naar contentie en de behoefte aan zekerheid. Ook bij goed functionerende teams weet ik dat het gevaarlijk kan zijn om te intensief die consensus op te zoeken. Volledige overeenstemming is soms onmogelijk maar samen op zoek naar kleine manieren om steun te verwerven gaat sneller in goed functionerende teams. We weten allemaal dat je als persoon niet altijd je zin hoeft te krijgen, maar dat jij je zodanig kunt opstellen dat het toch mogelijk is om je achter een beslissing te scharen. Daardoor ontstaat de bereidheid om verder te gaan, ongeacht het groepsbesluit. Bij een mogelijke impasse is het aan de teamleider om dan de knoop door te hakken. Daarvoor is wel nodig dat het standpunt wordt aangehoord en uiteindelijk wordt meegewogen bij de besluitvorming. Bij zelf organiserende teams wordt ook dit door het team zelf genomen en in de traditionele gevallen wordt de manager of teamleider gevraagd om hulp.

De tweede eigenschap binnen goed functionerende teams die betrokken zijn is de hoge mate van zekerheid. Goed functionerende teams zijn vaak trots op de gehaalde doelen met elkaar en staan graag achter beslissingen. Zij engageren zich ook volledig met plannen.
Ook in het geval van weinig zekerheid nemen we besluiten met zijn allen en dus zijn wij met z’n allen verantwoordelijk voor het resultaat. In deze teams zie ik vaak terug dat elke beslissing beter is dan geen beslissing. Als je dit vergelijkt met slecht functionerende teams is de trend dat besluiten worden uitgesteld. Meestal ligt hier achter de zekerheid van het te nemen besluit (Is het nou goed wat we van plan zijn te gaan doen?). Hoe verstandig dit misschien ook lijkt, het kan leiden tot verlamming in het team. Het is ook van belang te beseffen dat de bereidheid tot constructieve conflicten ( zie eerdere post) de basis vormt voor de bereidheid tot engageren als sprake is van onvoldoende informatie.

Als je een team hebt waar de betrokkenheid minder is, is het tijd om aan de slag te gaan. Bedenk je: hoe gaat een team te werk dat eenheid wil creëren? Hiervoor kun je een aantal instrumenten inzetten. Denk hierbij aan gebruik van een besluitenlijst, deadlines, analyse van worst case -scenario’s (zorgt voor inperking van angsten), blootstelling aan lage risico’s (opeisen dat elke teamlid een besluit helpt nemen).
Als ik teams help om te betrokkenheid te vergroten zal ik als coach de groep voortdurend aansporen tot discussie rond problemen af te ronden en zich te houden aan de planning of het overeengekomen proces.
Tegelijkertijd probeer ik minder de nadruk te leggen op zekerheid en consensus.

Uiteindelijk wil ik dat mijn team als een eenheid optreedt en zich blijft ontwikkelen en fouten durft te maken. Kansen inzien of profiteren van kansen. Blijven handelen zonder aarzeling ook in geval van veranderingen of schuldgevoelens.

Niet vanuit het ‘ik’ en ook niet vanuit het ‘zij’ maar vanuit het ‘wij’ ontstaan de mooiste dingen.

Door Stanley Markiet, consultant bij Towson

Waarom zijn korte sprints beter? Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op. Waarom zijn korte sprints beter? Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op. Waarom zijn korte sprints beter? Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op. Waarom zijn korte sprints beter? Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op. Waarom zijn korte sprints beter? Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op.

Waarom zijn korte sprints beter?

Geschreven door admin op . Gepost in Blog, Agile, Coaching, Teamontwikkeling.

De sprint: een afgebakende korte tijdsperiode waarin teams aan de hand van vaste rituelen werk plannen en uitvoeren. Het hart van Scrum werken zoals de Scrum Guide het omschrijft.
Als scrum master sluit ik me daar helemaal bij aan. De sprint is namelijk één van de krachtigste tools om bottlenecks te ontdekken. Let wel; ontdekken, niet oplossen.

Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op.

De sprint verlengen is sowieso geen goed idee vanwege de volgende redenen:

  • Feedback komt later – Sprints verlengen betekent automatisch dat de feedback pas op een later moment komt, terwijl je juist feedback zo snel mogelijk wilt ontvangen om het mee te kunnen nemen in je volgende sprint.
  • Minder Agile – Kortere sprints betekent meer mogelijkheid om in te spelen op verandering. Hoe langer de sprint, hoe groter de kans dat de sprint open gebroken moet worden om nieuwe items met spoed op te pakken.
  • Minder verbeteringen – Als sprints langer zijn voelen teamleden al snel dat er meer tijd is om werk uit te voeren en ontstaat er minder drang om te verbeteren.
  • Prioriteren wordt moeilijker – Als sprints langer worden willen stakeholders al snel dat hun items in de eerst volgende sprint opgepakt worden, omdat ze anders voor hun gevoel te lang moeten wachten.

Langere sprints ≠ Minder overhead

Te vaak hoor ik als scrum master het argument voorbij komen dat langere sprints in verhouding minder “overhead” hebben dan kortere sprints. Maar dat is niet zo. De lengte van alle rituelen schalen namelijk mee volgens de scrum guide [1].

Timeboxes volgens de Scrum Guide

schema sprints Towson

Zo gaat de timebox voor de sprintplanning bijvoorbeeld van 4u naar 6u als je de sprint van twee naar drie weken verlengt. Dat klopt ook want je moet immers een extra week werk inplannen. Daarbij speelt ook nog eens dat hoe verder in de toekomst, hoe lastiger het inschatten is of je iets wel of niet op kunt pakken en af kunt maken. Je weet immers beter wat je morgen gaat doen dan wat je over drie weken gaat doen. De onzekerheid neemt toe naarmate de sprint langer wordt. De sprintplanning zal dus in verhouding eerder langer dan korter worden.

Vooral voor teams die niet dagelijks bij elkaar zitten is er nog een groot nadeel bij het verlengen van de sprint. Bij een tweewekelijkse sprint passen de review, de retrospective en de planning exact op één werkdag. Je kan dus zo een echte “sprintwisseldag” creëren waarbij iedereen op locatie aanwezig is.

Verleng je de sprint naar drie of meer weken dan passen deze drie rituelen niet meer op één werkdag en zullen ze over twee of meer werkdagen verspreid moeten worden.

Het is dan ook niet zonder reden dat het Agile Manifesto korte sprints als één van de belangrijkste principes noemt: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale [2]”.

De sprint verlengen? Voer dan eerst deze checklist uit

Speelt het team tegen beter weten in met het idee om de sprint te verlengen? Vul dan eerst onderstaande checklist in om te ontdekken of er een ander probleem speelt binnen het team:

☐ Het team is bezig met het uitvoeren van “mini-watervallen” (Eerst design, dan ontwikkelen en als laatste testen). Zie ook mijn eerdere artikel.

    • Het team heeft moeite met het splitsen van user stories.
    • Teammeetings zijn niet efficiënt.
    • Het team heeft moeite met deployments (incl. merge & integration).
    • Het team heeft niet genoeg ervaring met test driven development of andere quality practices.
    • Technical debt is zo groot gegroeid dat werk langer duurt.
    • Team werkt aan te veel items buitenom de sprint.
    • Skills en vaardigheden zijn niet goed verdeeld binnen het team waardoor het team afhankelijk is van één of enkele specialisten binnen het team.
    • Team werkt en worstelt met oude technologie.
    • Uitzoekpunten en antwoorden laten te lang op zich wachten.
    • Het team worstelt met afhankelijkheden buiten het team.

☐ De communicatie met teamleden die niet op locatie werken verloopt moeizaam.

  • Problemen met prioriteren of gebrek aan een actieve Product Owner.
  • Moeite met het concept van een MVP’s.
  • De product owner of stakeholders bemoeien zich met de sprint backlog tijdens de sprint.
  • Het team is bang om “niet genoeg” op te leveren aan het eind van de sprint aan de stakeholders.
  • Het team vreest te moeten overwerken om aan de commitment te voldoen.

[1] Bron: https://agilescrumgroup.nl/duur-scrum-meetings/
[2] Bron: https://agilemanifesto.org/iso/nl/principles.html

Door William van der Maas, consultant bij Towson

Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early” Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early” Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early” Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early”

Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes!

Geschreven door admin op . Gepost in Blog, Agile, Coaching.

Als Agile-enthousiast sta ik helemaal achter het statement “Fail early”. En om dan maar gelijk míjn interpretatie erbij te geven: dit betekent wat mij betreft niet “We doen maar wat en zien wel waar het schip strandt”, want dat is simpelweg slechte voorbereiding. De basis is goede voorbereiding die gewoonweg nodig is om een gewenst effect te behalen. Echter: wanneer de goede voorbereiding gedaan is komt de keuze; ga ik voor een eindeloos lange voorbereiding waar ik in theorie en in detail àlles wil voorbereiden, of ga ik van start. Dit is het punt waarop je je wat mij betreft over je koudwatervrees zet en van start gaat.

Ga je tegen zaken aanlopen die je niet had voorzien? Zeker! Maar dat zou je na de eindeloos lange voorbereiding ook zijn gebeurd, omdat je niet weet wat je niet weet totdat je het in de praktijk gaat proberen. Maar: omdat je een goede voorbereiding hebt gedaan kun je die tegenslag gelukkig goed aan. Daarnaast ben je wendbaar en veerkrachtig genoeg om een assessment te doen: blijkt het idee in de praktijk een matig idee of is het een horde die ik met mijn team kan nemen.

Een ander oneliner waarop ik niet alleen voor mezelf, maar ook voor de mensen en teams waarmee ik werk heel streng in ben, is: “Liever af en toe vragen om vergeving achteraf, dan constant vragen om toestemming vooraf”. Wat mij betreft is dit een basishouding die je heel hard nodig hebt om enerzijds tot zelfsturende teams en organisaties te komen, en anderzijds om de motivatie in je organisatie te houden.
Organisaties waar je constant op toestemming aan het wachten bent zijn voor de meeste mensen niet de leukste organisaties om in te werken. De reden is simpel- het gaat rechtstreeks in tegen 1 van de 3 pijlers voor gelukkige werknemers, namelijk het hebben van autonomie. Tegelijkertijd is iedere keer toestemming vooraf eisen voor organisaties ook kostbaar want het leidt tot wachttijden waarin de kosten voor teams gewoon doorlopen en ze minder of zelfs niets realiseren. Je kunt dan dus bijna de businesscase maken “Wat is duurder? De kosten van het wachten, of de kosten van af en toe een fout?”

In mijn trainingen en coaching krijg ik vaak de opmerking dat het geven van de ruimte, om besluiten “laag” in de organisatie te nemen, een voornemen is waar vaak aan begonnen wordt, maar dat ook snel afgelopen is zodra er een fout wordt gemaakt. De manager neemt dan weer de traditionele rol van “besluitenmachine” op zich. Direct daarop volgt dan de vraag: “Hoe los jij dit dan op?”.
Het antwoord is kinderlijk eenvoudig: vier je successen!
Dat weer terugdraaien van autonoom besluiten nemen heeft een oorzaak- we zijn servicegerichte mensen. Servicegerichte mensen hebben naast een hele reeks goede eigenschappen ook een paar minder goede:

    • Dat wat goed gaat is “normaal”, en dat geven ze van nature weinig tot geen aandacht. Doe maar gewoon dan doe je al gek genoeg;
    • Wat fout gaat moet gefikst worden om te kunnen verbeteren en wordt volop aandacht gegeven.

Het gevolg is dat in een omgeving waar we bijzondere dingen doen, waar iedereen met eer en geweten en vol energie een bijdrage levert en waar het overgrote deel van wat we doen hartstikke goed gaat, de sfeer alsnog matig is. Dit komt doordat de focus vooral gericht is op datgene dat fout gaat.
Door in dezelfde omgeving actief stil te staan bij wat er goed gaat, collega’s te bedanken voor hun bijdrage en te vieren dat doelen behaald worden, ontstaat er een heel andere balans. Fouten worden (natuurlijk) nog steeds besproken: niet meer als het enige onderwerp, maar als een van de onderwerpen. Doordat er ook actief aandacht en waardering geschonken wordt aan de bijdrage is het vertrouwen van de mensen waarmee fouten besproken wordt groter, en kan er ook met een open vizier naar een oplossing gezocht worden. Door niet alleen de fouten, maar ook de successen te bespreken ontstaat er een sfeer waarin fouten gemaakt mógen worden. Wat mij betreft is dat een omgeving met een menselijke maat.

Jaren geleden was er al een filmpje van Prof. Sumantra Ghoshal met de titel “The smell of the place”, waarin hij in een prachtige metafoor zijn persoonlijke verhaal over empowerment mixt met zijn inzichten wat organisaties moeten doen om hun personeel de ruimte te bieden om te ontplooien, zelf besluiten te kunnen nemen en te leren. Het is een kort filmpje dat ik vaak laat zien en me nog altijd raakt. Hij beschrijft typisch de bedrijven waar ik zou willen werken omdat daar ruimte is om fouten te maken waardoor er een basis is om samen succesvol te zijn.
Daar waar hij het in een prachtige metafoor deed ben ik meer van de oneliners. Vandaar mijn stelling: Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes!

Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen.

Scrum in business: Op weg naar zelfsturende teams

Geschreven door admin op . Gepost in Blog, Agile, Coaching, Teamontwikkeling.

1. Introductie

De maatschappij, klantbehoeftes en -verwachtingen veranderen voortdurend. Daarnaast wordt de kwantiteit, snelheid en complexiteit van veranderingen steeds groter en zullen organisaties en medewerkers de komende jaren geconfronteerd worden met een continu veranderende omgeving.

Dit vraagt naast aanpassingsvermogen, om sterk leiderschap en teams die naast de uitvoering van de operationele werkzaamheden (running the business) in staat zijn om producten, diensten en werkzaamheden continu te verbeteren (changing the business).

In de praktijk blijkt dit een behoorlijke uitdaging en passen energiebedrijven, banken, verzekeringen, zorg- en onderwijsinstellingen steeds vaker de agile en scrum principes toe binnen hun dagelijkse operatie om veranderingen door te voeren.

De agile principes helpen organisaties relatief snel hun effectiviteit te vergroten door werkzaamheden te prioriteren en transparant te maken, in een vast ritme te werken, tijdig te evalueren, te investeren in medewerkers en tegelijkertijd de medewerkerstevredenheid te vergroten.

Bekende praktijkvoorbeelden zijn onder andere salesteams, HR-, communicatie- en marketing-afdelingen die met succes volgens de agile en scrum principes werken. Daarnaast wordt Scrum ook steeds meer ingezet bij het ontwikkelen van onderwijs, beleid en wet- en regelgeving of gericht bij het opstellen van bijvoorbeeld een jaarrekening.

In dit artikel wordt in het kort uitgelegd hoe je geleidelijk de agile en Scrum principes kan toepassen binnen de operatie en zelfsturende (Scrum) teams kunt ontwikkelen die in staat zijn om veranderingen door te voeren, te innoveren en producten te ontwikkelen.

2. Scrum in business

Het agile gedachtegoed en de scrum principes worden steeds vaker door organisaties in de operatie gebruikt om de effectiviteit en het aanpassingsvermogen van de organisatie, afdeling en teams te vergroten.

In de praktijk is het een uitdaging om de transitie te maken van regulier opererende teams naar teams die werken op basis van scrum principes. Onderstaand wordt beschreven hoe je stapsgewijs de transitie kunt maken naar zelfsturende (Scrum) teams.

2.1 Organiseer commitment en volg gezamenlijk de training

Voordat je start met de eerste stappen is het allereerst belangrijk om de juiste commitment en draagvlak bij het management, de medewerkers en de omgeving te creëren. Dit bepaalt in grote mate het succes.

Verder is het verstandig om klein te beginnen met medewerkers die enthousiast zijn en kunnen zorgen voor een goede start.

Vervolgens is het zaak om ervoor te zorgen dat iedereen de spelregels kent en dezelfde taal spreekt door een gedegen training te volgen waar de agile en Scrum principes worden uitgelegd en de koppeling met de praktijk wordt gemaakt.

In het kader van commitment is het tevens handig om het management kader ook deel te laten nemen aan de training of de training te laten volgen, zodat het voor het management inzichtelijk wordt hoe Scrum werkt en wat de voordelen ervan zijn voor de organisatie.

2.2 Benoem de Product Owner en Scrum Master

Na de training kunnen de Product Owner en Scrum Master benoemd worden die respectievelijk verantwoordelijk zijn voor het prioriteren van de Product Backlog en het oplossen van issues.

Een Product Owner dient inhoudelijk sterk, besluitvaardig en goed met stakeholders om te kunnen gaan. Een goede Scrum Master daarentegen dient goed te zijn in issue-management en in staat te zijn om het team op sleeptouw kunnen nemen en te coachen.

Belangrijk in de zoektocht naar een geschikte Product Owner en Scrum Master is om op zoek te gaan naar een match tussen de rol en de kennis en vaardigheden van een medewerker in plaats van een match tussen rol en bestaande functieprofielen. Uiteindelijk is de match tussen rol en medewerker succesvoller dan de match tussen rol en functieprofiel.

In het begin wordt de rol van Product Owner en Scrum Master vaak door een leidinggevende vervult of benoemd. Het komt ook voor dat de keuze wordt overgelaten aan het team. Hierbij is het van belang om te benadrukken dat de rol van Scrum Master en Product Owner geen hiërarchische rollen zijn en het team gezamenlijk verantwoordelijk is. Daarnaast is het goed om te beseffen dat rollen in de praktijk na verloop van tijd vaak rouleren en de rol van Scrum Master verandert in agile coach of team lead.

2.3 Stel gezamenlijk de Product Backlog op

Nu de Product Owner bekend is kan gestart worden met het opstellen van de Product Backlog en het inventariseren en prioriteren van de werkzaamheden. Vaak is het handig om voorafgaand aan het opstellen van de Product Backlog een stakeholdermap op te stellen om inzicht te krijgen in het speelveld en type stakeholders die betrokken dienen te worden bij het opstellen van de Product Backlog.

Vervolgens kan op basis van de behoeften van interne en externe stakeholders bepaald worden welke concrete producten en diensten opgeleverd dienen te worden.

De Backlog van een operationeel team of stafafdeling is vaak operationeler van aard dan de Backlog van een ICT afdeling en bevat veelal naast ICT-wijzigingen ook operationele wijzigingen zoals het opstellen van customer journeys, procesplaten en werkinstructies. Hoewel het de voorkeur geniet om op de Backlog alle items op te nemen, wordt in de praktijk vaak nog een onderscheid gemaakt tussen producten en wijzigingen gericht op het veranderen van de business (changing the business) en het uitvoeren van de dagdagelijkse werkzaamheden (running the business). Voorbeelden zijn operationele issues en het opleveren van maandelijkse rapportages.

Uiteindelijk dient de Product Backlog door de Product Owner geprioriteerd te worden. Hiervoor worden afhankelijk van het type organisatie, afdeling en team vaak verschillende criteria gebruikt waaronder business value, klanttevredenheid, impact en werkdruk. Tot slot is het handig om gezamenlijk met het team per Backlog item de relatieve omvang in te schatten alvorens gestart kan worden met de eerste sprint, zodat een goed beeld gevormd kan worden van de omvang van werkzaamheden.

2.4 Stel het Scrum Team samen

Nadat de backlog is opgesteld en geprioriteerd kan gestart worden met de verdere samenstelling van het Scrum Team. Idealiter bestaat het team uit “T-shaped” medewerkers of “generalized specialists”. Dit zijn medewerkers die naast een of meerdere specialismes tevens beschikken over andere vaardigheden en allround inzetbaar zijn. In de praktijk is het lastig om dit type medewerkers te vinden omdat medewerkers niet allemaal all-round zijn opgeleid en functieprofielen binnen organisaties vaak vragen om specialistische kennis, vaardigheden en ervaring.

Desalniettemin is het van belang om op zoek te gaan naar een match tussen de werkzaamheden op de Backlog, het team en de individuele medewerkers in het team. Het team is immers collectief verantwoordelijk en dient zelfstandig in staat te zijn om alle werkzaamheden die op de Product Backlog staan in nauwe samenwerking met de omgeving te realiseren.

Verder is het handig om alvast na te denken over de opleiding en training die het team en de individuele medewerkers binnen het team nodig hebben om zichzelf en de samenwerking binnen het team continue te verbeteren.

2.5 Bepaal het slagritme van de sprint

Tot slot is het van belang om op voorhand het slagritme te bepalen en de Scrum vergaderingen in te plannen. Het slagritme varieert vaak per organisatie, afdeling en team. Veel organisaties kiezen voor een vast ritme van 2-4 weken en houden in het begin strikt vast aan de scrum vergaderingen om de de agile scrum principes goed onder de knie te krijgen.

Naarmate het team volwassener wordt, worden vaak het slagritme, de frequentie en de duur van de vergaderingen aan de behoefte van de organisatie en teams aangepast. De Sprint Review wordt bijvoorbeeld ingekort en de Daily Scrum vindt om de dag plaats. In de praktijk houden teams vaak wel vast aan de Sprint Planning en de Sprint Retrospective. Beide vergaderingen geven het team richting en helpen het team om continue te kunnen verbeteren.

3. Scrum works

Het agile gedachtegoed heeft zich inmiddels bewezen en wordt steeds meer door organisaties en bedrijven toegepast binnen de operatie om effectieve zelfsturende teams te creëren en efficiënt veranderingen door te voeren.

Medewerkers zijn op basis van de agile en scrum principes niet langer individueel verantwoordelijk voor het uitvoeren van werkzaamheden, onderlinge verhoudingen worden minder hiërarchisch en er wordt verwacht dat medewerkers hun expertise inbrengen en over de grenzen van hun eigen expertise heen kijken.

Scrum vraagt dus een nieuwe mind-set waar organisaties en medewerkers geleidelijk aan moeten wennen. De meest effectieve manier om hiermee om te gaan is om gezamenlijk het avontuur aan te gaan en te starten.

De komende weken zullen een aantal korte praktijkvoorbeelden gepost worden. Dus stay tuned…

Ben je na het lezen van dit artikel geïnteresseerd geraakt? Of vind je het leuk om ervaringen uit te wisselen? Neem dan contact op via info@towson.nl.

Agile Stakeholder game Towson: Identify, classify and effectively manage your stakeholders. Game could be played with individuals, pairs, groups and is easy to scale up. 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. Agile Stakeholder game Towson: Identify, classify and effectively manage your stakeholders. Game could be played with individuals, pairs, groups and is easy to scale up. 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. Agile Stakeholder game Towson: Identify, classify and effectively manage your stakeholders. Game could be played with individuals, pairs, groups and is easy to scale up. 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.

Agile Stakeholder game

Geschreven door admin op . Gepost in Blog, Coaching, Teamontwikkeling.

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.

teamcoaching teamcoaching teamcoaching teamcoaching teamcoaching

Teamcoaching met Lencioni: Zoek conflicten op en neem afscheid van de kunstmatige harmonie

Geschreven door admin op . Gepost in Blog, Agile, Coaching, Teamontwikkeling.

In mijn vorige artikel heb ik geschreven over vertrouwen. Dit is de basis voor een goede samenwerking en voor open communicatie omdat je dan kwetsbaar durft te zijn.
Alleen binnen teams waar het vertrouwen goed is kunnen we de volgende stap richting een goede samenwerking nemen.

Wanneer we niet kwetsbaar kunnen zijn en open kunnen communiceren, zal de kans op een ongezond conflict (ruzie) exponentieel toe nemen waardoor men afziet van een ongeremde, open discussie met elkaar. Als deze discussie er wel is en we standpunten kunnen delen en belichten met het doel samen iets te bereiken, noemen we het een gezond conflict.
We bespreken zaken open en nemen op basis hiervan samen besluiten waar we als team achter kunnen staan, juist omdat we de standpunten hebben gedeeld en uitgedaagd.

Teams waar het vertrouwen goed is kunnen deze volgende stap nemen.
In de piramide van Lencioni noemen we dit “het gezonde conflict durven opzoeken met elkaar”.

piramide-teamcoaching

Gezond conflict

Vaak worden conflicten als iets negatiefs gezien terwijl dit zeker niet aan de orde is.
Het is pas negatief wanneer een conflict te hoog oploopt en destructief wordt voor de samenwerking met elkaar.
Vaak is de basis van een negatief conflict “gelijk willen krijgen”, met als gevolg dat collega’s elkaar binnen de afdeling of binnen het team niet meer durven aan te spreken en dat ze elkaar minder zullen vertrouwen. Ieder gaat zijn eigen weg en er ontstaat een kunstmatige harmonie. Nergens is er sprake van conflict, of interesse in elkaar of in de gezamenlijke doelen.

We willen het conflict juist gebruiken om elkaar te begrijpen door elkaar uit te dagen op standpunten dan wel op een positieve manier waarbij wij ruimte laten zodat iedereen in zijn waarde kan blijven. Het conflict kan hier worden gezien en toegepast als middel om het vertrouwen in een team te versterken. Het wordt de basis voor het creëren van betrokkenheid en het nemen van eigenaarschap binnen het team.

Conflictstijlen

In de praktijk zijn er meerdere fasen en stijlen van conflicten- denk hierbij aan bijvoorbeeld toegeven, vermijden, exploreren of doordrukken. Elk van de stijlen van conflicthantering kan zich manifesteren tussen collega’s of teams. Afhankelijk van de karakters van de betrokkenen, het eigenbelang of het belang van de ander kan een bepaalde stijl zich nadrukkelijker manifesteren.

Het is goed om voor jezelf te bepalen welke stijl wenselijk is bij de specifieke situatie. Uiteindelijk moet ieder wel de wil houden om er samen uit te komen. Want je bent onderdeel van het team en nog steeds samen verantwoordelijk voor een doel.
Blijf dus hoe dan ook op zoek gaan naar een win-win situatie; tenslotte wil je met elkaar verder. Win-Win betekent overigens niet altijd compromissen.

Maar de persoon of partij die niet het gewenste resultaat krijgt moet wel de kans hebben om goed te begrijpen en te kunnen accepteren dat de keuze goed is voor het halen van het team is waar we allen toe behoren. Hiermee behoud je de relatie met elkaar en voorkom verkrampte reacties.

Wanneer binnen een team sprake is van een constante behoefte aan consensus lijkt alles bespreekbaar. Het continu kiezen voor de veilige middenweg, met de mindset “kan iedereen zich hierin vinden”, veroorzaakt uiteindelijk vooral gevoel van vaagheid over de richting en uiteindelijk is er nooit sprake van heldere prioriteit. Dit gaat direct ten koste van de betrokkenheid van de collega’s in het team en daarmee het wel of niet nemen van persoonlijk eigenaarschap. Teamleden zullen steeds minder offers brengen en dit kan zelfs doorschieten in opportunisme (eigen gewin) of ongeloofwaardigheid om ooit als team tot de beste resultaten te komen.

Kortom: zonder gezond conflict gaan teamleden twijfelen over de juistheid van genomen beslissingen.

Gaspedalen

Binnen mijn eigen opdrachten ben ik ook situaties tegengekomen waarbij ik te maken had met eigen vaste patronen. Ieder mens heeft vaste patronen die we allemaal bewust en onbewust toepassen in ons gedrag en onze communicatie. Ik noem ze ook wel onze “gaspedalen”. De vier gaspedalen zijn: -D(direct). -I(inspirerend). -S(supporting), -C(correct).
Door oefenen kan iedereen deze gaspedalen naar behoefte harder of zachter intrappen.

Naar gelang de situatie ben je vrij om te switchen tussen deze pedalen. Het helpt mij persoonlijk om de verbinding op te zoeken met mensen die van nature een ander gaspedaal dieper indrukken dan ik onbewust doe. Door dan wat anders “gas te geven” kan ik beter contact maken en daardoor ook beter omgaan met conflicten in mijn team of met mijn gesprekspartner. Mijn eigen natuurlijke voorkeursgedrag is “mensgericht”, iets wat niet goed of fout is, maar in situaties waar men juist heel “taakgericht” is zou ik minder effectief kunnen zijn. Wanneer ik mijn communicatie dan niet wijzig zal de kans op onbegrip, wrijving of conflict toenemen.

Sinds ik het DISC-model heb ontdekt gebruik ik het ook bij mijn teamcoaching.
Ik leer de mensen die ik coach onderling ook actief gebruik te maken van de gaspedalen die we van nature misschien niet zo snel intrappen. Hierdoor beginnen we elkaar beter te begrijpen en soms zelfs beter te waarderen en dat helpt dan weer de onderlinge communicatie te verbeteren. Doordat er ruimte ontstaat om waardering te oogsten terwijl je jezelf bent, stimuleert het ook het benutten van talent en vergroot het de individuele effectiviteit binnen het team.

Iedereen heeft sterke kanten die ons uniek maken waarvoor we graag erkend willen worden, met de erkenning van onze sterke kanten. Echter, elke sterke kant, indien overmatig of onjuist toegepast, kan ook worden gezien als een zwakke kant en daarmee verval je in overcompensatie en ongezond conflict. Kortom: balanceren, en bij elkaar blijven toetsen, is de sleutel.

Ik help mijn teams altijd de DISC-stijlen te herkennen door het observeren van de verbale en non-verbale communicatie. Zo vinden we bij de samenwerking snel de juiste handvaten om tot gezond conflict te komen. Als je je eenmaal bewust bent van elkaars communicatiestijlen, gedragsvoorkeuren en woordgebruik ben ik ervan overtuigd dat conflicten anders zullen worden beleefd. Dit zal dan weer helpen om afscheid te nemen van die kunstmatige harmonie waar we weinig aan hebben.

Ik nodig je van harte uit om te reageren en mijn posts te delen met anderen in je eigen netwerk.

Daarnaast geven collega’s en ik ook workshops rondom leiderschap en teamperformance.
Kijk eens op https://towson.nl/workshops voor meer informatie.

Stanley Markiet, consultant bij Towson

Teamcoaching met Lencioni: Hoe zit het met het vertrouwen in je team? Teamcoaching met Lencioni: Hoe zit het met het vertrouwen in je team? Teamcoaching met Lencioni: Hoe zit het met het vertrouwen in je team? Teamcoaching met Lencioni: Hoe zit het met het vertrouwen in je team? Teamcoaching met Lencioni: Hoe zit het met het vertrouwen in je team?

Teamcoaching met Lencioni: Hoe zit het met het vertrouwen in je team?

Geschreven door admin op . Gepost in Blog, Agile, Coaching, Teamontwikkeling.

Ondanks dat vertrouwen niet zichtbaar of grijpbaar is hebben we allemaal een begrip, maar ook vooral een gevoel bij het woord vertrouwen. Wanneer je het woord in een woordenboek opzoekt zal een volgende tekst verschijnen:
“Bereidheid van een persoon of groep om afhankelijk te zijn van de daden van een andere persoon of groep”.

Het is niet voor niets mijn eerste artikel: zonder vertrouwen is er geen sprake van een team. Daarom is het ook zo belangrijk om in de eerste fase van de teamvorming en de coaching van je teams zo nadrukkelijk stil te staan bij vertrouwen.

Wanneer teams gevormd worden hebben we het wel over een team, maar in feite is het nog een groep. In deze fase is het nog “los zand”. En dat komt omdat in een beginnend team de leden elkaar nog niet volledig vertrouwen. Per slot van rekening is er dan ook nog helemaal geen basis voor vertrouwen omdat je nog niet weet hoe afhankelijk je van de anderen kunt zijn of bent, dus hier is gelijk werk te doen.
En dat leidt dan gelijk weer tot de volgende vraag: Welk niveau van vertrouwen is nodig om onze doelen te behalen en om een effectief team te zijn waar eenieder zich in thuis voelt en graag in wil werken?

Angst

De bereidheid en het vermogen om je afhankelijk (kwetsbaar) op te stellen heeft veel aandacht in de eerste fase, maar het gaat natuurlijk om een continu proces. Bij vertrouwen gaat het niet alleen over krijgen maar zeker ook over vertrouwen bieden. Dit is onderdeel van mijn aanpak als teamcoach.

Er zijn elementen waaraan je heel snel kunt zien dat er sprake is van vertrouwen binnen een team. Er is binnen een team de bereidheid om te werken met de geldende (geschreven en ongeschreven) regels. Binnen dit team zijn mensen bereid hulpvragen aan elkaar te stellen, maar ook bereid om elkaar aan te spreken. Mijn ervaring is dat iedereen zich eerst veilig moet voelen en bekend moet zijn met elkaars gedrag. Neem als voorbeeld autorijden.
Als we zelf de verkeersregels kennen, de auto zelf veilig genoeg vinden en we er min of meer van op aan kunnen dat anderen ook de regels kennen en ook hiernaar handelen, durven we de weg op. We hebben er dan vertrouwen in dat het goed komt.

Wat ik regelmatig ervaren heb is dat men uit angst voor de eigen veiligheid zich niet uitspreekt, bijvoorbeeld uit angst voor de reactie (of zelfs actie) van de leidinggevende.
Wat er dan ontstaat is schijnvertrouwen; alles lijkt goed, maar onder de oppervlakte groeit de onvrede en de afstand tussen de teamleden. Niks zeggen betekent dus ook dat er automatisch van je verwacht wordt dat je doet wat anderen willen. Dit gedrag wil ik niet binnen mijn teams en daarom besteed ik hier veel aandacht aan.
Open en gelijkwaardige communicatie kan soms wat schuren en zelfs wat pijnlijk zijn, maar is een belangrijke pijler voor vertrouwen.

Manifesto

Binnen teams met genoeg vertrouwen hoef je niet bang te zijn bij een misstap.
Binnen teams waar het vertrouwen goed zit, gelooft men erin dat het soms niet helemaal gaat zoals gepland maar dat het werk met de juiste intenties is uitgevoerd. Het naderhand bespreken in de retrospective is hierbij natuurlijk belangrijk; samen leren van je fouten en het vervolgens beter doen is een belangrijke bouwsteen in het team vertrouwen.

Hieronder een aantal kenmerken van teams waar het vertrouwen ontbreekt:

  • Zeer afwachtende houding bij het vragen om hulp
  • De teamleden koesteren veel wrok naar elkaar
  • Binnen het team worden regelmatig onterechte conclusies getrokken over bedoelingen/bekwaamheden van anderen zonder deze te (kunnen) verklaren
  • Teamleden die elkaar ontwijken en sprake van structurele afwijzing van meetings of gesprekken met elkaar
  • De teamleden verbergen hun eigen zwakte en fouten voor elkaar
  • Er is sprake van grote aarzeling bij het bieden van hulp

Daarom is het opstellen van een Teammanifesto een van de topics die ik bij een retrospective ook graag doe. Het is een waardevolle manier om het onderwerp vertrouwen binnen een team bespreekbaar te maken en het maakt de waarden die teamleden belangrijk vinden in het team expliciet waardoor er minder of geen ongeschreven regels meer zijn waar men zich aan moet houden.

Ter vergelijking: als je bij een concert achterwaarts wil “stagediven” moet het zo zijn dat je het liefste wilt dat de mensen die je opvangen de collega’s zijn uit jouw team. Want je wilt dat het team je opvangt mocht het misgaan.
Zou jij het durven binnen je huidige team?

teamcoaching

 

Ik nodig je van harte uit om te reageren en mijn posts te delen met anderen in je eigen netwerk.

Daarnaast geven collega’s en ik ook workshops rondom leiderschap en team performance.
Kijk eens op https://www.towson.nl/trainingen voor meer informatie.

Stanley Markiet, consultant bij Towson

Team coaching: Management 3.0: We all have intrinsic motivators that inspire us to perform an activity to get a job done. Team coaching: Management 3.0: We all have intrinsic motivators that inspire us to perform an activity to get a job done. Team coaching: Management 3.0: We all have intrinsic motivators that inspire us to perform an activity to get a job done.

Management 3.0 – “Intrinsic motivators and the power of one question”

Geschreven door admin op . Gepost in Blog, Coaching, Teamontwikkeling.

We all have intrinsic motivators that inspire us to perform an activity to get a job done: “pride”, “order”, or “mastery”, just to name a few.
Management 3.0 offers a game called Moving Motivators. Basically, it’s nothing more than 10 cards, each with the description of one motivator, and designed as a one player game.
My experiment was to make it a group game.

I started the game by handing each team-member a card deck and asking them to rank the motivators in order of importance measured against their own values. The “motivators” to be ranked were curiosity, honor, acceptance, mastery, power, freedom, relatedness, order, goal and status. The participants in my experiment did not take this task lightly and needed some time to think about their choices.

After all personal rankings were made, they were shared with the other team-members, not intending to start a discussion, but just to get a better understanding of what each team-member had ranked the highest. Finally, I asked a simple question:

“As of now, your team is fully self-managed and therefore as a team you are truly responsible and accountable for your team success. Would this change the order of your motivators?”
I did this experiment several times now and without fail each team-member had a few motivators that would become more important. Funny side note, this even happens in teams that had already declared themselves self-managed.

There are two levels of insights here:

  • On a personal level; when we are part of a team, we are willing to put more emphasis on the motivators that are the most important motivators for the good of the group instead of our personal motivators;
  • Our personal motivators are literally moving when the objective of a group has changed or when new members join the team.