Tag: SAFe

Artificial Intelligence in Scaled Agile. Vooraanzicht van een Agile team staand voor een raampartij in een kantoorruimte. De ruiten zijn volgeplakt met gekleurde post-its. De jonge teamleden kijken naar de post-its die onderdeel zijn van het kanban-organisatieproces. Artificial Intelligence in Scaled Agile. Vooraanzicht van een Agile team staand voor een raampartij in een kantoorruimte. De ruiten zijn volgeplakt met gekleurde post-its. De jonge teamleden kijken naar de post-its die onderdeel zijn van het kanban-organisatieproces. Artificial Intelligence in Scaled Agile. Vooraanzicht van een Agile team staand voor een raampartij in een kantoorruimte. De ruiten zijn volgeplakt met gekleurde post-its. De jonge teamleden kijken naar de post-its die onderdeel zijn van het kanban-organisatieproces. Artificial Intelligence in Scaled Agile. Vooraanzicht van een Agile team staand voor een raampartij in een kantoorruimte. De ruiten zijn volgeplakt met gekleurde post-its. De jonge teamleden kijken naar de post-its die onderdeel zijn van het kanban-organisatieproces.

Artificial Intelligence in een (scaled) agile omgeving: Lekker Belangrijk?!

Geschreven door Marieke Bosscher op 16 mei 2024. Gepost in Agile, Kenniscentrum.

Wanneer het gaat over Artificial Intelligence (AI) in onze (scaled)agile werkomgevingen, stuiten we vaak op vooroordelen. Aanvankelijk leek AI meer een gemakkelijke uitweg voor wie niet de moeite wil nemen diep in de materie te duiken. Maar de visie van Peter Turien (de stuwende kracht achter Towson) veranderde dramatisch na het bijwonen van enkele eye-openers. Is AI inderdaad alleen maar een handige tool, of is het de revolutionaire kracht die we over het hoofd zien?

Van twijfel naar transformatie:

Een doorslaggevend moment kwam begin dit jaar tijdens de Towson inspiratiedag, aangedreven door een boeiende workshop van Capgemini Invent. Hier werd helder hoe AI kan dienen als een katalysator voor innovatie binnen onze processen. Wat eens leek op een “leuke extra” zonder veel substantie, werd plots een essentiële strategie om ideeën te verrijken en de uitvoering ervan te versnellen.

Doorbraak op de SAFe Summit 2024:

De bevestiging van dit nieuwe inzicht kwam met de SAFe Summit in Berlijn, waar de release van het “Artificial Intelligence in SAFe” visieartikel plaatsvond. Dit document onderstreept niet alleen het belang van AI maar biedt ook concrete handvatten voor de implementatie ervan in drie sleuteldomeinen:

De Augmented Workforce:

AI als hulpmiddel om het potentieel van teams te vergroten, specifiek gericht op rollen zoals Scrum Masters en Product Owners. Deze kunnen met AI efficiënter knelpunten identificeren en user stories uitbreiden.

AI-Enabled Solutions:

Hierbij wordt de optimalisatie van Agile Release Trains (ART’s) met AI belicht, een combinatie die zorgt voor een versnelling in het realiseren van projectwaarde.

Responsible AI:

Gericht op het gebruik van AI voor het formuleren van beleid en het maken van strategische beslissingen die de organisatie ten goede komen.

Wat begon als een sceptische kijk op AI is geëvolueerd naar een diep inzicht in haar cruciale rol. Laten we AI niet meer zien als een optioneel extraatje, maar als een onmisbare innovatieve kracht. Het is tijd om AI serieus te nemen en volledig te integreren in onze agile processen.

Ben je klaar om met AI jouw agile praktijken naar een hoger niveau te tillen? Bekijk onze Agile traininge n.

Business Objectives Business Objectives Business Objectives Business Objectives Business Objectives

Geef betekenis aan Business Objectives en stuur op waarde

Geschreven door marjorie op 24 juli 2023. Gepost in Agile, Kenniscentrum, SAFe.

Betekenis geven aan de Agilerituelen is een van de belangrijke taken die een scrum master en RTE hebben. Wanneer je dit niet doet is het directe gevolg dat mensen zich hardop afvragen waarom hun aanwezigheid gewenst is. Indirect is de schade echter nog veel groter: de rituelen verliezen hun kracht om veranderingen en productrealisatie effectief te sturen. Een van die aspecten waar een Scum Master of RTE tijdens de PI planning betekenis aan moet geven, is het coachen van de Agile Release Train en de Business Owner op het samen vaststellen van goede Business Objectives.

Het hebben van goede en goed gedragen business objectives leidt tot focus en de juiste gesprekken of binnen de ART tijdens de increment de juiste dingen gedaan worden. Het niet hebben van goede en goed gedragen business objectives leidt er bijna altijd toe dat de verwachtingen van de business owner en de stakeholders afwijken van wat de Agile Release Train werkelijk oplevert. Met alle teleurstelling die daarbij hoort.

Geef betekenis aan Business Objectives voor effectief gebruik van het SAFe-model en waardesturing boven opgeleverde Features.

Onvoldoende betrokkenheid van Business Owners leidt tot teleurstelling over opgeleverde resultaten.

Na de overgang naar het SAFe werken en een Agiletransformatie, ervaren veel organisaties een nieuwe structuur van Agile Release Trains, Program Increments (PI) en PI planningen. Ondanks de voortgang in het transformeren naar een agile organisatie, blijft de snelheid en invulling van strategische doelstellingen vaak achter. Business Owners zijn vaak nog niet voldoende betrokken en hebben daardoor geen duidelijk beeld van wat ze kunnen verwachten. Dit resulteert regelmatig in teleurstelling over opgeleverde resultaten. Zelfs als er een goed draaiende ART is, dragen de opgeleverde Features mogelijk beperkt bij aan de hogere organisatiedoelen. Een gesprek tussen de Business Owner en de ART over PI Objectives kan deze uitdagingen aanpakken.

Bekijk onze SAFe Agile Product Management training

Toch zal niet elke organisatie dit herkennen en worstelt men in het begin geregeld met het vertalen van de strategie in goede PI Features. Of er zijn juist zoveel Features dat men door de bomen het bos niet meer ziet. Met PI objectives kun je de focus houden op wat echt belangrijk is en die Features die het meeste bijdragen aan de strategische doelen voorrang geven. Hieronder lees je wat dit zijn en hoe je ze gebruikt.

PI planning: de magie van het framework

Eerst even terug naar de basis: waarom kiezen organisaties voor een PI-cadans met PI planning-events? Volgens de SAFe-auteurs bestaat er geen SAFe zonder PI planning. Sterker nog: zij noemen de PI planning de magie van het framework. De kracht van het event zit erin om in een 2-daagse sessie van strategie tot realisatieplanning te komen. In het event zit een feedbackloop verweven die de problemen van de teams expliciet op de tafel van de beslissers legt. Zo kan een team dat een nieuw product ontwikkelt er tijdens het plannen van de Features erachter komen dat er specifieke kennis nodig is van buiten het team. Er kan dan diezelfde dag nog door de directie besloten worden om een expert daarvoor vrij te maken. Door het transparant maken van wat er nodig is om tot resultaten te komen wordt het eenvoudig om hiervoor de juiste beslissingen te nemen.

