Scrum Master: Contract your Team!
In this blog series I would like to address topics that relate to professional team coaching as well as Professional Scrum. In the course of becoming a Professional Team Coach, I noticed a lot of interesting topics for Scrum Masters who want to improve their coaching stance.
I'd like to note that models and terms I am using and discuss are not mine. They come from training and coaching sessions belonging to Vroemen from Teamchange. The connection I make to Scrum is my interpretation.
Contracting and containment
The word contract often triggers some raised eyebrows in the Scrum community. It may feel like something strict that prevents people from collaborating, referencing back to the agile manifesto for software development. The fact that this manifesto motivated us to collaborate with our customers instead of negotiating contracts, was a sign that collaboration and contracting were out of balance. However, there is a new need for a contract: a (psychological) contract between the Scrum Master and the Scrum Team (including the Development Team).
By this I don't mean a big contract upfront with the signature of the whole Scrum Team. There are more ways to contract a team.
A couple of examples:
- You have a certain objective in mind for this Retrospective. At the beginning of the session you're transparant about this and check if the Scrum Team is ready and willing to achieve this objective together;
- You're an hour into a refinement session and you read the room. There is tension in the room, discussions are hardened. You suggest a short break and you do a check-in before continuing;
- You start with a new assignment as a Scrum Master. You're assigned to the marketing team. The marketing team never asked for Scrum, let alone a Scrum Master. So this is the first thing you bring up when you meet the team. Together you set up some rules of engagement, so you can be a servant leader to the team. Or maybe you don't take on the assignment at all?
- You meet with a new team and you create a set of team rules that everybody can agree on.
I'm sure now that I've given some examples, you can think of a couple examples of you're own?
So this contracting doesn't happen just once. It happens over-and-over-again.
Creating a contract like this will create containment and safety for the team to freely express themselves because of the containment of this contract.
Contract the team, not (just) the manager
You will often encounter managers or customers you work with to take on some improvements regarding a specific Scrum Team. Things have not been going that smooth and you're the perfect match to solve this teams' problems. Before you agree to take on the assignment, take a moment to talk to the team first to assess their view on the situation. If this team does not want to be coached, chances are you will be having a very hard time doing so. Find out what the needs of this team are. What do they think/feel? What's the relationship between them and management? All of these things affect the ability of you being able to help this team grow or not.
I was once the Scrum Master of two teams that started out with Scrum. I was hired by the CEO to help these teams become better Scrum Teams. Or actually, the CEO thought I would help the team perform better on their targets. Management started putting more and more pressure on the teams and they wanted me to do the same. This led to the situation that I had to end my contract with this company. The CEO did not want Scrum, he wanted to get results as fast as possible by pressuring the teams. No sustainable pace what so ever. My contract with the CEO was in conflict with the contract I had (not) made with the Scrum Teams.
Contact and contract
Contact and contract are not that different. Making contact with the people in your team is like making a psychological contract. Sometimes this is done by a subtle check-in, sometimes more clearly by asking for permission to proceed with the agenda for a session. Or having a conversion on the expectations of your role as a Scrum Master in a team. If you treat a contract in this way, you and your Scrum Team will most definitely benefit.