Skip to main content
Kumbaya Kumbaya Kumbaya

Kumbaya

Waarom willen hele organisaties Agile werken en zijn ze hiervoor bereid om een transitie te doen? Wat was ook alweer het kerndoel om Agile te werken? Richard geeft hier in zijn blog zijn visie op en herinnert ons er nog eens aan waarom ook executive teams een Agile transitie in hun organisatie interessant vinden. Om maar gewoon met de deur in huis te vallen: Wat is de aanleiding om ‘Agile’ te werken? Of een Agile transitie te doen, ongeacht de methode of het framework? Waarom überhaupt een transitie doormaken als organisatie en het gehele denken en handelen van mensen in die organisatie van top to bottom willen veranderen? Is het om medewerkers gelukkig te zien? Is het omdat de concurrentie het doet of omdat dit nou eenmaal hip & happening is? Of zit er zelfs een droom of visie achter dat we een prachtige wereld voor ons zien waarin iedereen gelijk is, en ieders stem gehoord wordt en evenveel gewicht in de schaal legt? We hebben volledig vertrouwen in de goedheid van de mens? Als je sommige publicaties leest, motivational speakers hoort, Agile HR managers aanhoort en ook Agile coaches beluistert, zou je toch haast het laatste denken. Als ik nou bestuurder of manager zou zijn die voor de keuze staat om Agile werken te introduceren, wat een radicale verandering met zich meebrengt, dan zou ik toch ernstige bedenkingen hebben als dit de boodschap is die wordt verkondigd. Want wat levert al dit gedoe dan eigenlijk op? Kumbaya? Waarom toch alleen focus op autonomie, zelfsturende teams, happiness, afbreken van autoriteit/zeggenschap, afbranden van hiërarchie, management of zelfs leiderschap. Het lijkt wel of de gehele gedachte achter Agile werken volgens hen is: we maken er een mooie commune van waar iedereen gelijk is en de kennis en kunde van een ontwikkelaar gelijk is aan die van een bestuurder, manager, marketingspecialist, productspecialist etc. Iedereen neemt uiteraard automatisch zijn/haar verantwoordelijkheid en optimaliseert zijn/haar werk en ontwikkeltraject, want zo is de mens. Right. Zijn al deze mensen vergeten, blind of onwetend waar Agile werken voor bedoeld is en welke gevolgen dit heeft voor een organisatie? Of zijn ze het er gewoon niet mee eens? Iemand de laatste tijd het Agile Manifesto bijgehaald? Waar draait het daar om? Zo snel mogelijk, zo veel mogelijk, zo goed mogelijke waarde leveren. Alles en iedereen staat ten dienste daarvan. En aangezien we dat nooit in 1x goed kunnen doen, gaan we alles in het werk stellen om dit zo snel mogelijk te verbeteren en versnellen. Dit is zonder twijfel een zeer strikte en economische filosofie welke tot in ieder hoekje en gaatje van een organisatie gevoeld zou moeten worden. Maximale waardecreatie, rigoureuze keuzes maken, continue optimalisatie van efficiëntie en kwaliteit, kritische reflectie op alles en iedereen, keiharde onderlinge concurrentie en eliminatie van de zwakste schakel binnen een team (we willen toch alleen gemotiveerde professionals?). Alles wordt daarbij vele malen meer controleerbaar door de glasharde transparantie. Waterfall en Prince2 zijn er echt helemaal niets bij, en voordat de engineering projectmanagers commentaar leveren: daar is de feitelijke ontwikkeling al geweest, een project om onderdelen in te kopen en te monteren is geen ontwikkel- of innovatietraject. Mocht dat wel zo zijn, ga dan Agile werken (als je wil weten hoe, neem maar eens contact op). Alle keuzes die gemaakt moeten worden, gaan om zo snel mogelijk de juiste waarde toe te voegen op het juiste moment, inclusief het meten of het gerealiseerde wel het beoogde effect had zodat het de volgende keer nog beter kan. Daarnaast is er strak georganiseerde, kortcyclische controle op wat nou iedereen aan het leveren is en hoe de verbetering gaat, inclusief directe feedback van en exposure naar het hoogste echelon. Iedereen en alles staat dus continu ten dienste van de maximalisering van waarde creatie (wat je ook maar als waarde hebt gedefinieerd als organisatie). In mijn oren klinkt dat helemaal niet Kumbaya, maar wel erg efficiënt en effectief en daardoor goed voor een organisatie om noodzakelijk snel, wendbaar en economisch efficiënt te kunnen worden en de enige basis waarom je überhaupt aan een Agile transitie begint. Om de pijn hiervan te verzachten, hebben we prachtige afleidingen, kralen en spiegels bedacht die hopelijk het zicht op deze harde werkelijkheid bedekken. Want goed samenwerkende teams zijn essentieel. Samenwerkingsvormen, mooi ingerichte teamwerkplekken, leuke spannende benamingen als Tribes en Chapters, leuke rolbenamingen, teamspiritverhogende meet-ups en spelletjes, gekleurde post-its op de muren, high fiven bij resultaten. Het ziet er, en klinkt, allemaal prachtig en is ook echt nodig. Het zijn echter slechts middelen die ten dienste staan van de waardecreatie. Maar om hier de focus op te leggen bij een Agile transitieadvies, is ronduit liegen tegen een organisatie en haar medewerkers. En zoals eenieder weet, mensen weten dondersgoed als er tegen hen gelogen wordt met alle gevolgen van dien. Wat is er mis mee dat het om waarde gaat bij een organisatie? Het hele voortbestaan van de organisatie is ervan afhankelijk. Wat kan er dan erg zijn aan eerlijk vertellen dat ieders bijdrage wordt geëist in het realiseren hiervan? De hele reden dat mensen aan het werk zijn bij een organisatie, is om waarde toe te voegen met kun skills, talenten en karakters. Dat er van medewerkers (inclusief management) wordt geëist dat ze zich continu openstellen voor nieuwe inzichten en eigen ontwikkeling? Daar worden ze toch echt voor betaald (vrijwilligers daar gelaten, die krijgen voldoening, hoop ik voor hen). Moeten bedrijven blij zijn met jou als medewerker, of moet jij blij zijn dat je bij dat bedrijf mag werken? Beantwoord die vraag maar als er zich een crisis voordoet waardoor er een flinke werkloosheid ontstaat. Laten we dus voortaan eerlijk zijn en het beestje bij de naam noemen: Agile werken gaat om maximale waarde te creëren voor een organisatie, niet meer, niet minder. Met deze maximale waarde kan het bedrijf blijven voortbestaan. Alle technieken en manieren van organiseren zijn daarin geoorloofd, als het maar efficiënt en effectief is en natuurlijk meerwaarde oplevert. En laten we de belofte uitspreken dat we allemaal ons best doen om deze nieuwe focus zo aangenaam mogelijk voor elkaar te maken. Dat we iedereen zullen faciliteren in hun ontwikkeltraject. Dat we genoeg zullen regelen zodat zoveel mogelijk mensen het naar hun zin hebben tijdens de uitvoering van hun werk. En dat, mocht dit allemaal niet lukken, we als goede vrienden uit elkaar zullen gaan. Want: verlies je de focus hierop, dan verlies je de meerwaarde van Agile werken.
leerling vroeger agile transitie leerling vroeger agile transitie leerling vroeger agile transitie leerling vroeger agile transitie