PI objectives beschrijven wat er bereikt zal zijn als het PI succesvol is; Wat kan de organisatie na de realisatie gedurende een increment dat het voorheen nog niet kon? PI objectives zijn in de basis simpel: een lijstje bulletpoints met 7-10 concrete doelen voor het komende Program Increment, doorgaans 8 tot 12 weken. Deze doelen moeten realistisch en haalbaar zijn en duidelijk bijdragen aan de doelen van de organisatie waar een ART deel van uitmaakt. Goede vragen om jezelf te stellen bij het opstellen van de PI objectives zijn: -Welke functionaliteit is gereleased?; -Hoeveel extra gebruikers zijn bereikt?; -Welke kosten zijn bespaard? Voorbeelden zijn: “Eerste product verkocht in de app” of “Een werkende feedbackknop op de website”.

PI Objectives laten stakeholders de waarde herkennen zonder alle Feature-details te begrijpen, tonen afhankelijkheden, en hoe stakeholders kunnen bijdragen aan de doelen.

Belangrijk voor PI Objectives is dat de stakeholders van de ART de waarde ook eenvoudig herkennen. Het geeft ze daarmee een goed beeld van wat ze kunnen verwachten zonder elke Feature te moeten begrijpen. Daarnaast maakt het afhankelijkheden inzichtelijk en toont het hoe stakeholders kunnen helpen om de gestelde doelen te realiseren. Een voorbeeld: “Om een product te kunnen verkopen in de app is nodig dat Finance het facturatieproces ondersteunt”. Dat geeft de Finance stakeholder een duidelijke taak mee voor het PI.

Door de PI Objectives te scoren en ordenen maak je helder van welke objective je de grootste bijdrage verwacht aan de organisatiedoelen.

Hoe stel je goede PI Objectives op?

Volg het stappenplan hieronder:

1. De Product manager(s) stelt (stellen) een eerste versie van PI Objectives op, vanuit de productdoelen en Features voor het PI. Wat zijn de belangrijkste doelen voor dit PI?

2. Op het PI plannen de teams Features in en wordt duidelijk wat wel en niet gepland kan worden.

3. De ART teams bepalen hun doelen op teamniveau, gebaseerd op Features die ze dit PI plannen. Deze Teamobjectives geven aan welke hogere doelen het team met deze Features wil bereiken. Een goede checkvraag hierbij is: wanneer heeft het team een succesvol PI? Belangrijk om deze doelen SMART te maken, zodat het team hier tijdens het PI op kan sturen.

4. Op basis van de eerste versie van de geplande Features en teamobjectives stelt de Product manager de PI Objectives op.

5. De Release Train Engineer toetst de Objectives bij de teams op haalbaarheid zodat zij zich eraan kunnen committeren.

6. Wanneer de PI Objectives definitief zijn kan de Product Manager deze scoren van 1-10 op waarde.

7. De Product Manager deelt de PI Objectives met de ART en haar stakeholders. Door ze transparant te maken en gedurende het PI als referentie te gebruiken blijft de ART de belangrijkste doelen in het vizier houden. Dit start bij de PI confidencevote en loopt door in PO Syncs en Sprint Reviews tot de afsluitende Inspect & Adapt sessie.

Geef betekenis aan Business Objectives om het SAFe-model effectief te gebruiken en te sturen op waarde in plaats van opgeleverde Features

Naast de gecommiteerde PI Objectives kan de ART ook niet-gecommitteerde objectives opnemen. Dit zijn doelen die wel waardevol zijn, maar waaraan de teams zich niet met zekerheid kunnen committeren dat ze deze kunnen afronden binnen het PI. Oorzaken hiervan zijn externe afhankelijkheden, of er is nog grote onzekerheid in de exacte uitkomst van wat er gebouwd wordt, of nog onvoldoende kennis van de tool waarmee gewerkt wordt. Door deze objectives wel te benoemen en ervoor te plannen, maar niet op te committeren verhoog je de betrouwbaarheid van de ART. De business owner weet nu waar zeker op gerekend mag worden en wat op basis van best effort gedaan wordt.

Door te werken met PI Objectives zijn de doelen samengevat in voor iedereen begrijpbare taal. Succescriteria zijn expliciet, concreet én hebben commitment van de teams. Business Owners hoeven zich niet volledig te verdiepen op alle features en stories en snappen direct waar de ART zich op richt, maar belangrijker: op welke prestatie van de ART ze mogen rekenen. Door met elkaar de juiste betekenis te geven aan Business Objectives kun je het SAFe-model effectief inzetten waar het voor bedoeld is, namelijk het sturen op waarde (outcome) in plaats van opgeleverde Features (output).

Heb je ook een uitdaging om businessdoelstellingen te bereiken in een agile omgeving? Wil je meer weten over het gebruik van PI Objectives? Neem dan contact op via info@towson.nl en één van onze consultants helpt je graag verder!

Transitie en het managen van verandering, hoe organiseer je dat? En waar is het draaiboek?!

Geschreven door Marieke Bosscher op 25 maart 2023. Gepost in Agile, SAFe.

Wanneer je gaat veranderen ga je een onzeker traject in. Wat doet zo’n verandering van de situatie met jou? Hoe kun je je hier goed op aanpassen? En als het niet zo gaat als je vooraf dacht, wat dan? Vanuit een heel herkenbare situatie schrijft Remco Klompmaker over zijn bijdrage aan de energietransitie en hoe zijn aanpassingsvermogen (en dat van zijn gezin) werd getest. De wereld om ons heen verandert constant: kijk naar de klimaatverandering en de energietransitie die daaruit voortvloeit, of de oorlog in Oekraïne die hier, maar ook op andere ambities, direct impact op heeft. Kortom: we zijn constant onderdeel van een transformatie of organiseren, binnen een verandering, onze eigen transformatie. In het kader van de energietransitie vertel ik je over een experiment als de start van een persoonlijke transformatie, en wat mijn ervaring hierin was. Ondanks dat dit een overzichtelijk experiment was als start van een verandering, verschilt het proces niet zoveel van de veranderingen die we op grote schaal doen.

Mijn transitie

Onlangs was het weer tijd om een nieuwe leasewagen te kiezen en wat kies je dan? Elektrisch, fossiel of hybride aangedreven auto? De eerste vragen waren er direct:

Wat gaat dit mij extra kosten?
En heb ik dat ervoor over?
Wat voor impact heeft dat op mijn woon/werk verkeer.
Wat voor impact heeft dat op mijn privésituatie?

Allemaal vragen waar je voor jezelf een antwoord op moet vinden in combinatie met hoe je tegen de benodigde verandering aan kijkt. En dán loop je vervolgens nog aan tegen vragen als: Hoeveel heb je er dan voor over, hoeveel ben je bereid zelf te investeren? Ik heb de keus gemaakt om vanuit mijn motivatie een bijdrage te willen doen aan de klimaatverandering en heb daar iets extra’s voor over gehad. Met de levering van de wagen bleek dit echt, want het rijden in een elektrische auto vereist een andere houding. Voor mij is de transitie de nieuwe auto en de transformatie dat ik anders moet rijden met deze auto en anders mijn routes ga plannen om efficiënt met de laadtijd om te gaan. Ineens moet ik nadenken wanneer ik ga laden en hoe groot mijn bereik is. Kortom, om de auto optimaal te kunnen gebruiken zal ik mijn oude gewoontes moeten afleren of bijstellen.

Wat is er veranderd dan?

Ik hoef in Nederland niet meer naar een tankstation. Ik laad de auto thuis op. De auto rijdt anders en als ik snel rij heeft dat direct veel meer impact op mijn bereik dan een benzineauto en daarmee de afstand die ik kan afleggen. Met harder rijden moet ik toch nog een extra pauze inlassen om even bij te laden. Wil ik een extra stop of rij ik langzamer en ben ik dan sneller thuis? Ik kwam er al snel achter dat mijn rijgedrag aangepast moest worden.

Het experiment:

