Buzz blog

Taking leadership on personal development: Go for a run

Wed, 24 Jan 2024 15:08:44 GMT

Good intentions

I have decided to run a half marathon for the first time in the spring of 2024. Not particularly special you can say, because plenty of people do that. It is not just a resolution taken on the threshold of the new year with a glass of champagne in hand. I am progressing well in the training program. We often make resolutions that don’t go beyond good intentions. We want something or we think we want something to further develop ourselves, however we often don't get it done. The cause of this lies in your environment or yourself. So much for stating the obvious. But how are you going to initiate that personal development?

Taking time for personal development

The organization where you work is part of your professional environment. There are probably training opportunities available and even a personal development plan may be drawn up. There is often a certain budget available to spend on training for which your request is rejected or granted. Suppose you are allowed to do that training, can you actually spend the required time on it? Because there is also work that needs to be done. Frank Oeben has shared a nice insight on this [sorry only in Dutch language]: “ Tijd hebben en nemen voor persoonlijke ontwikkeling ”.

Choose personal leadership

Then let's talk about your own motivation to develop yourself. Resolutions that do not achieve a desired result are probably not relevant resolutions for your personal development. Due to external influences, there may be intentions in your personal development plan for which you cannot muster motivation. It is therefore important to reach your self-chosen intentions. This way you take leadership over your personal development. Then it will be fun and probably successful. The Agile Leiderschap Canvas can help you set relevant development goals for yourself. This is not just about deciding which training you want to follow, but about developing competencies and behavior.

Half marathon

Last summer I created space to think about what I wanted to put on my personal development backlog. In addition to a number of work-related developments, endurance running was also introduced as a sporting activity in the mix of work and relaxation. For me, that half marathon has become a metaphor for taking time and space for personal development. Making relevant intentions, setting achievable goals and actually implementing the development. When that first half marathon is over, I will look back on the result and on the way I have achieved that. I will then bring these insights to the next moment when I create a new personal development backlog.

My personal manifesto includes: “Go for a run”. Wish me a lot of fun.

Leiderschap nemen over persoonlijke ontwikkeling: Ga hardlopen

joost.comperen@gmail.com — Wed, 24 Jan 2024 13:27:24 GMT

Goede voornemens

Ik heb me voorgenomen om voor het eerst een halve marathon lopen in het voorjaar van 2024. Niets bijzonders kun je zeggen, want dat doen zoveel mensen. Het is niet enkel een voornemen dat is genomen op de drempel van het nieuwe jaar met een glas champagne in de hand. Ik ben lekker op weg met het trainingsschema. We maken vaak voornemens die niet verder komen dan het voornemen zelf. We willen iets of we denken iets te willen om onszelf verder te ontwikkelen, maar we krijgen het vaak niet voor elkaar. De oorzaak daarvan ligt in je omgeving of bij jezelf. Tot zover de open deur. Maar hoe ga je die persoonlijke ontwikkeling dan in gang zetten?

Tijd nemen voor persoonlijke ontwikkeling

De organisatie waar je werkt is onderdeel van jou professionele omgeving. Daar zijn vast opleidingsmogelijkheden en wordt er misschien zelf een persoonlijk ontwikkelplan gemaakt. Vaak is er een bepaald budget beschikbaar om te besteden aan een training waarbij jouw verzoek wordt afgewezen of toegekend. Stel dat je die training mag doen, kun je er dan de tijd voor nemen? Want er is ook werk dat moet worden gedaan. Frank Oeben heeft hierover een mooi inzicht gedeeld: “ Tijd hebben en nemen voor persoonlijke ontwikkeling ”.

Kies voor persoonlijk leiderschap

Dan nog even over jouw eigen motivatie om jezelf te ontwikkelen. Voornemens die niet tot een gewenst resultaat komen, zijn waarschijnlijk geen relevante voornemens voor jouw persoonlijke ontwikkeling. Door invloeden van buitenaf staan er mogelijk voornemens in je persoonlijk ontwikkelplan waar je geen motivatie voor kunt opbrengen. Het is dus zaak om tot jouw zelf gekozen voornemens te komen. Zo neem je leiderschap over je persoonlijke ontwikkeling. Dan wordt het leuk en waarschijnlijk succesvol. Het Agile Leiderschap Canvas kan je helpen om relevante ontwikkeldoelen voor jezelf te stellen. Dat gaat niet enkel over het bedenken welke training je wilt volgen, maar over het ontwikkelen van competenties en gedrag.

Halve marathon

Afgelopen zomer heb ik ruimte gecreëerd om te bedenken wat ik op mijn persoonlijke ontwikkel backlog wil zetten. Naast een aantal werk gerelateerde ontwikkelingen, kwam ook de duurloop erop te staan als invulling van de sportieve activiteit in de mix van werk en ontspanning. Die halve marathon is voor mij de metafoor geworden voor het nemen van tijd en ruimte voor persoonlijke ontwikkeling. Het maken van relevante voornemens, het stellen van haalbare doelen en het daadwerkelijk uitvoeren van de ontwikkeling. Als die eerste halve marathon erop zit, kijk ik terug op het resultaat en op welke manier ik tot dat resultaat ben gekomen. De inzichten neem ik dan weer mee naar het volgende moment dat ik een nieuwe persoonlijke ontwikkelbacklog maak.

Op mijn persoonlijke manifest staat onder andere: “Ga hardlopen”. Wens me veel plezier.

Zelf organiseren is ook zelf oplossen

Wed, 19 Jul 2023 10:10:25 GMT

Waarom niets doen vaak beter is dan een interventie plegen. Dat gaat mogelijk tegen onze natuur in. Zeker wanneer we zien dat er iets fout dreigt te gaan. Want in je achterhoofd denk je aan de stakeholders die een verwachting hebben over wat er uit ‘de fabriek’ komt op een bepaald moment. Dan ben je geneigd om in te grijpen en te sturen. Lees in deel 1 van deze blog wat ik heb geleerd van WEL ingrijpen in een zelf organiserend team. Daaruit blijkt dat dat niet altijd de juiste keuze is bij het scrummen, als het ontwikkelteam zelf verantwoordelijkheid draagt over wat er wordt ontwikkeld en over het behalen van het sprintdoel. Zij organiseren zichzelf, dus het devies is: grijp niet in en laat het ze zelf oplossen. Lees wat ik heb geleerd van NIET ingrijpen.

Waarom ik NIET ingreep