Wat voor leerling was jij vroeger? De parallel met een Agile transitie.

Deze week een mooie bijdrage van mijn collega Lotte Coosen. Lotte is namens Towson Scrum Master en Coach bij de gemeente Rotterdam. In haar blog vraagt ze zich af hoe het toch komt dat transformaties die met de beste bedoelingen beginnen maar niet echt breed landen in de organisatie wat beginnen te stropen en verzanden… Om een Agile transitie in gang te zetten wordt er vaak verwezen naar een belangrijke voorwaarde: het bereiken van het ‘tipping point’. Er moet een reden zijn om te veranderen en die moet collectief gevoeld worden; men moet het er met elkaar eens zijn dat de huidige manier van werken niet de gewenste resultaten oplevert. Maar is het niet vaak zo dat dit alleen in de hogere lagen van de organisatie gevoeld wordt? En dat er vervolgens voor de uitvoerende lagen besloten wordt dat zij Agile gaan werken? Hoe zorg je dan dat de urgentie om te veranderen ook daar gevoeld wordt? En welke rol speel je daar als Agile Coach in? Als beginnend Agile Coach ben ik ook in de valkuil gestapt om maar zoveel mogelijk uit te leggen wat Agile is, wat scrum is, wat SAFe is en hoe dat binnen een organisatie toegepast kan worden. En natuurlijk is die theorie nodig, moet men de spelregels verkennen met elkaar. Maar tezamen met een mooie zeepkistsessie van de CTO over de ‘need to change’ bleken mensen toch echt niet altijd in beweging te komen. Waarom gebeurde er nou niets? De reden voor verandering is toch duidelijk, de spelregels zijn uitgelegd, de teams zijn gevormd. Gaan met die banaan zou je zeggen. Misschien was het naïef, misschien had ik er zelf ook gewoon wat langer de tijd voor nodig voor ik het zag, maar inmiddels is mij duidelijk dat niet iedereen elke ochtend inlogt om bij te dragen aan de visie en missie van een bedrijf. Ondanks dat hij of zij er ooit heel bewust voor heeft gekozen om daar te gaan werken. Bij sommige mensen is die connectie met het bedrijf inmiddels verdwenen, bij anderen is hij er misschien nooit zo sterk geweest. Uiteraard en gelukkig zijn er ook genoeg mensen die wel tot in hun kern verbinding voelen met het bedrijf waarvoor ze werken, alles in het werk stellen om bij te dragen aan goede resultaten en een mooi product, en van daaruit de nut en noodzaak van een transitie inzien. Maar juist die paar mensen die die verbinding niet zo voelen, of die gewoon bang zijn voor verandering, dát zijn de mensen die een transitie en de vorming van een team aardig in de weg kunnen zitten. Het artikel van mijn collega Marjolein van Gelderen gaf al een mooie inkijk in hoe je zo’n team recht kunt trekken. Daarnaast helpt het om steeds stil te staan bij de persoonlijke motivatie van een teamlid of medewerker. Bij iedereen is wel een ‘tipping point’ te vinden, maar dat zal voor iedereen anders zijn. Net zoals dat van bedrijf tot bedrijf verschilt. Bij het ene bedrijf zal het de behoefte zijn om van waterval af te stappen, bij het andere bedrijf wil men structuur aanbrengen in het ad-hoc werken, etc. Zo zijn er bij teamleden ook verschillende redenen om wel mee te gaan in een agile transitie. Behoefte aan transparantie, aan regie, aan een sterke teamdynamiek, plichtsgetrouwheid en zo zijn er nog veel meer redenen. Wanneer en waarmee bereikt iemand zijn of haar tipping point? Of komt dat misschien wel nooit (ook goed om te weten)? Daar kom je alleen achter door als coach in gesprek te blijven en wellicht eens te vragen naar iemands verleden. Niet zo lang geleden viel bij mij ineens de vergelijking met de klasgenoten van vroeger. Er zijn er altijd een paar die weken van tevoren gaan leren voor een toets en je hebt er ook een aantal die pas de dag van tevoren hun boeken openslaan. Dat kan te maken hebben met iemands leervermogen. Maar dat kan ook te maken hebben met de urgentie die iemand moet voelen om aan de slag te gaan. Dat is bij een Agile transitie niet anders; je hebt medewerkers die er gewoon in meegaan omdat ze het grotere belang ervan inzien, en je hebt medewerkers die pas in beweging komen als de voordelen voor hen persoonlijk duidelijk zijn. Dus vraag als coach eens wat voor leerling iemand vroeger was. En dan is het hopen dat niet al te veel mensen zullen antwoorden dat ze helemaal niet leerden, en gewoon op goed geluk naar het examen gingen.
continue-verbeteren-in-team continue-verbeteren-in-team continue-verbeteren-in-team