De eerste vakantie, een reisje naar Frankrijk, werd echt een uitdaging. Ik was nieuwsgierig naar het experiment en heb mijn familie weten te overtuigen om dit met de nieuwe elektrische wagen te gaan ondernemen. Na hun goedkeuring konden we gaan plannen. Ik noem het een experiment omdat ik nog erg onbekend ben met het rijden van een heel lange afstand en tegen welke uitdagingen je dan werkelijk aanloopt. Hoe gaat de familie daarmee om? En wordt het een succes en willen we het na deze reis ooit nog eens proberen of blijft het bij deze ene keer? Behalve de onzekerheid en het ongemakkelijke ben ik natuurlijk ook benieuwd wat voor positieve dingen het brengt. Het kan zomaar lukken en een groot succes zijn.

Het doel:

Het doel is gekozen: “Toulouse bij vrienden in huis”. De onzekerheid voor de eindstop en tijdig moeten arriveren was daarmee weggenomen. En de Franse familie hadden we al een tijdje niet gezien, dus dat was een leuk vooruitzicht.

De heenreis:

Daar waar ik normaal gesproken met de maximum toegestane snelheid zeer efficiënt naar het zuiden van Frankrijk reed en met 1 tankbeurt al op locatie aan kom moest ik het nu anders gaan aanpakken. Internet was (nog niet) mijn beste vriend. Er stond al wel veel geschreven maar toch was ik er niet gerust op. Er was nog veel onzekerheid over de laadpalen, hoe te betalen, snelheid van het laden in combinatie met mijn rijgedrag en de buitentemperatuur. Oh ja… die buitentemperatuur heeft dus ook ineens invloed op mijn rijafstand. Dat was ik niet gewend! Voor de zekerheid heb ik extra pasjes gekocht naast de laadpas die ik bij de auto meegeleverd heb gekregen. Dat was een goede tip die mij al veel problemen heeft bespaard. Ik heb een route gepland met de laadpunten die ik nodig had om op de plaats van bestemming te komen. Ik had gelezen dat de Tesla superchargers ook voor niet-Tesla’s waren opengesteld maar kon geen ervaringen terugvinden op internet. Ik heb 20 apps gedownload die aangaven te weten waar alle laadpalen stonden. Na er 15 weer verwijderd te hebben heb ik de meest betrouwbare laten staan, hopende dat ze tijdens de reis nog konden helpen als het fout ging. Ok, route bepaald en laadpunten in Google Maps geplaatst om te gebruiken met Carplay. Ook voor de zekerheid in de navigatie van de auto gezet. Tijdstip vertrek 7:00 uur in de ochtend en uitgerekende aankomst om 20:00 uur inclusief 5 stops om te kunnen laden. Daar reden we weg om 7:15, beginnend met een achterstand op het schema van 15 minuten. Met een 100% volle accu ben ik gestart met een snelheid van 100 km per uur zodat ik een langere range had. Het had gevroren dus ik merkte al snel op dat, als ik harder ging rijden dan 100km per uur, de ingeplande reserve van 100 km accu slonk naar 90km. Maar vanwege de onzekerheid wilden we die 100km reserve wel hebben. Stèl dat een laadstation niet werkt dan sta je stil. Een extra kannetje met benzine gaat hier niet lukken en ook mijn accu van de telefoon zal de auto niet verder brengen. 2e oponthoud was de ochtendspits bij Antwerpen. Die was te verwachten en hadden we met de conventionele wagen ook gehad. Daar kwam de eerste stop aan. Ik had als eerste laadpunt gekozen voor een Tesla supercharger die sinds kort ook in het buitenland beschikbaar waren voor niet-Tesla’s. Maar eenmaal op locatie bleek dat deze dus niet voor mij beschikbaar was. De reden voor het Tesla laadstation te kiezen is dat er veel laadpalen zijn en ze altijd werken. Dus als eerste maar ervaring opdoen met deze laadlocaties zodat ik er later voordeel uit kon halen. Dus: op zoek naar een andere laadlocatie. Dit heeft ons zeker 30-45 minuten extra tijd gekost. De 2e stop was in de binnenring van Parijs bij een Tesla snellaadstation bij een winkelcentrum. Eindelijk! Dat ging goed en het was erg gezellig. We hadden immers tijd om even samen rond te kijken. Gedurende de dag kwamen we er al achter dat het langzamer ging dan gedacht: 2/3e van de dag voorbij en nog niet eens op de helft van de route. En het volgende laadstation werkte niet. Ook hier weer op zoek naar een andere. Deze andere lag in de buurt maar was geen supercharger. Dus geen 30 minuten laden maar 1 uur. Dus gelijk maar wat eten want het was inmiddels 18:00 uur, zodat we dat niet meer hoefden te doen. Gelukkig ging het daarna wat sneller en naarmate ik ervaring kreeg met het laden, en omdat de buitentemperatuur was opgelopen naar 17 graden, kon ik ook harder gaan rijden zonder in te boeten op reserve. 110 – 120 was een mooie snelheid en bleek voldoende reserveaccu over te houden. Om 23:30 kwamen we aan op ons adres in Toulouse en werden we welkom geheten met een lekkere Franse wijn en kaas.

De terugreis

Met de ervaring van de heenreis werd het plannen al simpeler. Ik wist welke laadpalen wel en niet werkten en hoe ik dat kon zien in de apps. Ook wist ik welke laadpassen wel werkten en welke niet. Hiermee ging de terugreis al een stuk sneller. Alle geplande laadpunten werkten en we hoefden niet meer te zoeken naar een alternatief. Ik heb de hele terugreis 110-120 km per uur gereden waardoor ik ook al beter opschoot. Tja… En dan kom je weer in Parijs, maar nu tijdens de spits. Dat was niet geheel onverwacht en ik heb bewust gekozen voor een laadbeurt tijdens de spits. Na het vertrek hadden we toch nog een staartje van de spits wat met een conventionele auto hetzelfde was geweest. Met een vertrek van 9:15 en aankomst om 23:45 uur hebben we het een stuk efficiënter gedaan dan de heenreis.

Reflectie op mijn experiment

Dit verhaal brengt me weer terug bij de vragen over Transitie en het managen van verandering: “Hoe organiseer je dat?” en “Is daar een draaiboek voor dat je uitrolt?”. De transitie was bij mij de nieuwe auto die anders was dan een conventionele fossiele brandstofaangedreven wagen. De Transformatie was voor mij het feit dat ik de dingen anders moest gaan doen, zoals laden, rijden, en plannen van mijn rit. Ik ben me bewust geworden dat de transitie erg veel onzekerheid met zich meegebracht waar ik opties open moest laten om eventueel met het geleerde bij te kunnen sturen. De verandering zorgt dat je moet transformeren om je doelen te kunnen behalen. Transformatie betekent verandering van mindset en skills naar een nieuwe mindset en skills die je nog niet hebt ervaren en waarvan je niet weet hoe die er precies uit gaat zien. Dat moet je immers nog gaan ervaren en van gaan leren. Het leren zal in kleine stapjes gaan. De ene keer gaat het goed en de andere keer fout waardoor je het anders moet doen. Er is geen draaiboek dat je 1:1 kunt uitrollen; daarvoor zit er teveel onzekerheid in omdat je het nog nooit eerder hebt ervaren. Een plan maken blijkt nog steeds verstandig om de risico’s te identificeren en ruimte in te bouwen voor de opties als het anders gaat dan verwacht. Accepteer en calculeer in dat je plan niet loopt zoals gepland en dat je dat weer snel kunt bijsturen met de opgedane ervaring of experimenten. Communiceer het met je collega’s zoals ik mijn familie in het plan heb meegenomen zodat het niet alleen mijn experiment is. Als laatste te beantwoorden vraag: “Wat voor positieve elementen heb ik eraan overgehouden?”. Als gezin kwamen we erachter- doordat we rekening hadden gehouden met vertraging- dat niemand heeft geklaagd tijdens de heen- en terugreis. Het was zelfs ontspannener dan de traditionele gehaaste reizen die we voorheen hebben gemaakt. We hebben beide reisdagen als gezellig ervaren omdat we tijd hadden voor elkaar en om even te ontspannen. Ik hoop dat mijn relaas je heeft kunnen aanzetten tot denken en doen. Mocht je meer willen weten, of hulp nodig hebben: laat het mij vooral weten: stuur een mail naar info@towson.nl of neem telefonisch contact op: 085 877 0180. Ik geef bij Towson ook twee trainingen die hierbij mooi aansluiten: de Leading SAFe training en de SAFe Advanced Scrum Master training (SASM).