Uit de periode dat ik wel ingreep gedurende een sprint heb ik geleerd dat het veel extra tijd kost en dat het ontwikkelteam het ervaart als bemoeienis. Dus geen interventies meer, maar het team zelf hun problemen laten oplossen. Ik heb daarom besloten om me meer terughoudend op te stellen naar het ontwikkelteam toe. Ook was ik niet meer bij elke Daily Scrum meeting aanwezig. Waarom zou ik? Het is hun verantwoordelijkheid om de product increment te maken op hun manier binnen de timebox van de sprint. Met gepaste afstand zag ik de probleemsituaties nog steeds voorbijkomen (transparantie) en door het team worden besproken, maar heb me er niet mee bemoeid.

Tot mijn plezier bleek dat aan het eind van de sprint vaak het sprintdoel gehaald werd. Het oplossend vermogen van het team was groot waardoor ogenschijnlijke problemen gedurende de sprint netjes werden opgelost, zonder concessies te doen aan functionaliteit of kwaliteit. De teamleden leerde van elkaar en van elke iteratie. Als extra bonus kwam het ontwikkelteam vroegtijdig naar mij toe in situaties wanneer het sprintdoel niet gehaald zou gaan worden. Dat kwam weinig voor. Samen vonden we dan een oplossing waarbij ik als Scrum Master een rol had in communicatie naar stakeholders toe.

Ben de coach

Zie je een noodzaak om te sturen, prima, doe dat dan na afloop van de ontwikkelactiviteit aan het einde van de sprint. Maak dus goed gebruik van de Agile rituelen die elke sprint staan gepland om terug te kijken op de ontwikkelactiviteit. Geef feedback op de product increment en de waarde die het oplevert (outcome). Coach het team in het continue streven naar het leveren van waardevolle verbeteringen van het product.

De sprint retrospective geeft je alle ruimte om samen te bespreken hoe de product increment tot stand is gekomen. Volgens de scrumgids 2017 past dit in het verband van zelforganisatie.

"Tegen het einde van de Sprint Retrospective zou het Scrum Team verbeteringen moeten hebben benoemd die geïmplementeerd zullen worden in de volgende Sprint. Het implementeren van deze verbeteringen in de volgende Sprint is de aanpassing naar aanleiding van de inspectie van het Scrum Team zelf."

Volgens de scrumgids 2020 :

"Het Scrum Team identificeert de meest nuttige veranderingen om zijn effectiviteit te verhogen. De meest impactvolle verbeteringen worden zo snel mogelijk aangepakt. Ze kunnen zelfs worden toegevoegd aan de Sprint Backlog voor de volgende Sprint."

Dit is dus het moment om de situaties te bespreken die zich tijdens de sprint hebben voorgedaan en hoe deze door het team zijn opgelost. Wat vinden we daarvan? Hoe kunnen we het voorkomen of een volgende keer effectiever oplossen? Wederom, coach het team in het zorgvuldig uitvoeren van deze inspectie om zinvolle aanpassingen te doen in toekomstige sprints. Daarvan groeit het team naar ‘high-performance’.

Er kan altijd iets onverwachts gebeuren gedurende een sprint dat effect heeft op capaciteit en functionaliteit. Om dergelijke situaties te voorkomen is het zaak als Scrum Master om scherp te zijn op het resultaat van de planningsbijeenkomst. De Scrumgids 2017 zegt:

"Aan het einde van de Sprint Planningsbijeenkomst zou het Ontwikkelteam in staat moeten zijn om aan de Product Owner en Scrum Master uit te leggen hoe zij van plan zijn, als zelf organiserend team, het Sprintdoel te behalen en het verwachte Increment te realiseren."

Volgens de scrumgids 2020 :

"Voor elk geselecteerd Product Backlog item plannen de Developers het werk dat nodig is om een Increment te maken dat aan de Definition of Done voldoet."

Stimuleer het team om de uitkomsten van de sprint review en sprint retrospective te gebruiken in de planningsbijeenkomst van de volgende sprint. Ik vertel hier waarschijnlijk niets nieuws over hoe deze scrumrituelen worden ingezet, maar ik wil benadrukken dat het de juiste plaats is om te sturen indien nodig.

Alles onder controle

Een collega van een andere afdeling vroeg regelmatig aan mij “En…alles onder controle?”. In het kader van transparantie geef je eerlijk antwoord. Toen ik nog wel ingreep tijdens het ontwikkelproces en met het idee een bepaalde controle te hebben over het eindresultaat, was het antwoord toch vaak ‘nee’. Dat kwam vooral doordat ik druk was met het willen oplossen van problemen voor het ontwikkelteam.

Toen ik niet meer ingreep tijdens het ontwikkelproces en het idee van controle had losgelaten, was het antwoord bijna altijd ‘ja’. Hoe komt dat nou? Teamleden voelden zich eigenaar van de increment, voelde zich daar 100% verantwoordelijk voor en zij kregen een grote verbondenheid met het product. Daar was niet meer die Scrum Master die ging ‘helpen’ met het oplossen van een probleem, dat kon het ontwikkelteam uiteraard zelf. Bovendien bleek vaak dat een potentieel probleem niet eens echt een incident werd, want het was opgelost voor het einde van de sprint. De scrumrituelen zijn de mechanismen om te sturen en vooral ook om te coachen en als team succesvol te zijn. Het antwoord is dan dus altijd: “Ja…alles onder controle.”

Foto: kantoorkat genaamd Jules

Ingrijpen in een zelf organiserend team

joost.comperen@gmail.com — Wed, 19 Jul 2023 10:07:07 GMT

Tijdens de Daily Scrum meeting, halverwege de sprint, merk je een zorgwekkende trend op. Een taak, onderdeel van de belangrijkste user story, loopt al drie dagen vertraging op. De afhankelijkheid met een ander agile team is complexer dan ingeschat. Dat wordt een probleem, want de stakeholders hebben een verwachting over wat er uit ‘de fabriek’ komt op een bepaald moment. Dan ben je als Scrum Master geneigd om in te grijpen en te sturen om controle te houden over wat er gebeurt en invloed uitoefenen op het eindresultaat. Maar is dat het leiderschap dat nodig is in een Agile team? Lees wat ik heb geleerd van WEL ingrijpen in een zelf organiserend team.

Onze neiging om te ‘managen’

Als Scrum Master heb je een rol in het ondersteunen van de leden in het scrum team. Ook heb je een begeleidende rol naar andere teams die afhankelijkheden hebben en naar stakeholders in de organisatie die een belang hebben bij het product waar het ontwikkelteam aan werkt. Er ontstaat wel eens druk op het leveren van een functionaliteit in een bepaald tijdsbestek, terwijl het ontwikkelteam zelf organiserend is en dus zelf kiest hoe het sprintdoel wordt behaald. Wanneer dat sprintdoel in gevaar dreigt te komen wil je ‘managen’, ingrijpen dus.

Dit zegt de Scrumgids 2017 over zelforganisatie van teams.

