Blogopmaak
Intervening in a self-organizing team
joost.comperen • Nov 11, 2020
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.
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 should not intervene when problems arise during a sprint. It is the self-organizing team that ensures the scrum master has everything under control.
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.