Tuckmans-fases Tuckmans-fases Tuckmans-fases

Samenwerken, een vanzelfsprekend proces?

Geschreven door Marieke Bosscher op 23 maart 2023. Gepost in Agile, Teamontwikkeling.

Je kent het gevoel wel: je bent werkzaam binnen een team waar iedereen kan lezen en schrijven met elkaar. Je zou dan zeggen dat de samenwerking goed is. Andersom heb je misschien ook wel eens meegemaakt. Als Agile Coach zie je deze situaties veel en vaak, en alleen dit constateren is voor een Agile Coach vaak niet voldoende. Dit betekent actie! Als een samenwerking als goed wordt ervaren, ben je natuurlijk nieuwsgierig waar dit hem dan in zit, en waar nog meer winst te behalen valt. Wanneer een samenwerking minder goed is, dan is het natuurlijk de uitdaging om te kijken waar dit hem dan in zit.

Aan de hand van het model van Tuckman neem ik je mee hoe je zou kunnen herkennen of een samenwerking binnen een team prettig verloopt, en wat je vervolgens aan interventies zou kunnen doen om dit te verbeteren. Belangrijk om hierbij te vermelden is dat iedere groep mensen die geacht wordt een gezamenlijk doel te bereiken een team zou kunnen zijn. Dit model maakt geen onderscheid in development teams, business teams of een leiderschapsteam. Dus in welke context jij als coach ook zit, dit model kan jou inspireren, nieuwe inzichten geven en je interventies beter maken door de behoefte die er op dat moment is. De eerste fase van Tuckman kun je herkennen als je een team begeleidt dat alleen maar met zichzelf bezig is, een beetje zoals het Nederlands elftal onder Frank de Boer. Ze zien elkaar niet als teamleden, en als er iets is gaan ze naar de manager. Daarnaast zie je vaak dat de groepsleden niet eens weten waarom ze bij elkaar gezet zijn, en met welk doel. Bij conflicten luisteren ze niet naar elkaar, ligt de schuld altijd bij de ander en is het lastig afspraken maken met deze groep. Tuckman noemt deze fase forming: de groep is zich aan het vormen tot een geheel, maar dat gaat vaak niet vanzelf. Als jij coach bent van zo’n groep, faciliteer dan sessies waarbij mensen elkaar beter leren kennen. Als mens, maar ook als professional. Coach het leiderschap op transparantie en kwetsbaarheid. Op deze manier gaan zij het goede voorbeeld geven, leading by example! Als je als coach lekker bezig bent geweest om een team te creëren ga je op een gegeven moment merken dat het gaat stormen binnen het team. Letterlijk stormen! Daarom heet deze fase ook storming. Je gaat twijfelen of deze groep hier wel wil werken, er zijn veel conflicten, subgroepen ontstaan (kijk regelmatig bij de koffiemachine) en in deze fase wordt de norm bepaald van wat binnen deze groep geaccepteerd wordt. “Zo doen wij het hier”, gaat duidelijk worden. Maar ook hier kun je als coach een rol spelen zodat je het team helpt in deze fase. Jij kunt deze storm bedwingen! Zorg ervoor dat je de groep helpt de normen te bepalen. Doe dit met de groep, zodat iedereen zijn zegje kan doen, en zodat de afspraken binnen de groep van iedereen zijn. Maak deze ook transparant, net als de doelen en werkprocessen van het team. Een ongeschreven regel is in dit geval killing. Transparancy is key in deze fase! Onderdeel van deze transparantie is ook, hoe lastig het soms ook is, feedback naar elkaar geven. Alleen zo leer je de teamleden om elkaar aan te spreken op het naleven van de door hen opgestelde afspraken. Je zult zien dat ze elkaar dan gaan helpen, en verantwoordelijkheid gaan nemen voor de dingen die ze doen. Als de storm is gaan liggen, is er als het goed is een bepaalde norm binnen het team. Je merkt dat het een leuk team aan het worden is. Ze vinden zichzelf ook leuk, en vaak ook goed, en je ziet ze groeien. Het teamgevoel komt meer en meer en de wil om te presteren is er. Toch is het op sommige plekken nog een beetje ruw. Ze geven elkaar gevraagd en ongevraagd feedback, nieuwe mensen worden niet snel opgenomen en ook samenwerking met andere teams kan nog wat onwennig zijn. Ik wil niet de vergelijking trekken met motorclubs, maar vergelijk het toch maar een beetje hiermee. Misschien gaan ze zelfs leren jasjes maken waar hun zelfbedachte teamnaam en logo opstaat. Hoe dan ook, er worden vaak al mooie resultaten geboekt door het team, maar toch kun je als coach nog veel waarde toevoegen bij een groep die in norming zit. Ga eens successen met ze vieren. Iets waar we in Nederland niet zo goed in zijn, maar wat echt bewezen helpt om (zelf)vertrouwen te krijgen. Leg de successen tijdens demo’s onder de loep, hang een bel op in teamspace en elke keer als er een user story af is, of als een increment live is gegaan luidt het team de bel. Het lijkt heel Amerikaans, maar ik daag je uit om het te doen, het werkt! Zet daarnaast in op het lerend en reflecterend vermogen van het team, en help de sterke en minder sterke kanten te zien. Faciliteer een sessie waarbij de teamleden zich uitspreken over wat ze willen leren en wat ze nodig hebben. Spannend, echt heel gaaf om te doen! Barcelona in de zomer van 1992, Olympische Spelen. Als je toevallig daar was dan had je de kans om een team te zien dat Tuckman zou beschrijven als performing. Ik heb het hier natuurlijk over het Dream Team, het basketbalteam dat de VS vertegenwoordigde. Michael Jordan, Scottie Pippen, Magic Johnson en Larry Bird waren onderdeel van dit team, om er maar een paar te noemen. Dit team won uiteraard goud, niet alleen omdat ze de beste spelers waren (het hielp wel), maar ook omdat de spelers zich onderdeel voelden van een groter geheel. De manager van het team hoefde deze spelers niks uit te leggen, alleen maar te faciliteren. Constant kijken wat ze nodig hebben om nog beter te kunnen worden als team. Iedereen had zijn eigen rol in dit team, maar wist elkaar te vinden om te scoren, met natuurlijk als groter einddoel, die gouden plak om de nek. Als jij ooit een Dream Team mag coachen, dan kun je nog steeds van waarde zijn als Agile Coach. Maak kennisdeling mogelijk zodat teamleden elkaar beter kunnen maken, vier de successen die ze bereiken en neem hier andere afdelingen in mee. Bijvoorbeeld die ene afdeling waar een grote afhankelijkheid mee was. En probeer te experimenteren met nieuwe manieren van werken. Andere frameworks en nieuwe practices kunnen dit team helpen zichzelf opnieuw uit te vinden en zo nog beter te worden. Vergeet niet dat dit allemaal niet zwart-wit is. Het kan heel goed zijn dat verschillende fases in elkaar overlopen, dat een team op sommige vlakken al in een volgende fase zit of juist een fase terug gaat. Waar dit model je vooral bij kan helpen is om voor jezelf een snelle inschatting te maken, deze te toetsen en je wat handvatten kan geven om interventies te kunnen doen. Daarnaast is het niet raar dat als je werkt met een team, het zomaar kan zijn dat er iets gebeurt waardoor ze weer terugvallen in oud gedrag en daarmee weer kenmerken vertonen van een andere fase. Dit is heel normaal en betekent werk aan de winkel! Ik hoop dat deze uitleg van het model je heeft kunnen aanzetten tot denken en doen. Mocht je meer willen weten, of hulp nodig hebben bij de ontwikkeling van je teams laat het mij vooral weten. Je kunt mij altijd een bericht sturen op info@towson.nl.