"Scrum Teams zijn zelf organiserend en multidisciplinair. Zelforganiserende teams kiezen zelf hoe zij het beste hun werk kunnen uitvoeren, in plaats van dat dit verteld wordt door iemand van buiten het team."

"Ontwikkelteams zijn zelf organiserend. Niemand (zelfs de Scrum Master niet) vertelt het Ontwikkelteam hoe zij de Product Backlog moeten omzetten in Incrementen van potentieel uitleverbare functionaliteit."

Dit zegt de Scrumgids 2020 over zelforganisatie van teams.

"Het Scrum Team is zelfsturend, wat betekent dat de teamleden onderling bepalen wie wat doet, wanneer en hoe."

"Scrum Teams zijn opgezet en bevoegd door de organisatie, zodat zij hun eigen werk kunnen managen."

Developers zijn niet zelfsturend, dus als Scrum Master heb je wel het stuur in handen, maar alleen op een hoger productniveau en organisatorisch niveau. Als het gaat om de activiteiten in een sprint heeft het ontwikkelteam de verantwoordelijkheid. Als zelf organiserend team bepalen zij welke taken er moeten worden opgepakt in een sprint en hoe dat wordt uitgevoerd om het sprintdoel te halen. Eerder refereerde ik aan teamverantwoordelijkheid in mijn blog over agile leiderschap; " We zijn met z’n allen Agile gebrainwasht ".

Waarom ik WEL ingreep

Vaak is niet alles in detail bekend bij de start van de ontwikkeling en kunnen nieuwe details het sprintdoel in gevaar brengen. Zoals in het voorbeeld over de afhankelijkheid van een ander team dat complexer bleek te zijn. Wanneer dit werd opgemerkt, ging ik ingrijpen en vervolgens uitzoeken hoe ik het probleem voor het team kon oplossen. Bijvoorbeeld door al te bedenken hoe ik de vertraging kon uitleggen aan een stakeholder. Of hoe ik het andere scrum team, met wie we een urgente afhankelijkheid hadden, onder druk kon zetten om iets te leveren. Welke taken we eventueel konden laten vallen in deze sprint zonder dat er serieuze problemen zouden ontstaan. En zelfs of we de reeds beloofde functionaliteit konden verkleinen om toch een werkend increment op te leveren.

De neiging om sturend op te treden was sterk, want er was druk van de omgeving om te leveren wat we hadden beloofd. Daarnaast wilde ik het ontwikkelteam helpen door mezelf het probleem toe te eigenen zodat het team gefocust verder kan gaan met andere taken uit de sprint backlog. Het leverde veel extra communicatie op binnen het team, naar andere scrum teams en naar stakeholders. Dat waren vaak geen leuke gesprekken en bracht ons negatieve energie. Bovendien was hierdoor de bijdrage aan de waardevermeerdering van het product lager dan beoogd.

Tijdens scrum retrospective bijeenkomsten bespraken we de incidenten en zochten we naar manieren om deze te voorkomen. Vaak was dan de conclusie dat het ontwikkelteam meer details wilde hebben bij de start van de ontwikkelactiviteit in een sprint. We gingen dus harder werken om alle details vooraf duidelijk te hebben. De ‘Definition of Ready’ werd steeds scherper gesteld. Dat begon wel erg te lijken op een agile machine die de scrum rituelen slaafs aan het volgen was.

Leermomentje…

Het besef dat het anders moet, kreeg ik bij het ontvangen van de feedback van het ontwikkelteam dat ik me te veel met hun activiteiten aan het bemoeien was. Deze feedback was volledig terecht en bovendien had ik ook zeker wel het vertrouwen in de kunde van alle teamleden. Waarom ging ik dan ingrijpen? Waren die problemen wel zo groot dat sturen noodzakelijk was? Later bleek dat ik dus beter niet kan ingrijpen. Achteraf gezien vond ik het vreemd van mezelf dat ik dat toch deed. Ik was dus iets aan het oplossen wat eigenlijk niet eens mijn probleem was, maar juist een verantwoordelijkheid van het ontwikkelteam. Dus…niet mijn probleem.

Lees in deel 2 van deze blog wat ik heb geleerd van NIET ingrijpen.

Foto: kantoorkat genaamd Jules

Samenwerken op afstand in een Agile team

Thu, 18 Mar 2021 10:49:51 GMT

Organisaties zijn noodgedwongen gaan werken op afstand. Dat is een proces van doen, evalueren en aanpassen om tot een situatie te komen waarin samenwerken via beeldbellen effectief wordt. Ook zijn er organisaties die dat al jarenlang doen. Zodoende heb ik de afgelopen 8 jaar samengewerkt op afstand in een Agile team. Daarnaast zat het grootste deel van de stakeholders ook op afstand in allerlei plaatsen in de wereld. Wat voor anderen een grote omslag was, is voor mij dagelijkse praktijk. Dus vroeg ik me af: Is het nu echt zo lastig om die transitie te maken naar samenwerken op afstand in een Agile team?

Verbondenheid ervaren

Werknemers in organisaties die veel samenwerken op een kantoorlocatie zullen het moeilijker vinden om de omslag te maken naar werken op afstand. Het is lastig om een dergelijke transitie door te maken in de manier van samenwerken en communiceren met je teamleden. De fysieke aanwezigheid van teamleden, wat een extra dimensie geeft aan samenwerken, maakt dat individuen zich meer verbonden voelen met elkaar, met het werk en met de organisatie. Hoe kunnen we die verbondenheid in een Agile team dan creëren en ervaren door het scherm heen? Hieronder een aantal suggesties.

Voorbereiding en proces begeleiding

Het organiseren van digitaal samenwerken vergt een goede voorbereiding en een duidelijke structuur tijdens meetings. Het moet vooraf duidelijk zijn wat het doel is van de online meeting, hoe lang deze duurt en wat de rol van ieder teamlid is. Steek hier voldoende tijd in, want een goede voorbereiding is cruciaal omdat je digitaal minder kunt improviseren. Je kan het Scrum framework gebruiken om het werk te organiseren. Dat geeft al een voorsprong omdat de Scrum-gerelateerde meetings vastliggen in sprints. Dit geeft rust en duidelijkheid waarbij alle teamleden weten wat er van hen wordt verwacht. Wat dat betreft maakt het dus niet uit of deze offline of online plaatsvinden.

Wat wel uitmaakt is hoe de online meetings verlopen. Bij uitstek iets waar de Scrum Master zich voor moet inzetten. Hoe voorkom je bijvoorbeeld dat de meeting wordt gedomineerd door de extraverte teamleden? Gebruik bijvoorbeeld de individuele chat in het meetingsysteem om sturing te geven aan het verloop van de meeting. Dit vraagt wel om multitasking tijdens de bijeenkomst. Je bent dan procesbegeleider van het gesprek. Betrek eenieder op een natuurlijke wijze en geef extra aandacht aan de stillere teamleden.

