After working with 100+ teams this is a short framework for a Scrum Master/Agile Coach starting in a new team to avoid disaster and get some sh*t done ๐๐ผ (part 2)
Part 2 of 2 - on sharing insights, finding leverage and showing progress.
This article continues a topic I started more than a week ago. Check the previous points on initiation and observation ๐๐ผ
So.. Youโve introduced yourself to the team, you made some observations and have a couple of recommendations to share. Whatโs next?
Donโt share your recommendations ๐ช
Share your observations instead. Whatโs the difference?ย
Observationย - in this context, it means a registered fact, e.g. the meeting lasted X minutes, quotes of what people said, numbers without interpretation, metrics etc.
Recommendationย - advice on what to do after observing something, e.g., focus on improving your work flow; you talk too little about value and too much about velocity.
I share my findings in a separate meeting or a retrospective (if the team agrees and has a habit of conducting one) as a document or presentation. I always let them know who will have access to the โreportโ, andย everyone I share it with can see the same contentย (provided there is a safe space to do so). 1
๐กIf you plan to share with different stakeholders, it might be best to have everyone present in the same room -ย or not. Do the former if there are good relations and a safe environment and the latter when the team might need to digest the information first and respond before sharing it outside.
๐๐ผ Focus on facts, not interpretations. People will know some of the stuff you mention, and they have probably tried to solve it already. Share your observations transparently, donโt sugarcoat, yet remain respectful.
Afterwards, askย what they notice and want to do going further.ย This leaves space for taking ownership. Donโt ask if the data is accurate or what they think about it - this can make them more defensive and put the focus on finding the culprit instead of putting in the work.
When people ask for your recommendations, go for it.
Focus on what brings most leverage ๐ง
Considering the team wants to improve and sees you as someone who can help, you can not build an initial improvement plan together.ย
๐ย Contractingย is an excellent way to start working with a team. A contract is a list of agreements you make together like, for instance:
When we see things not working, we speak up. We will try to solve it. If we cannot solve it, we accept it and donโt complain.
We always take 5-10 min to share kudos on our retrospectives.
When we agree on something, we work as a team to make it work.
When discussing the following steps and improvements, focus on what the team is eager to engage in and fix together with you. Donโt focus on more than 1-2 impediments at once.
๐๐ผย Start by focusing on fixing a low-hanging fruitย that makes the team's work easier, better or happier to gain trust and show your intentions. No, this is not a manipulation. This shows that change is possible, and you are there to help them.
๐กย Going straight for the jugular of a huge problem is a bad ideaย and might leave you drained, absent, and the team disappointed. Although the ego says 'go big or die trying' - you will get caught up in a long fight and politics instead of making real change.
You donโt know the teamโs environment and the mechanics of work just yet. Sustainable change is more visible, requires less effort and grows stronger with time. You can read more in Esther Derbyโs โ7 Rules for Positive Productive Changeโ.
Show progress and do check-ins ๐ก๏ธ
With your observations, you should have data set to mark as point A and measure against it while improving. Being entangled in work, the team usually does not see the change as an outsider can.
๐๐ผย Show regularly the progressย made with factual data, change in behaviour and solved improvements - on team and organisation levels. You can use dashboards, notes, and feedback from stakeholders or other teams.ย
Once every 1-2 months should be sufficient, yet adjust to what your gut tells you.
๐๐ผย Do a health checkย with the team every retrospective or now and then, e.g. usingย Spotify Squad Healthcheckย model.
โ
Finally, some of the above points and those mentioned in aย previous articleย can be timed differently. Trust your gut and try to sense the team. These are the best indicators. Sometimes itโs good to take a risk and see what happens.
What are your โmust havesโ when starting work with a team?
๐Share this post if you think it can help a Scrum Master enter a team and do some quality work.
Safety is paramount. There is courage and significant change possible when confronted with the facts because, when named, it cannot be unseen, and a reaction is required.
At the same time, in an unsafe culture, there is a risk of retaliation, and some observations should be kept to the team so they can undertake the work in a known and trustworthy space.
In the end, sharing challenging observations almost always leads to discomfort, which I do not view as bad.