Blogopmaak
Self-organizing also means self-resolving
joost.comperen • Nov 20, 2020
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
Running as a metaphor for learning to take time for personal development by setting relevant goals.
Hardlopen als metafoor om te leren tijd te nemen voor persoonlijke ontwikkeling met het stellen relevante doelen.
Tegen onze natuur in grijpen we niet in bij problemen tijdens een sprint. Het zelf organiserende team zorgt dat de scrum master alles onder controle heeft.
Wij neigen naar interventie bij problemen tijdens een sprint. Waarom als scrum master wel ingrijpen niet de juiste actie is bij een zelf organiserend team.
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?
We tend to intervene in the event of problems during a sprint. Why intervening as a scrum master is not the right action towards a self-organizing team.
Being forced to work remotely is a process of doing, inspecting, and adapting. Some suggestions for collaboration in a distributed Agile team.
An Agile vacation story on sunbathing in Sprints, which brings value but is a bit silly at the same time.
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.
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.