Wanneer het aantal deelnemers in een online meeting omvangrijker wordt, raad ik aan om één of meerdere facilitators in te zetten. Zo kun je het proces en het gebruik van de techniek in goede banen leiden. Als Scrum Master houd je dan makkelijker de regie. Bij een Sprint Review meeting is de groep groter vanwege de deelname van stakeholders. Scrum Master en Product Owner trekken samen op met daarnaast een facilitator ter ondersteuning. Bij Scaled Agile meetings zoals de PI Planning hebben we het over een serieus grote omvang. De Release Train Engineer organiseert en begeleidt dit evenement samen met de Scrum Masters en een logistiek team.

Staand achter het scherm

In mijn blog genaamd " We zijn met z’n allen Agile gebrainwasht " spreek ik over het tonen van leiderschap waarbij je scherp moet zijn op signalen die je waarneemt via non-verbale communicatie. Als teammanager of Scrum Master is het belangrijk om gevoel te houden met alle teamleden zodat je opmerkt of iemand bijvoorbeeld ergens mee zit. Waar dat op een kantoor makkelijker is, is het van achter een scherm veel moeilijker te lezen wat iemands houding en lichaamstaal is. De dagelijkse stand-up meetings zijn een goed instrument om signalen op te pikken, maar het wordt lastiger wanneer we alleen maar schouders en hoofd kunnen zien. Vraag je teamleden om, indien mogelijk, de camera zo te richten dat diegene ook staand zichtbaar is en dus allemaal staand de Stand-up meetings te doen. What’s in the name?

Unmute

Een zorg in digitaal samenwerken is het kunnen voeren van gesprekken in groepsverband waar meer diepgang nodig is. Je mist de dynamiek en het groepsgevoel met non-verbale communicatie zoals houding. Ook kleine geluiden als een lach of een begrijpend “uhumm” zijn niet hoorbaar, want we hebben afgesproken dat je op mute staat als je niet aan het woord bent. Hoe groter de groep, hoe sneller we genoodzaakt zijn om de mute-knop te gebruiken. In kleinere groepen kun je mogelijk wel allemaal zonder geluidsonderdrukking met meer interactie overleggen. Als middel kun je een grotere groep opdelen in kleinere groepen met gerichte opdrachten om zo te zorgen voor meer dynamiek, betere verbinding en diepgang. Het gebruik van een ‘break-out room’ kan dit in grote mate faciliteren. Zo kom je een heel eind, maar toch zal je het gemis van elkaars fysieke aanwezigheid niet helemaal kunnen ondervangen.

Virtuele koffie

Tijdens allerlei webinars en online meetups heb ik nog meer suggesties opgepikt voor sociale online activiteiten voor teams om de verbondenheid binnen het team te blijven stimuleren. Agile teams hebben al een dagelijkse meeting standaard in hun agenda staan. Dat is routine, maar het napraten bij de koffieautomaat is weggevallen. Rek de Daily Stand-up op met een extra kwartier voor gesprekken vrij van vorm. Die kunnen gaan over werk, gerelateerd aan de organisatie of juist over persoonlijke ervaringen. Mocht de stand-up meeting nog niet in de ochtend staan gepland, verplaats die dan om de dag gezamenlijk te beginnen met een virtuele koffie. Praat over koetjes, kalfjes en werk.

Zo kom je meer van elkaar te weten en dit geeft je meer gelegenheid om ook non-verbale signalen op te pikken. Als teammanager of Scrum Master kun je tijdens 1-op-1 gesprekken ingaan op de signalen die je hebt gekregen om te luisteren en te coachen. Maak regelmatig tijd vrij buiten de geplande Agile rituelen voor deze informele contactmomenten met leden van het team.

Online Vrijmibo

Als uitsmijter nog een aantal suggesties voor online teambuilding evenementen. Plan bijvoorbeeld themabijeenkomsten waar teams van elkaar kunnen leren of die helpen bij persoonlijke ontwikkeling. En de, door Nederlanders zo gekoesterde, vrijdagmiddagborrel kan prima online worden gehouden. Zorg voor elementen van FUN met bijvoorbeeld een Pubquiz, een potje online Catan of een Bingo. Dan zijn er natuurlijk ook mooie prijzen te winnen!

Ik ben erg benieuwd hoe het jullie vergaat met het digitaal Scrummen. Andere toffe suggesties hoor ik graag!

Self-organizing also means self-resolving

joost.comperen@gmail.com — Fri, 20 Nov 2020 14:46:08 GMT

Why doing nothing is often better than performing an intervention. That may go against our nature. Especially when we see that something is about to go wrong. Because in the back of your mind you think of the stakeholders who have an expectation about what will come out of "the factory" at a certain moment. You feel inclined to intervene. Read in part 1 of this blog what I have learned from intervening in a self-organizing team. It shows that intervention is not always the right action when scrumming, where the development team itself bears responsibility for what is being developed and about achieving the sprint goal. They organize themselves, so the motto is: do not intervene and let them solve problems themselves. Read what I have learned from NOT intervening.

Why I did NOT intervene

From the period I did intervene during a sprint, I learned that it takes a lot of extra time and on top of that the development team experiences it as intrusive. So, no more interventions and let the team solve their problems themselves. I have therefore decided to be more on the background regarding the development process. I was also no longer present at every Daily Scrum meeting. Why would I? It is their responsibility to make the product increment within the sprint timebox. With appropriate distance I still saw problem situations popping up (transparency) and being discussed by the team, however I did not interfere.

I was very pleased to see that the sprint goal was often achieved at the end of the sprint. The team's ability to solve problems was high, which meant that apparent problems during the sprint were neatly resolved, without making concessions to functionality or quality. The team members learned from each other and from every iteration. As an extra bonus, the development team came to me early in situations when the sprint goal would not be achieved. That was rare. Together we found a solution in which I, as a Scrum Master, had a role in communication to stakeholders.

Be the coach

If you feel the need to steer, fine, do so when the development activity has finished at the end of the sprint. Make good use of the Agile rituals that are planned every sprint to look back on the development activity. Provide feedback on the product increment and the value it provides (outcome). Coach the team in the continuous pursuit of delivering valuable product improvements.

The sprint retrospective gives you plenty of opportunity to discuss together how the product increment was produced. According to the Scrum Guide 2017 , this fits within the context of self-organization.

"By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself."