De transformatie van managementteam naar leadershipteam,…

Geschreven door Marieke Bosscher op 22 maart 2023. Gepost in Agile, SAFe, Teamontwikkeling.

…en het positieve effect op resultaat en voorspelbaarheid

door Peter Turien Wanneer ik bij opdrachtgevers te gast ben, hoor ik nog steeds met grote regelmaat de verzuchting dat teams in deze organisaties niet de verwachtte of nodig geachte resultaten leveren. De oorzaak van het niet betrouwbaar leveren van de teams wordt dan bijna altijd binnen deze teams gezocht. De oorzaak kan echter ook voor een groot deel in de verhouding en samenwerking tussen het managementteam en de organisatie liggen. De effectiviteit van de organisatie wordt mede bepaald door de opstelling van de leiders. Deze kant van het “leveringsprobleem” wordt regelmatig onderbelicht. Omdat de oorzaak in eerste aanleg bij de leverende teams zelf wordt gezocht, wordt er teamcoaching ingezet. Coaches gaan dan met deze teams aan de slag met bijvoorbeeld de piramide van Lencioni om vanuit vertrouwen naar resultaat te komen. Nu ben ik een warm voorstander van de inzet van teamcoaching (en ook van Lencioni), maar dit lost alleen het probleem op wanneer de oorzaak van het probleem daadwerkelijk in de teams zit. Wanneer teamcoaching niet de gewenste resultaten oplevert is het tijd om ook eens heel goed naar de leiders van een organisatie te kijken en naar hun manier van aansturing. Want de oorzaak van onvoorspelbare teams en lage kwaliteit leveren kan ook een leiderschapprobleem zijn, doordat de leiders van een organisatie een managementteam vormen in plaats van een leadershipteam. Om aan te geven hoe ik het verschil zie tussen een managementteam en een leadershipteam: Een managementteam streeft een resultaat na, deelt dit doel en geeft de organisatie aan welke bijdrage ze verwacht. De bijdrage wordt gemeten om te zien of de organisatie daadwerkelijk het resultaat haalt, en er wordt indien nodig bijgestuurd. Een leadershipteam streeft een resultaat na, vraagt de organisatie welke bijdrage ze hieraan kan leveren, en wat er nodig is om samen het doel te behalen. Het verschil zit in de kunst van het loslaten door de leiders en de juiste ruimte te geven. Alleen wanneer de leiders van een organisatie medewerkers de juiste ruimte geven, zullen medewerkers verantwoordelijkheid nemen en zich kunnen committeren aan een resultaat. In mijn voorbeeld van een managementteam, neemt dit team alle verantwoordelijkheid voor het resultaat en sluit de rest van de organisatie bijna automatisch aan op basis van “best effort”. Teams en medewerkers kunnen geen eigenaarschap nemen voor commitments die door anderen zijn beschreven. In mijn voorbeeld van een leadershipteam worden de teams uitgenodigd om gezamenlijk verantwoordelijkheid te nemen. De teams kunnen aangeven wat ze haalbaar achten en kunnen daarmee ook verantwoordelijkheid nemen voor hun werk. Hierdoor wordt het doel dat een organisatie probeert te behalen, een gezamenlijk doel. Daarmee zijn organisaties met leadershipteams waar de verantwoordelijkheid voor het resultaat laag in de organisatie genomen wordt, naar mijn mening, op de langere termijn gemeten effectiever dan organisaties waar een managementteam resultaatverantwoordelijkheid neemt. Kortom, investeren in zelfsturende teams is goed, maar niet voldoende. Organisaties moeten ook investeren in de transformatie van managementteams naar leadershipteams. De kunst van het juist loslaten wordt verzilveringsmiddel op voorspelbaarheid en de kwaliteit van de te leveren producten. Om als managementteam een leadershipteam te worden is de Piramide van Lencioni een effectieve leidraad om de relatie met de teams te herdefiniëren. Echter: in plaats van bij “vertrouwen” te beginnen en ons een weg door de piramide naar boven te werken naar “resultaat”, is het in dit geval effectiever om te beginnen bij het niveau resultaat. Door als leadershipteam goed te articuleren wat de missie en visie van de organisatie zijn en welke resultaten behaald moeten worden, weten de teams in de organisatie waar ze zich op dienen te concentreren. Het gesprek tussen het leadershipteam en de organisatie kan dan gaan over hoe we herkennen dat resultaten behaald worden. Het voeren van het gesprek langs de as van duidelijk uitgesproken doelen en gewenste resultaten is de basis voor de leadershipteams om te vragen welke bijdrage de teams kunnen leveren. Door de mate van de bijdrage door de teams te laten bepalen, wordt teams de ruimte geboden om verantwoordelijkheid te nemen. De cynische manager zegt nu: “Als ik het aan de teams overlaat krijg ik nooit wat ik wil”. De praktijk heeft echter bewezen dat de mensen in een organisatie die geen manager zijn wel degelijk naar het werk komen om de beste bijdrage te leveren. Het kan natuurlijk zo zijn dat de ambitie van de organisatie niet alligned is met waar de teams verantwoordelijkheid voor kunnen nemen. En dit is precies het cruciale moment waar leadershipteams zich onderscheiden van managementteams en de betrokkenheid bij de teams tonen. Dit kan enerzijds door de teams te vragen of er een ondersteuning mogelijk is waarmee de teams de verantwoordelijkheid wel kunnen nemen voor de ambitie die het leadershipteam geuit heeft. En vervolgens aan de andere kant het te accepteren wanneer de teams aangeven dat ze, ondanks het aanbod voor hulp, niet meer verantwoordelijkheid kunnen nemen. Dit is in het begin zeker even wennen, maar als leadershipteams dit kunnen en durven accepteren, zit juist in dit punt voor de organisatie een enorm geschenk verscholen. Een organisatie weet nu al heel vroeg dat een bepaalde ambitie niet of later waargemaakt kan worden. Hierdoor kan er heel vroeg actief verwachtingsmanagement gedaan worden en aan mogelijke alternatieven gewerkt worden; in tegenstelling tot de “gemanagete” organisaties waar het doel toch opgelegd wordt en het moment van niet kunnen waarmaken van de ambities pas laat in het proces duidelijk wordt. Voor het managementteam rest alleen nog damagecontrol als optie. Wanneer de relatie tussen het leadershipteam en de teams al zo gezond is dat er ruimte is voor het nemen van verantwoordelijkheid van de teams, en de leadershipteams zich niet meer bezighouden met de “hoe” vraag, dan is de basis gelegd voor een open en gelijkwaardig gesprek. De organisatie komt nu al tot op het niveau van de “constructieve conflicten”. Dit is heel waardevol omdat leadershipteams die dit niveau bereiken relevante informatie tijdig krijgen. Dit zijn de middelen om bij te sturen én effectief verwachtings- en stakeholdermanagement te doen, kortom: de middelen om als leadershipteam zelf eigenaarschap over de situatie te kunnen nemen en betrouwbaar naar de stakeholders te zijn. Wat dan nog overblijft is het niveau “vertrouwen”. Dit ontstaat, bijzonder genoeg, op heel korte termijn op basis van het doorlopen van de vorige niveaus. De mate en het vast kunnen houden van vertrouwen worden bepaald door als leadershipteam koersvast te blijven en de organisatie te blijven faciliteren, en niet alsnog namens de teams te gaan denken wanneer de situatie lastiger is. Vooral leadershipteams die niet terugvallen in oude gewoontes, geven een enorme boost in het vertrouwen van de teams, en daarmee grote stimulans voor teams om er alles aan te doen om effectief en voorspelbaar te blijven. Wil je hierover verder praten met mij, of met een van onze coaches? Neem dan contact op met ons: stuur een mail naar info@towson.nl of neem telefonisch contact op: 085 877 0180. Onze Teamtraining Lencioni en DISC besteedt uitgebreid aandacht aan leiderschap en samenwerking. Wil je meer weten over deze teamtraining, klik dan hier.