Continu verbeteren in een team – wat als de basis ontbreekt?

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!
valkuil valkuil valkuil

De valkuil van te klantgericht willen zijn

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?

pyramide-van-lencioni 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 Lenioni; 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 teamcoaching teamcoaching teamcoaching teamcoaching

Teamcoaching met Lencioni: Commitment; ook wel “betrokkenheid”

teamcoaching 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
korte sprints beter in team korte sprints beter in team korte sprints beter in team korte sprints beter in team korte sprints beter in team

Waarom zijn korte sprints beter?

korte sprints beter in team 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
escaperoom

Leer je team kennen via een escaperoomgame

escaperoom Als scrummaster ben je continu teamdynamiek aan het verbeteren. Soms werk je al een hele tijd samen, soms ben je net aan een team toegevoegd, of is het team inclusief jou net gevormd- in welke situatie je je ook bevindt: het spelen van een escaperoomgame biedt inzicht. Daarvoor hoef je niet naar een (dure) escaperoom: er zijn diverse escaperoom-boardgames verkrijgbaar tussen de 10 en 30 euro. De escaperooms kunnen gespeeld worden met maximaal 4 of 6 personen. Heb je een groter team dan kun je meerdere escaperooms aanschaffen en het team in groepen verdelen, hetgeen zorgt voor een extra competitie-element. De “pocket-escaperoom” (€ 10) bestaat uit alleen kaarten, de “Exitgame escaperooms” van € 15 bevatten ook objecten die je moet vouwen, beschrijven en/of verknippen. De uitgebreide escaperoomspellen (€ 30+) hebben daarbij ook nog een tijdklok die terugloopt. Ga goed na bij je team of iemand al eens een escaperoomspel gespeeld heeft, voor je er een aanschaft. Je wilt niet dat iemand de oplossingen al kent. Als scrummaster of Agilecoach doe je niet mee maar observeer je alleen het gedrag van de teamleden en maak je aantekeningen. Het mooie is dat de tijdsdruk, complexiteit en samenwerking vaak een goede afspiegeling zijn van de situaties waarin je team normaal gesproken ook terecht komt. Als je een beetje bekend bent met Disc-profielen en Kolb-leerstijlen zul je deze ongetwijfeld herkennen in het gedrag van je teamleden. Wie neemt het voortouw, wie observeert, wie “doet”, wie betrekt de rest van het team erbij, wie neemt beslissingen, wie houdt het overzicht? Maak notities en probeer voorbeelden te onthouden. Uit de observaties komt vaak ook goed naar voren welke rol er mist in een team. Als het team geen “beslisser” heeft zullen discussies lang doorgaan. Als er geen “doener” is blijft het team analyseren; als er alleen maar dominante personen zijn zonder bruggenbouwer, ontstaat er vaak onenigheid en komt het team ook niet verder. Het beste is om het team van tevoren niet in te lichten waar je op zult letten, zodat men onbevangen en “als zichzelf” deelneemt aan het spel. Achteraf kun je je observaties delen en bespreken en samen met het team kijk je dan naar mogelijke verbeterpunten en te ondernemen acties. Bij Towson gebruiken we een escaperoomspel in de teamworkshop “Samen Succesvol”. Als je nieuw bent bij een team of met een team start, kun je het spel als kennismakingsoefening gebruiken. Als je al langer met een team samenwerkt kun je het als alternatieve retrospective gebruiken. Of als start van een teamuitje. Je moet ongeveer 90 minuten uittrekken want niet iedereen redt het in 60 minuten te ontsnappen en dan wil je toch tot het einde door gaan. Daarnaast wil je ruimte hebben om de terugkoppeling te kunnen geven. Zelfs teamleden die niet van spelletjes spelen houden vinden dit vaak toch wel een leuke uitdaging. Het is spannend om te doen en biedt jou als (nieuwe) scrum master inzichten die kunnen helpen het team te laten groeien. Veel plezier met de escaperooms! Door Tamara Teunissen van Manen-Kiljan, consultant bij Towson
Eduscrum Eduscrum Eduscrum