So now is the moment to discuss the situations that occurred during the sprint and how they were resolved by the team. What do we think about that? How can we prevent it or solve it more effectively next time? Again, coach the team in carefully conducting this inspection to make meaningful adjustments in future sprints. The team can grow to high-performance.

Something unexpected can always happen during a sprint which affects capacity and functionality. To prevent these situations, it is important as a Scrum Master to be keen on the outcome of the planning meeting. The Scrum Guide 2017 says:

“By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”

Encourage the team to use the results of the review and retrospective in the sprint planning meeting of the next sprint. I am probably not telling you anything new about how these scrum rituals are used, but I want to emphasize that it's the right place to steer if necessary.

Everything under control

A colleague from a different department often asked me “And… everything under control?”. I was inclined to answer honestly in the context of transparency. When I did intervene during the development process and with the idea to be in full control over the result, the answer was often "no". This was mainly because I was busy trying to solve problems for the development team.

When I stopped intervening during the development process and had let go of the idea of control, the answer was almost always "yes". How come? Team members felt ownership of the increment, felt 100% responsible for it, and they became deeply connected to the product. There was no longer that Scrum Master who regularly stepped in to ‘help’ solve a problem. Moreover, it often turned out that potential problems were not even really becoming an incident, because it was solved during the sprint. The scrum rituals are the mechanisms to steer, but above all to coach and to be successful as a team. Then the answer is always: "Yes ... all under control."

Photo: office cat named Jules

Intervening in a self-organizing team

joost.comperen@gmail.com — Wed, 11 Nov 2020 17:49:38 GMT

During the Daily Scrum meeting, halfway through the sprint, you notice a worrying trend. A task, part of the main user story, has already been delayed for three days. A dependency with another agile team is more complex than estimated. That is a problem, because the stakeholders have an expectation about what will come out of "the factory" at a given time. As a Scrum Master you feel inclined to intervene and steer to keep control over what needs to be done and influence the result. However, is that the required leadership in an Agile team? Read what I learned from intervening in a self-organizing team.

Our tendency to "manage"

As a Scrum Master you have a role in supporting the members of the scrum team. You also have a guiding role towards other teams that have dependencies and towards stakeholders in the organization who have an interest in the product that the development team is working on. Sometimes there is pressure to deliver a functionality in a certain timeframe, while the development team organizes itself and therefore chooses how the sprint goal will be achieved. When that sprint goal is being jeopardized, you want to "manage", so you intervene.

This is what the Scrum guide 2017 says about self-organization of teams:

"Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team."

"Development teams are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality"

Development teams are not self-managing, so as a Scrum Master you are in control, but only at a higher product level and organizational level. When it comes to the activities in a sprint, the development team has the responsibility. As a self-organizing team, they determine which tasks must be tackled in a sprint and how this is carried out to achieve the sprint goal. Earlier I referred to team responsibility in my blog about agile leadership; " We are all Agile brainwashed ".

Why I DO intervene

Often not all details are known at the start of development and new details can jeopardize the sprint goal. As in the example about the dependence on another team that turned out to be more complex. When this was noticed, I stepped in and figuring out how to fix the problem for the team. For example, by already thinking about how I could explain the delay to a stakeholder. Or how I could put pressure on the other scrum team, with whom we had an urgent dependence, to deliver. Which tasks we could possibly drop in this sprint without the risk serious problems would arise. And even whether we could reduce the functionality already promised in order to still deliver a working increment.

There was a strong tendency to act because there was pressure from stakeholders to deliver what we had promised. In addition, I wanted to help the development team by taking ownership of the problem so that the team can continue to focus on other tasks from the sprint backlog. It resulted in a lot of extra communication within the team, to other scrum teams and to stakeholders. These were often not pleasant conversations and brought us negative energy. And on top of that, this meant that the contribution to the increase in value of the product was lower than intended.

During scrum retrospective meetings we discussed the incidents and searched for ways to prevent them. Often the conclusion was that the development team wanted more details at the start of the development activity in a sprint. So, we worked harder to get all the details clear in advance. The "Definition of Ready" was increasingly tightened. This started to look more like an agile machine that was following the scrum rituals slavishly.

Learning point...

The moment I realized that things had to changes was when I received the feedback from the development team that I was interfering too much with their activities. This feedback was completely justified and besides that I did have full confidence in the skills of all team members. Why did I intervene? Were those problems so great that it was necessary? Later it turned out that I should have better not intervened. In retrospect, I felt it was strange that I did that anyway. I was solving something that wasn't even my problem, but a responsibility of the development team. So… not my problem.

Read in part 2 of this blog what I learned from NOT intervening.

Photo: office cat named Jules

Collaboration in a distributed Agile team

Thu, 17 Sep 2020 18:23:13 GMT

Organizations have been forced to work remotely. It is a process of doing, inspecting, and adapting to bring your team a level in which collaboration through video calls becomes effective. The Dutch Best Practice User Group (BPUG) session "To Collaborate Through the Screen", shared creative ideas to do that in the best possible way. I participated in the session with interest as I have worked in a distributed Agile team in the past 8 years. In addition, most of the stakeholders were also remotely located in various parts of the world. What was a major change for others, is daily practice for me. So, I wondered: Is it really that difficult to make that transition to remote collaboration in an Agile team?

Experiencing the connection with one another

Employees in organizations that used to work together at an office location daily will find it more difficult to make the switch to remote working. It can definitely be hard to make that shift in the way of collaboration and communication with your team members. The physical presence of your teammates, which gives an extra dimension to collaboration, makes individuals feel more connected with each other, with the work and with the organization. How can we create and experience that connection in an Agile team through our screens? Below are a few suggestions.

Preparation and process guidance

Organizing digital collaboration requires good preparation and a clear structure during meetings. It must be clear in advance what the purpose of the online meeting is, how long it will take and what the role of each team member is. Put sufficient time into this as proper preparation is crucial because you have less opportunities to improvise less in a live online meeting. You can use the Scrum framework to organize the work, as many Agile teams do. That already gives you a head start because the Scrum-related meetings are set in sprints. This provides peace of mind and clarity so that all team members know what is expected of them. In that respect, it does not matter whether these take place offline or online.

What does matter is how the online meetings progress. Clearly something the Scrum Master should commit to. For example, how do you prevent the meeting from being dominated by the extroverted team members? Perhaps by using the individual chat in the meeting system to steer the conversation. This does, however, require multitasking during the meeting. Be the process supervisor of the conversation. Make an effort to involve everyone naturally and give extra attention to the quieter team members.

When the number of participants in an online meeting increases, I recommend using one or more facilitators. This way you can manage the process and the use of the technology. As a Scrum Master it is easier to keep control. In a Sprint Review meeting, the group is larger due to the participation of stakeholders. Scrum Master and Product Owner work together with a facilitator for support. At Scaled Agile meetings like the PI Planning we are talking about a seriously large size. The Release Train Engineer organizes and guides this event together with the Scrum Masters and a logistics team.