scrum grandmaster scrum grandmaster scrum grandmaster scrum grandmaster scrum grandmaster

De Scrum Grandmaster

Geschreven door Marieke Bosscher op 20 maart 2023. Gepost in Agile, Coaching, SAFe.

Door William van der Maas Iedereen kent de Scrum Master, maar bestaat er ook zoiets als de Scrum Grandmaster? Iemand die excelleert in het Scrum Master vak en als inspiratiebron dient voor andere Scrum Masters. Iemand waarbij je misschien in de leer kunt gaan net zoals vroeger ambachtslieden ook in de leer gingen bij een grootmeester. En als deze Scrum Grandmaster al bestaat, hoe zou je hem of haar kunnen herkennen? Waar zou deze dan in uitblinken? Om die vraag te kunnen beantwoorden moet je eerst iets van een meetlat hebben. Maar naar welke aspecten kun je dan kijken? Dit zijn sowieso goede vragen. Want hoe trek je eigenlijk een nieuwe Scrum Master aan in je organisatie? Op welke onderdelen kun je een Scrum Master toetsen tijdens een intake? In mijn zoektocht naar een geschikte meetlat stuitte ik al snel op het ACI’s Agile Coach Competency Framework uit 2011. Dit framework onderscheidt de acht competenties en coaching stances van een Agile Coach. In 2019 heeft Jonathan Kessel-Fell een waardevolle bijdrage geleverd en het framework verder uitgebouwd. Dit framework bestaat nu uit in totaal tien competenties en coaching stances. In een volgende blog leg ik uit hoe je dit framework kunt gebruiken. Voor nu hebben we genoeg aan de competenties en stances.

Zoals je ziet bestaat dit framework uit de volgende tien competenties en stances:

Agile Lean: Kennis van Kanban, Scrum, XP, DevOps en Lean-Agile principes, alsook van Scaling frameworks zoals Less, SAFe en DA. Maar ook hoe je deze kennis als Scrum Master in de praktijk kunt inzetten.
Mindset & Behaviour: Als Scrum Master ben je een levend voorbeeld van Servant Leadership en leef je naar de waarden en principes die horen bij een Agile-mindset.
People and Influence: Hier komen de soft-skills om de hoek kijken. Een Scrum master weet wanneer hij of zij deze in welke situatie het beste in kan zetten. Bij deze competentie draait het om de vaardigheid om mensen of situaties positief te beïnvloeden en zo blijvende verandering te bewerkstelligen.
Coaching: Bij professionele coaching draait het om onpartijdig te zijn van het doel. Je gelooft in de mensen of in het team. Je werkt als coach met ze samen en helpt daarbij om problemen op te lossen door middel van hun eigen kennis en vaardigheden. Je zorgt er voor dat mensen en teams om je heen het beste in zichzelf naar boven laten komen.
Facilitating: Je helpt als Scrum Master teams met het faciliteren van verschillende activiteiten zoals bijvoorbeeld een retrospective of een Inspect & Adapt event. Hierbij ben je zelf onpartijdig. Je hebt dus van te voren geen vastgesteld verwacht resultaat.
Teaching: De vaardigheid van een Scrum Master om door middel van lesgeven kennis over te brengen op andere mensen. Denk hierbij aan het lesgeven over hoe een Sprint Planning werkt.
Mentoring: Ook bij deze competentie draait het om het overbrengen van kennis, alleen op een veel subtielere manier. Je gebruikt als Scrum Master bijvoorbeeld vaak de zin “In mijn ervaring… heb ik dit en dit geprobeerd”. Ook breng je deze kennis 1 op 1 over in plaats van op grote groepen mensen.
Technical Mastery: Ervaring in het organiseren van technische activiteiten op het gebied van bijvoorbeeld architecture, design, coding en test engineering en de daarbij behorende tooling. Deze kennis en vaardigheden kun je als Scrum Master gebruiken om kwaliteit standaarden te promoten. Deze technische ervaring strekt zich ook uit tot Scaling en DevOps.
Business Mastery: Vaardigheden in het toepassen van business strategy en change leadership om Agile en Lean als concurrentievoordeel in te zetten. Denk hierbij ook aan ervaring met technieken als Lean Start-up, design thinking, product innovatie, flow-based business process management en andere technieken die betrekking hebben op innovatie en samenwerking binnen de organisatie.
Tranformation Mastery: De vaardigheid om organisatieverandering en transformatie op gang te brengen. Denk hierbij ook aan verandering van cultuur, organisatiestructuur, transformation leadership, system thinking en andere gedragswetenschappen.

Voor het aantrekken van nieuwe Scrum Masters is deze lijst met competenties sowieso al heel waardevol. Zo heeft een organisatie die net begonnen is met het introduceren van Scrum waarschijnlijk veel meer behoefte aan een Scrum Master die goed is in het overbrengen van kennis en ervaring. Anderzijds heeft een organisatie die al langer scrumt waarschijnlijk behoefte aan een Scrum Master die de teams of zelfs de complete organisatie coacht en zo het beste in haar mensen naar boven haalt. Nu rijst bij mij wederom de vraag: bestaat er dan een Scrum Grandmaster die op al deze gebieden uitblinkt? Of zou een Scrum Grandmaster juist op slechts 1 van deze competenties uitblinken en zo het voorbeeld kunnen zijn voor alle andere Scrum Masters? In een reeks van korte blogs, interviews en video’s neem ik jullie mee in mijn zoektocht naar de Scrum Grandmaster en alles wat ik daarbij ontdek. Wordt vervolgd… Mocht je een keer met William willen sparren over dit, of een ander, onderwerp, dan kun je contact met hem opnemen, een e-mail sturen naar info@towson.nl of telefonisch contact met ons opnemen: 085 877 0180. Vind je dit een nuttig artikel, dan is onze SAFe Advanced Scrum Master training zeker iets voor jou. Wil je meer weten over deze training, klik dan hier.

Duurzame inzetbaarheid

Geschreven door Marieke Bosscher op 19 maart 2023. Gepost in Agile, SAFe, Trainingen.