Eduscrum: Agile onderwijs instellingen

Eduscrum

1. Introductie

De maatschappij, de arbeidsmarkt en het onderwijs veranderen in rap tempo, opleidingen groeien en krimpen, lesmethodes veranderen en onderwijs veroudert steeds sneller. Onderwijsinstellingen en opleidingsinstituten zullen dan ook continu hun onderwijs en lesmethoden dienen te evalueren, vernieuwen en aan te scherpen. Het gericht, efficiënt en effectief ontwikkelen van onderwijs is echter arbeidsintensief en wordt vaak naast de reguliere contacturen ontwikkeld, waardoor het voor docenten lastig is om prioriteiten te stellen. Agile scrum kan onderwijsinstellingen helpen bij het effectief en efficiënt ontwikkelen van onderwijs.

2. Aanpak en implementatie

Allereerst worden gezamenlijk alle vakken geïnventariseerd die ontwikkeld en verbeterd dienen te worden. Per vak wordt op basis van urgentie, ouderdom, werkdruk, beoordeling van studenten een Product Backlog opgesteld. Tegelijkertijd wordt een Scrum Team van docenten ingericht. Twee docenten worden benoemd tot Product Owner en Scrum Master. Idealiter vervult de persoon die eindverantwoordelijk is voor het curriculum de rol van Product Owner. De rol van Scrum Master kan het beste worden vervuld door een docent met organisatietalent, draagvlak en oplossingsvermogen. Daarnaast is het handig om mensen uit de praktijk en studenten aan te haken. Op deze manier borg je dat het vak in lijn is met de praktijk en voldoet aan de behoefte van studenten. Vervolgens wordt gestart met een Sprint Planning waar het eerste vak wordt opgepakt en bepaald wordt welke taken er allemaal opgepakt moeten worden om succesvol het vak te ontwikkelen. Elementen die vaak in de Sprint Planning besproken worden zijn: visie, leerdoelen, competenties, toetsnormen, lesbeschrijving en onderwijsmaterialen. Voordat het vak definitief is afgerond is het handig om het vak te toetsen en testen. Dit kan door onderdelen van het lesmateriaal en werkvormen in een kleine groep van docenten, studenten en praktijkmensen te toetsen. Op deze manier ontvang je feed-back op basis waarvan je het vak en lesmethode nog voor gebruik kan aanscherpen.

3. Het resultaat

Door een combinatie van Agile en Scrum principes, intensieve samenwerking tussen docent, praktijk en student is het mogelijk om continu effectief en efficiënt onderwijs te ontwikkelen dat voldoet aan de wensen van docenten en studenten en geldende kwaliteitseisen. 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
Scrum-business Scrum-business Scrum-business Scrum-business Scrum-business

Scrum in business: Op weg naar zelfsturende teams

Scrum-business

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.