Standing in front of the screen

In my blog called " We are all Agile brainwashed " I wrote about showing leadership where you have to be keen on signals that you perceive through non-verbal communication. As a team manager or Scrum Master, it is important to actively nurture the connection with all team members so that you notice whether someone is upset or is experiencing issues. While that is easier in the office, it is much more difficult to read a person's body language from behind a screen. The daily stand-up meetings are a good tool to pick up signals, but it has become difficult when we can only see shoulders and head. If possible, ask your team members to point the camera in such a way that they can also be seen standing up and therefore all do the Stand-up meetings while standing. What's in the name?

Let’s unmute

A concern in digital collaboration is being able to conduct conversations in groups in which more depth is needed. You miss the dynamics and team bond with non-verbal communication such as body language. Small noises such as a laugh or an understanding “uhumm” are also not audible, because we have agreed to be on mute when you are not speaking. The larger the group, the sooner we will be forced to use the mute button. In smaller groups you may be able to be more interactive in video calls without sound suppression. As a means, you can divide a larger group into smaller groups with targeted assignments in order to provide more dynamics, better connection and depth. The use of a "break-out room" can facilitate this to a great extent. This will go a long way, but the lack of each other's physical presence cannot be completely overcome.

Virtual coffee

During the BPUG session, some nice suggestions were made for social online activities for teams to continue to support teambuilding. Agile teams already have a daily meeting in their agenda by default. That is routine but chatting at the coffee machine or watercooler has disappeared. Stretch the Daily Stand-up by an extra 15 minutes for free-form conversations. These can be about work, related to the organization or about personal experiences. If the Stand-up meeting is not yet scheduled in the morning, move it to start the day together with a virtual coffee. Exchange small talk and have conversations about the virtual office.

This way you get to know more about each other, and this gives you more opportunity to pick up non-verbal signals. As a team manager or Scrum Master you can respond to the signals you have received and utilize that during 1-on-1 conversations where you are mainly listening and coaching. Regularly set aside time outside of the planned Agile rituals for these informal moments of interaction with members of the team.

Online fun

As a bonus here are a few more suggestions from the BPUG session for online team building events. For example, plan themed meetings where teams can learn from each other and that supports personal development. The Friday afternoon drinks, so cherished by the Dutch, can easily be held online. Provide elements of FUN with a Pub quiz, a game of online Catan or a Bingo. Of course, there are great prizes to win!

I am very curious how you are progressing with digital Scrumming. I would love to hear other great suggestions!

Agile sunbathing...what? Don't be silly!

joost.comperen@gmail.com — Fri, 14 Aug 2020 14:23:36 GMT

Lying in the sun by the lake in Zurich on day two of a short vacation. It is much too hot to make it an active day, so we look to cool off by the water. Sunscreen is urgently needed, because the swimming body had hardly seen any sun due to some restraint in summer activities in recent months.

Thoughts wander

As is often the case at the start of a holiday, you haven’t yet become mentally detached from work. With the burning sun on my head, my thoughts wander to Agile working and its effects on organizations, teams and individuals. Recently I have read, learned and talked a lot about the applicability of Agile. Where the Agile mindset could be introduced and replacing the traditional management and project structure.

Tanning in Sprints

Perhaps the sun was too intense too or I drank too little water, but suddenly I was making a sun-and-water-plan behind my sunglasses. The ultimate goal is to get some extra tanning today without sunburn. We planned to be at Lake Zurich for about five hours. With four hours to go, I could time-box 4 one-hour Sprints to apply sunscreen, to sunbathe, to drink or eat, and to take a dip in the water. Of course, the result of the sprint is also evaluated and adjustments are made when planning the next Sprint (hour).

The importance of inspecting

Circumstances changed every hour, such as the position of the sun, the UV intensity, and my own physical condition. During the first inspection it turned out that the application of sunscreen could be better and that I would have to cool down in the water more often. That became the goal of the next Sprint. During the Sprints, the realization came that protecting is more important than tanning. It also turned out after Sprint 3 that I had drunk too little water and had to correct that in the next Sprint.

I have learned several lessons from the Sprint evaluations:

Turn regularly when tanning
Cool off more often in the water
After a dive in the water, also carefully apply sunscreen
Drink plenty of water because you dry out quickly in the sun
Stay in the shade during the hottest hours of the day

The result of this Agile day in sun and water is that I visibly got a modest tan, but I still discovered a few small burned spots where I applied the sunscreen badly. There is still room for improvement on a next day in the sun.

A Sprint-beer

It was a fun experiment to apply Agile thinking on a sun-and-water-day. But let's be honest, it's a bit weird. My friends at the lake have continuously joked about my Agile sunbathing experiment, which is absolutely justified. On vacation you should obviously let go of work for a while. Yet it has brought me something. I paid more attention to the condition of my skin, my sunscreen application behavior, my hydration, and the circumstances. Through the evaluations of every Sprint (every hour) I was able to make adjustments throughout the day. Unlike other years, I didn’t come home with a burnt back after the first sun-drenched day. Objective achieved! So, I treated myself to a Sprint beer. Cheers!

For a more serious story, read my blog on Agile leadership: " We are all Agile brainwashed ".

Agile zonnebaden…wat? Doe niet zo raar!

Fri, 14 Aug 2020 09:46:00 GMT

Lig je ingesmeerd in de zon aan het meer in Zürich op dag twee van een korte vakantie. Het is veel te warm om er een actieve dag van te maken, dus zoeken we verkoeling op bij het water. Insmeren is hoognodig, want het zwemlijf had nog nauwelijks zon gezien vanwege de terughoudendheid in zomeractiviteiten in de afgelopen maanden.

Gedachten dwalen af

Zoals dat vaak gaat aan het begin van een vakantie, ben je geestelijk nog niet losgekomen van werk. Met de brandende zon op het hoofd, dwalen mijn gedachten af naar Agile werken en de effecten daarvan voor organisaties, teams en individuen. In de afgelopen tijd heb ik veel gelezen, geleerd en gesproken over de toepasbaarheid van Agile. Waar het Agile gedachtengoed z’n intreden zou kunnen doen en de traditionele management- en projectstructuur zou kunnen vervangen.

Bijbruinen in Sprints