In dit artikel over duurzame inzetbaarheid gaat Marlies Kreuk niet in op het investeren in persoonlijke ontwikkeling. Hoe je dit voor jezelf kan doen, maar ook hoe je vanuit goed werkgeverschap namens je werkgever kan ondersteunen. Het artikel sluit uitstekend aan bij het artikel dat Orpheo Ormskerk onlangs over de “growth mindset” heeft geschreven. Toen ik ruim 5 jaar geleden bij een grote (IT)opleider kwam te werken had ik nog nooit dit begrip gehoord. Naar mate ik meer ervaring op deed, kwam dit fenomeen steeds meer naar voren in de gesprekken die ik voerde met werknemers en bedrijven. Toen ik 2,5 jaar geleden startte in een leidinggevende functie, kwamen ook de HR-workshops over hoe ik mijn team, mensen van millenials tot 50-plussers, op een duurzame manier kon laten ontwikkelen. Met de constante en steeds snellere veranderingen wordt er steeds meer gevraagd van de werknemer. De scheidslijn tussen IT-bedrijven en traditionele organisaties wordt steeds vager en zal op den duur waarschijnlijk helemaal verdwijnen. Immers elk bedrijf, klein of groot, heeft tegenwoordig te maken met IT en bijbehorende kennis en processen. (Bij)scholing in IT is al lang niet meer voor de beroeps IT ’er, maar voor iedereen die in zijn of haar werk met IT te maken heeft. Nu ik zelf bij een Agile consultancy practice werk, zie ik ook juist veel opdrachtgevers die niet van origine IT-bedrijven zijn. Juist zij omarmen het Agile werken om de vele nieuwe mogelijkheden die het biedt voor de organisatie en de mensen die er werkzaam zijn. Daarnaast wordt er gelukkig ook steeds meer aandacht besteed aan de persoonlijke ontwikkeling van de werknemer. Samenwerking, zelfreflectie en feedback geven zijn zaken waar organisaties steeds meer belang aan hechten. En terecht ook, is mijn mening. De beste prestaties behaal je als je vertrouwen hebt in jezelf en in je team en er een transparante en veilige werkcultuur heerst. Dit houdt echter wel in dat je als werknemer dus over de as van de vak inhoud, de techniek en persoonlijke groei moet blijven ontwikkelen. Er is hier alleen 1 ‘probleempje’…. Volgens Prof. dr. Kim Putters, Directeur Sociaal en Cultureel Planbureau, laat onderzoek zien dat veel werkenden geen duidelijk beeld hebben van de veranderingen op de middellange termijn in hun werk, en wat die voor hun eigen competenties betekenen. Zij voelen geen urgentie om te blijven leren. Vaak besluiten zij pas om zich verder te scholen wanneer zij concreet uitzicht hebben op ander werk, of wanneer zij de overstap naar een andere baan al hebben gemaakt. Tegelijkertijd maakt het onderzoek duidelijk dat een deel van de werkenden wel degelijk belemmeringen ervaart voor het blijven leren. Voor het zich een leven lang ontwikkelen dient er tijd en geld beschikbaar te zijn, evenals maatwerk in scholingsvoorzieningen. [1] Uit ditzelfde onderzoekt blijkt dat maar een kleine 19% van de Nederlandse beroepsbevolking deelneemt aan een opleiding of cursus. Dit is weliswaar ruim boven de EU-norm, we zitten bij de top-5 landen, maar toch bekruipt mij hier het gevoel dat we er nog lang niet alles uithalen. Het AWVN heeft namelijk in 2018 al onderzoek gedaan[2] waaruit blijkt dat in 5 jaar tijd het budget wat vanuit werkgevers beschikbaar wordt gesteld voor scholing (volgens cao-afspraken), gestegen is van 1 miljoen werknemers naar 2,3 miljoen. En er zijn nog duizenden bedrijven die hierover afspraken hebben vastgelegd buiten de CAO’s om. Kortom, er liggen dus miljarden euro’s op de plank die ingezet kunnen worden door de werknemers zelf om zich over de technische, inhoudelijke of persoonlijke as verder te ontwikkelen. ‘Makkelijk op te lossen, de werknemer moet hier dus gewoon zijn eigen verantwoordelijkheid in nemen’ zou je nu kunnen roepen. En deels is dit ook zo, maar veel mensen ervaren van nature weerstand om zaken anders aan te pakken dan dat ze altijd gedaan hebben. Ook vinden velen het gewoonweg spannend om met de werkgever om tafel te gaan en het over hun ontwikkeling met de bijbehorende budgetten te hebben. Anderzijds willen veel bedrijven ook graag verder ontwikkelen, maar lopen ze nog vast hoe ze de werknemers op een duurzame en positieve manier mee kunnen nemen in impactvolle veranderingen zoals een Agile transformatie. Mijn conclusie is dan ook dat we vooral met elkaar in gesprek moeten blijven over duurzame oplossingen en de hulpvraag moeten blijven durven stellen. Stel bijvoorbeeld als werknemer eens de vraag aan je werkgever hoe hij jou kan ondersteunen in de veranderingen binnen jouw afdeling. Of stel als werkgever eens de vraag wat je werknemer van jou nodig heeft om mee te kunnen in de visie van de organisatie. En ga vooral ook vrijblijvend in gesprek met organisaties die jullie hierbij kunnen helpen. Nu het einde van het jaar nadert, is dit de uitgelezen kans voor zo’n gesprek. Want uit onderzoek van Springest blijkt dat bijna de helft (!) van het jaarlijkse opleidingsbudget wat werknemers hebben onbenut blijft. Meer dan 1 miljoen werknemers en duizenden werkgevers, en waarschijnlijk nog veel meer, laten hun kans op duurzame ontwikkeling hier liggen. En het zou toch zonde zijn als jij dit jaar één van hen bent. Wil je als werkgever of als werknemer eens sparren hoe je in kunt spelen op veranderingen die over de technische (IT) as gaan, bijvoorbeeld m.b.t. Agile werken? Maar ook hoe je hier als team of als management mee om moet gaan? En ben je benieuwd hoe je jouw organisatie-of persoonlijk budget hiervoor kan inzetten? Neem dan contact op met ons via 085 877 0180 of mail naar peter.turien@towson.nl. Ik ben benieuwd naar jullie vraag en ga graag met jullie in gesprek. [1] Grenzen aan een leven lang leren, Ralf Maslowski (m.m.v. Ria Vogels), SCP 2019 [2] https://www.awvn.nl/nieuws/persbericht/verdubbeling-budget-duurzame-inzetbaarheid/

Scrumvsagile Scrumvsagile Scrumvsagile Scrumvsagile Scrumvsagile

Scrum: De Scrum Master vs. Agile Coach

Geschreven door Marieke Bosscher op 18 maart 2023. Gepost in Agile, Coaching, SAFe.

Wanneer je rolomschrijvingen en vacatureteksten van de Scrum Master en Agile Coach leest, dan valt het op dat die nogal verschillen van elkaar. Toch is er in de praktijk veel overlap in de rollen binnen een organisatie. Kevin Roberts deelt in dit artikel zijn visie. Steeds meer organisaties willen hun wendbaarheid vergroten. Logisch, want we leven in een tijd waarin digitale innovaties elkaar in een rap tempo opvolgen en markt- en klantbehoeften continu veranderen. Agile werken biedt een uitstekende basis om je organisatie snel toe te rusten op de uitdagingen van nu en morgen. De Scrum Master en Agile Coach zijn twee personen die een belangrijke rol spelen binnen deze werkwijze. Het succes van een Scrum-project blijkt telkens grotendeels af te hangen van de samenwerking tussen deze twee professionals. Maar wat doen deze Scrum Master en Agile Coach? En welke methoden en tools gebruiken ze om een project te doen slagen en managers te betrekken bij het Scrumproces? Lees verder om erachter te komen.

Wat is een Scrum Master?

De Scrum Master zorgt ervoor dat het team met volle focus kan werken aan de afgesproken doelen en heeft als lid van een Scrumteam een voortrekkersrol binnen dit gezelschap. Hij/zij is verantwoordelijk voor het aansturen van het team en is dagelijks op de werkvloer aanwezig. De Scrum Master streeft ernaar om alle ins en outs van een team en project te kennen. Concrete taken van de Scrum Master zijn onder meer:

Erop toezien dat een team en organisatie werken volgens de principes en spelregels van Scrum.
Het regelen van allerlei praktische zaken. Denk bijvoorbeeld aan het inplannen van vergaderingen, sprintplanningen en brainstormsessies en het zoeken naar procesverbeteringen.
Het tackelen van problemen die het Scrumteam zelf niet kan oplossen.

Een Scrum Master moet ook de rol van ‘change agent’ kunnen invullen. Een change agent is iemand die een leidende rol speelt bij het doorvoeren van een veranderingstraject binnen een organisatie. Dit betekent dat de Scrum Master een gidsende en faciliterende rol heeft en teams in beweging zet. Dat doet hij door:

kennisdeling binnen de organisatie te stimuleren en faciliteren;
besluitvorming inzichtelijk te (laten) maken;
en een duidelijke visie met bijbehorende doelstellingen op te (laten) stellen.

De Scrum Master faciliteert dus in de breedste zin van het woord de processen die digitale transformatie versnellen en jouw organisatie flexibeler maken.

Wat is een Agile Coach?

De rol van een Agile Coach heeft wel raakvlakken met die van een Scrum Master, maar is toch net iets anders. De Agile Coach is geen vast lid van een Scrumteam. Hij heeft een onafhankelijke rol en coacht meerdere teams en het management. Bovendien is de Agile Coach vaak iemand die niet zozeer gericht is op de inhoud van een Scrumproject, maar vooral ook bezig is met het proces. Agile Coach is binnen Scrum geen officiële functie. De Scrum Guide noemt haar bijvoorbeeld niet. Het ontbreken van een officiële definitie betekent dan ook dat organisaties de positie van Agile Coach in de praktijk vaak op verschillende manieren invullen. Toch zijn er wel een aantal taken binnen een Scrumproject die meestal op het bord van de Agile Coach belanden. Denk bijvoorbeeld aan de onderstaande verantwoordelijkheden.

Teams en medewerkers bewust maken van hun sterke punten en minder sterke kanten. Het doel daarvan? Ervoor zorgen dat zowel de organisatie als individuele medewerkers zich kunnen ontwikkelen richting een agile-mindset en -werkwijze.
Het creëren en borgen van een gezonde en goede groepsdynamiek. Dit doet de Agile Coach door medewerkers de juiste tools en technieken aan te reiken en geregeld de samenwerking te evalueren.
Individuen en teams ondersteunen met behulp van mentoring, coaching en teaching.

Twee worden één

Managers en organisaties maken nogal eens een onderscheid tussen de rollen van Scrum Master en Agile Coach. De Scrum Master wordt dan voorgesteld als iemand die alleen verstand heeft van Scrum, terwijl de Agile Coach over een groter kennisreservoir en uitgebreidere toolkit zou beschikken. De Scrum Master is volgens die visie eigenlijk een ‘junior Agile Coach’. In werkelijkheid is het onderscheid tussen de twee niet zo scherp en zeker niet zo hiërarchisch. Vergelijk het met twee flessen cola van een verschillend merk: het etiket is anders en de smaak verschilt enigszins, maar in de basis zijn er meer overeenkomsten dan verschillen. In de praktijk versmelten de rollen van Scrum Master en Agile Coach steeds meer. Traditioneel leeft vaak het idee dat de Scrum Master alleen actief is op het teamniveau en de Agile Coach vooral op enterprise-niveau. Hoewel het klopt dat de Scrum Master vaak begint op teamniveau, evolueert hij vaak mee met de organisatie naarmate die beter wordt in het adopteren en toepassen van Scrum en andere agile-methodieken. Hierdoor werkt hij ook steeds vaker direct samen met de hogere echelons binnen een organisatie.

De les: dek alle competenties goed af

Of je nu kiest voor een Scrum Master en een aparte Agile Coach of beide functies samenbrengt in een en dezelfde persoon: zorg er in elk geval voor dat alle kennisgebieden en praktische onderdelen van Scrum goed zijn afgedekt. Dit betekent dat je niet alleen de juiste kennis in huis hebt, maar ook op het vlak van communicatie, motivatie en taakafstemming alles goed op orde hebt.

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.

Geschreven door admin op 12 maart 2023. Gepost in Coaching, SAFe, Teamontwikkeling.

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.

Deadline-Release Deadline-Release Deadline-Release

Foute keuzes na gemiste deadlines in een agile omgeving

Geschreven door Marieke Bosscher op 4 maart 2023. Gepost in Agile, SAFe.

1. Introductie

Scrum teams hebben net als traditionele waterval teams te maken met deadlines. Om diverse redenen kan het voorkomen dat nieuwe functionaliteiten niet op tijd gereleased worden. Dat is zuur. Zeker omdat de volgende wijzigingen vaak al in de planning zijn opgenomen.

2. Combineren van releases

Een voor de hand liggende oplossing lijkt het combineren van de verschillende releases. Dan kun je bijvoorbeeld alle testen combineren en hoef je alles maar 1x te testen. Hierdoor creëer je tijdwinst en kom je de eerstvolgende release weer in de normale heartbeat (cadans). Het tegendeel is echter waar. Het samenvoegen van releases levert geen tijdwinst op. Het kost zelfs meer tijd. Veel meer tijd. Oorzaken zijn onder andere: – Door meer te wijzigen wordt de scope vergroot en neemt de kans op defects toe. Blijft het aantal ontwikkelaars gelijk dan ontstaat er een defect queue (bottleneck). Testen staan hierdoor stil totdat fixes worden opgeleverd. Een grotere scope leidt tot een exponentieel grotere defect queue. – De development- en testinfrastructuur blijft hetzelfde. Hierdoor ontstaat wachttijd (waste). Zo kunnen sommige testen bijvoorbeeld niet parallel uitgevoerd worden op dezelfde testomgeving waardoor ze op elkaar moeten wachten. – De coördinatie en afstemming tussen teams en afdelingen neemt exponentieel toe. – Omschakeltijd. Schakelen tussen verschillende activiteiten kost tijd. Voorbeeld: Een teamlid stuit tijdens het testen op een blokkerend defect en wil hierdoor een andere test opstarten. Hiervoor moet eerst nieuwe testdata klaargezet worden, ingelogd worden met een ander gebruikersaccount, etc. – Scopecreep. Hoe langer een release onderhanden is, hoe meer “extra functionaliteiten” van alle kanten toegevoegd worden. Denk hierbij bijvoorbeeld aan hotfixes. Kortom: Het vergroten van de scope zal dus door verschillende oorzaken exponentieel toenemen.

3. Release early, release often

In plaats van de scope te vergroten door releases te combineren adviseer ik met klem het tegenovergestelde. Maak de scope juist kleiner zoals het Agile Manifesto ook voorschrijft en release vaker. De volgende technieken kunnen helpen bij het verkleinen van de scope: – Dark Launches: Release van code naar productie waarbij de functionaliteit niet beschikbaar/zichtbaar is voor de eindgebruiker. – Feature toggles: Een techniek waarbij je gebruik maakt van Dark Launches waarbij je de mogelijkheid inbouwt om de functionaliteit op een later tijdstip alsnog aan/uit te zetten. – Canary release: Een techniek waarbij je de functionaliteit alleen beschikbaar maakt voor een selecte groep gebruikers. Vervolgens meet je de feedback en kun je er voor kiezen om op een later tijdstip de functionaliteit alsnog te releasen naar meer gebruikers. – Decouple release elements: Een release kan in de regel opgeknipt worden naar kleinere elementen die apart van elkaar live gebracht kunnen worden.