Wellicht had ik al te lang in de zon gelegen of te weinig water gedronken, maar ik was plotseling een zon-en-water-plan aan het maken achter mijn zonnebril. Het uiteindelijke doel is om vandaag wat bij te bruinen zonder te verbranden. We hadden gepland om zo’n vijf uur aan het meer van Zürich te zijn. Met nog vier uur te gaan zou ik vier Sprints van één uur kunnen Timeboxen om in te smeren, te zonnen, te drinken of eten en een duik te nemen in het water. Oh, en ondertussen het boek ‘En nu Agile!’ lezen. Uiteraard wordt dan ook het resultaat van de sprint geëvalueerd en aanpassingen gedaan bij het plannen van de volgende Sprint (uur).

Het belang van inspecteren

Omstandigheden veranderde elk uur, zoals de stand van de zon, de uv intensiteit en mijn eigen fysieke toestand. Bij de eerste inspectie bleek dat het insmeren beter kan en dat ik vaker zou moeten afkoelen in het water, dat was dan ook het doel van de volgende Sprint. Gedurende de Sprints kwam het besef dat beschermen belangrijker is dan bijbruinen. Ook bleek na Sprint 3 dat ik te weinig water had gedronken en dat moest corrigeren in de volgende Sprint.

Ik heb een aantal lessen geleerd uit de Sprint evaluaties:
Regelmatig draaien bij het zonnen
Vaker afkoelen in het water
Na een duik in het water ook zorgvuldig insmeren
Veel water drinken want je droogt snel uit in de zon
Op het heetst van de dag in de schaduw blijven

Het eindresultaat van deze Agile-dag in zon en water is dat ik zichtbaar een bescheiden kleuring heb gekregen, maar dat ik toch een paar kleine verbrande plekken heb ontdekt waar ik slecht heb ingesmeerd. Er valt nog wel wat te verbeteren bij een volgende dag in de zon.

Een Sprint-biertje

Het was een leuk experiment om Agile denken toe te passen op een zon-en-water-dag. Maar laten we eerlijk zijn, het is wel een beetje raar. Mijn gezelschap heeft continue grappen gemaakt over het Agile zonnebaden, wat natuurlijk wel terecht is. Op vakantie zou je toch het werk even moeten loslaten. Toch heeft het me wel iets gebracht. Ik had meer aandacht voor de toestand van mijn huid, mijn insmeer-gedrag, mijn hydratatie en de omstandigheden. Door de evaluaties van iedere Sprint (ieder uur) heb ik gedurende de dag steeds kunnen bijsturen. In tegenstelling tot andere jaren, kwam ik nu niet na de eerste zonovergoten dag thuis met een verbrande rug. Doelstelling behaald! Dus heb ik mezelf op een Sprint-biertje getrakteerd. Proost!

Voor een wat serieuzer verhaal, lees mijn blog over Agile leiderschap: " We zijn met z'n allen Agile gebrainwasht ".

We zijn met z’n allen Agile gebrainwasht

joost.comperen@gmail.com — Fri, 31 Jul 2020 16:25:17 GMT

Honderdduizenden zijn inmiddels gecertificeerd in een Agile framework, waarvan het grootste deel in Scrum. We selecteren uit de Product Backlog, we Sprinten ons een ongeluk en we Timeboxen wat af. We kunnen de serie aan review-loops wel dromen. In de ‘scaled’ varianten wordt het nog eens uitgebreid naar meerdere niveaus. Het hangt samen van Agile rituelen waar we ons allemaal strikt aan houden. We zijn met z’n allen Agile gebrainwasht! We gaan ervan uit dat de resultaten vanzelf komen omdat we werken volgens het Agile boekje, want we zijn gecertificeerd. Ik ben van mening dat het behalen van succes met Agile werken grotendeels afhankelijk is van leiderschap. Pas met commitment en aandacht van management kunnen deze rituelen het succes van Agile werken verzilveren.

De mens in de Agile machine

Is het dan zo erg dat we strak in de leer zijn als het gaat om de Agile rituelen? De harde kant van Agile, anders gezegd de machinale kant, is nodig om structuur te bieden. Een houvast om het proces van waarde creatie te laten stromen, anders wordt het chaotisch. Het technisch ‘scrummen’ zit inmiddels in ons systeem. Als we vooral de machine aan het oliën zijn, ligt een gevaar op de loer van ‘Agile in name only’. Toch is het antwoord op de eerste vraag: ‘Nee, het is niet erg dat we ons zo strikt vasthouden aan de Agile rituelen’. Maar er is meer nodig om succes te behalen. Want, hoe zit het met het Agile denken?

Scrum biedt een aantal ingebakken handvatten aan managers om aandacht te schenken aan het functioneren van de mens in deze Agile machine, zoals:

Het Scrumteam beschermen tegen verstorende invloeden van buiten om te zorgen dat zij zich kunnen focussen om het sprintdoel te halen.
Teams helpen om zichzelf te organiseren en hun te laten voelen welke verantwoordelijkheden zij hebben bij het plannen en uitvoeren van het werk in een sprint.
Het team helpen met het doen van aanpassingen op basis van de uitkomsten van de ‘retrospective’ meetings.

Dit zijn voorbeelden die voortvloeien uit de principes van het Scrum framework, ondersteund door de rituelen. Maar dat is niet voldoende om succesvol te worden met Agile werken. We zouden ons meer druk mogen maken om de zachte kant van Agile, de menselijke kant.

Leiderschap tonen

De harde en de zachte kant van Agile werken zijn ons bekend en teams passen het ook toe. Echter, dan komen er wel een aantal vragen boven drijven. Halen teamleden het beste uit zichzelf? Wanneer gaat de productiviteit omhoog? Zijn teamleden wel tevreden in hun rol? Managers hebben niet alleen een aandeel in de zachte kant van Agile, maar er wordt ook leiderschap gevraagd. We kunnen antwoorden geven op deze vragen door leiderschap te tonen.

Heldere doelstellingen

Zorg voor een duidelijke koers voor het te ontwikkelen product zodat het team de juiste prioriteiten kan stellen in het ontwikkelproces. Uiteraard wordt een team geacht wendbaar te zijn binnen de context van een sprint. Ook mag de koers best eens aangepast worden door vernieuwde inzichten, dat is juist de kern van Agile. Zorg er dan wel voor dat bij het begin van iedere sprint, de koers helder is voor alle teamleden.

Non-verbale communicatie

Wees scherp op non-verbale communicatie in Scrum meetings en ben extra aandachtig wanneer teamleden via een video-verbinding communiceren. Wanneer je opmerkt dat iemand ergens mee zit, maar het niet uitspreekt, is het zaak om daar achter te komen. Door regelmatig wat tijd vrij te maken buiten de geplande Agile rituelen, creëer je informele contactmomenten met leden van het team. Zo is er in 1-op-1 gesprekken voldoende gelegenheid om te luisteren en ondersteuning te bieden.

Persoonlijke ontwikkeling

Verlaag regelmatig de capaciteit in een sprint om teamleden de gelegenheid te geven zichzelf te ontwikkelen. In schaalbare Agile frameworks zoals SAFe wordt al voorzien in vrijgemaakte tijd voor persoonlijke ontwikkeling. Juist in kleinere organisaties waar het Scrum framework wordt gehanteerd, wordt verwacht dat in een continue aaneenschakeling van sprints wordt gewerkt. We kunnen immers het product blijvend verbeteren. Dan is het vaak lastig om tijd vrij te maken voor trainingen of cursussen. Als leider kun je bewust de capaciteit verlagen voor een toekomstige sprint om die gelegenheid te bieden.

Teamverantwoordelijkheid

Grijp niet in, maar laat een keer iets fout gaan om het lerende vermogen aan te wakkeren. Scrum is een framework en niet een methode. Het volgen van de Scrum rituelen is betrekkelijk makkelijk, maar het effectief gebruiken en toepassen van deze rituelen is moeilijk. Er gaat dus nog wel eens wat mis, zeker in een team dat nog in de adoptiefase zit van het Agile werken. Feddo Soeterik heeft het in zijn blog over ‘Doen’. Begin met de sprint ook al weet je nog niet alle details om je sprint doel te kunnen halen. Voortschrijdende inzichten kunnen dus tot problemen leiden met capaciteit, beschikbare tijd of beloofde functionaliteit. Wanneer dat opgemerkt wordt, is het de kunst om als manager niet in te grijpen, maar het team het zelf te laten oplossen. Daar wordt iedereen beter van.

De coachende leider

Je kunt de harde technische kant wel inrichten in je organisatie, maar dan ben je nog niet per se Agile. Agile worden of zijn, gaat over hoe je Agile denkt, toepast en inzet. Agile is een gedachtengoed ondersteund met rituelen. We hebben het hier eigenlijk over het belang van leiderschap bij Agile werken, waarbij we veel aandacht hebben voor het individu in de Agile machine. Als leiders streven we ernaar om de leden in Agile teams zo te coachen dat ze in de positie komen om succesvol te zijn als individu en als onderdeel van een team. Als leiders worden we dus coaches voor zelf organiserende teams.

Mocht het Agile team zo nu en dan eens een Timeboxed scrummeeting overslaan is dat geen ramp. Sta dat toe als manager, maar zorg er wel voor dat het team met elkaar helder heeft waarom daartoe is besloten. Zij organiseren zichzelf, jij coacht hen om het beste uit zichzelf te halen. Agile leiderschap.

We are all Agile brainwashed!

Fri, 31 Jul 2020 13:14:26 GMT

Hundreds of thousands amongst us are certified in an Agile framework by now, of which the most in Scrum. We are picking from the Product Backlog, we are Sprinting like maniacs and we do a whole lot of Timeboxing. The series of review-loops we can dream by now. In the scaled frameworks all of this is being multiplied to several levels. It is a collection of Agile rituals that we all strictly adhere to. We are all Agile brainwashed! We assume that results will naturally come because we act according to the Agile book. After all, we are certified. I believe that reaching success is largely dependent on leadership. Only with commitment and attention from management, these rituals can capitalize on the success of working Agile.

The human in the Agile machine

Is it so bad that we are so strict with ourselves when it comes to the Agile rituals? The hard side of Agile, in other words the mechanical side, is necessary to provide structure. A handhold to let the value creation process flow, otherwise it will become chaotic. The technique of scrumming is now in our system. If we are mainly oiling the machine, there is a danger of "Agile in name only". Yet the answer is "No", it is not a problem that we stick to the Agile rituals so strictly. But it takes more to achieve success. Because what about Agile thinking?

Scrum offers a number of ingrained tools to managers to pay attention to human functioning in this Agile machine, such as:

Protect the scrum team from disruptive outside influences to ensure they can focus on achieving the sprint goal.
Help teams organize themselves and make them feel their responsibilities when planning and performing work in a sprint.
Help the team to make adjustments based on the results of the retrospective meetings.

These are examples that follow from the principles of the scrum framework, supported by the rituals. But that is not enough to become successful with working Agile. We should be more concerned with the soft side of Agile, the human side.

Show leadership

We all know the hard and the soft side of working Agile and teams do apply it. However, a number of questions arise. Do team members get the best out of themselves? When will productivity increase? Are team members satisfied in their role? Managers not only have a stake in the soft side of Agile, but leadership is required. We can provide answers to these questions by showing leadership.

Clear objectives

Provide a clear course for the product to be developed so that the team can set the right priorities in the development process. Obviously, the team ought to be agile in the context of a sprint. The course may also be adjusted once again by renewed insights, that is Agile as well. Make sure that at the start of every sprint, the course is clear for all team members.

Non-verbal communication

Be alert to non-verbal communication in scrum meetings and pay extra attention when team members communicate via a video connection. When you notice that someone is struggling with something, but does not mention it, it is important to find out. By regularly taking some time outside the planned Agile rituals, you create informal contact moments with members of the team. In 1-on-1 conversations, for example, there is ample opportunity to listen and provide support.

Personal development

Regularly decrease the capacity in a sprint to allow team members to develop themselves. Scaled Agile frameworks such as SAFe already provide free time for personal development regularly. Especially in smaller organizations where the scrum framework is used, it is expected to work in a continuous sequence of sprints. After all, we can improve the product ongoingly. This makes it often difficult to spend time on training or courses. As a leader, you can consciously decrease the capacity for a future sprint to provide that opportunity.

Team responsibility

Do not intervene but let something go wrong once to stimulate the learning ability. Scrum is a framework and not a method. The following of the scrum rituals is relatively easy, but the effective use and application of these rituals is difficult. So sometimes things go wrong, especially in a team that is still in the adoption phase of working agile. It is a matter of doing. Start with the sprint even if you do not have all the details to achieve your sprint goal. New insights during a sprint can lead to problems with capacity, available time or promised functionality. Once noticed, try not to intervene as a manager, but let the team solve it themselves. Everyone benefits from that.

The coaching leader

You can implement the hard-technical side in your organization, but it doesn’t necessarily mean you are Agile. Becoming or being Agile is about how you think, apply and use Agile. Agile is a mindset supported by rituals. We are actually talking about the importance of Agile leadership, where we pay a lot of attention to the individual in the Agile machine. As leaders, we strive to coach members in agile teams to position them to be successful as individuals and as part of a team. As leaders, we therefore become coaches for self-organizing teams.

If the Agile team occasionally skips a Timeboxed scrum meeting, that is not a problem. Allow that as a manager, but make sure that the team has it clear why this was decided. They organize themselves, you coach them to get the best out of themselves. Agile leadership.