For a new scrum master, the first few months can be challenging – there’s a whole team (or teams) looking to you for guidance and help, a new group of stakeholders, and the opportunity to finally do things your way.
The opportunity is there in many ways, not only in the way the team works, but also the team morale, their ways of working and the way they collaborate. All those ideas and techniques you’ve been developing can be put into practice.
1. Get to Know the Team
You’re probably going to be introduced to your team in the worst way, where you’re brought to the team area, they will be dragged away from their work to turn around and awkwardly shake hands or perhaps just sit back and wave.
A better way is one by one when they have come to a natural break in their work, or perhaps at a dedicated meeting. It is better if you have the opportunity to give them a little of your background, and for them to do the same.
You should also set up a short one-on-one meeting with each of them, where you can speak to them individually and talk about the background, and find out a little about their work, their place in the team, and the way things are working currently. This could be done in the first two weeks – but don’t force it if the team are busy preparing for a release, completing a major feature, or are stressed for some other reason.
Don’t feel the need to intimidate them with your experience. Give them an overview of your background, answer their questions, but overall the main thing is just to listen and observe them so you can get to know them on an individual level.
2. Get to Know Your Toolset
Every organisation does it slightly differently, even if they are using the same tools. I’ve used Jira with at least four different companies, and every implementation and way of using it is slightly different. Likewise with Confluence, Sharepoint, or other CMS systems. And for communication there is always email, Skype, Teams, or Zoom, and Slack.
There are many different tools out there, and I’ve given my review of some here, and here. If you’re not familiar with the ones you’re using with your new team, then ask your team to help, or perhaps your fellow scrum masters to spend some time with you walking you through some of the basics. If you’re totally new with the tools, I think you should register for a free or trial account, and then go through YouTube, Udemy, or other resources and learn them at home as well. It’s okay to learn in public, but it’s better to do some homework and develop expertise in your own time.
3. Get to Know Your Work Environment
I’m a buddy for a scrum master who is fairly new to our company, and to be honest it is a great way to help a fellow scrum master. They call or Slack me with all sorts of questions, but the basic questions that someone has when they are new – such as where to find information, how things are done, who is who in the zoo, how to negotiate the political landscape, and a myriad of other questions. It really helps.
If you don’t have a buddy system, then again you should call on other scrum masters when you have a question, or when you’re stuck with something. It is likely that there is some sort of Scrum Master community at your company, and this is a good place to start. But if you’re in doubt, there is no shame in asking the product owner or the team.
4. Get to Know Your Product
Make some time with your product owner to learn about the product. It’s important for a scrum master to have an understanding of the product, the stakeholders, who uses the product, an idea of the roadmap, and where the team is at currently.
You can also talk to the team as well to understand it from their point of view – this can be a good signal for you to the level of understanding in the team, and their perspective on what the product is. This might sound like a weird thing to say, but those who work on the product don’t always have an understanding of what problem the product solves – why it exists and what customers are actually using it for.
5. Understand the Team’s Toolset
There are popular languages and tools, and then there are those mandated by the application’s legacy, or by the organisation. Sometimes, teams will use a mix of all three. Ask your team what they use, and why. If you’re not familiar with what they are using, do a little background reading so you have a little bit of knowledge, so you can understand what GitHub does, when the team uses Python, and when they use Java, which AWS services they use and why, what their build pipeline is, etc.
6. Join the Scrum Master Community of Practice
Many organisations, especially successful ones, have thriving communities of practice, where the members facilitate meetings, share success, learnings, ideas and techniques they have learned. Joining and participating helps to show that you are going to help it be successful, and keep growing. It also helps you connect and build working relationships with your fellow scrum masters. A great way to get involved when you’re a new scrum master is to team up with a more experienced one and facilitate a meeting together – you’ll build a connection with them and learn a lot in the process.
7. Create or Review the Team’s Working Agreement
If the team don’t have one already, it’s a good idea to create a working agreement for your team, with your team. If they do have one, it is a worthwhile exercise to review it – you should really understand what is in it, and why it was there. Check that the agreement actually has the backing of everyone in the team. If you’re unsure of anything that is included, then ask the team. If you ask, and you get sighs, or the rolling of eyes, then you know that it was forced upon the team, or at least it doesn’t have their full support or understanding. Going through an exercise of creating or reviewing the working agreement is a great easy to find out what is important for the team.
8. Start Building Your Relationship with your Product Owner
There has been a lot written about the working relationship between a scrum and their product owner, and with good reason. This relationship can have a huge impact on the team and the product. It is worthwhile scheduling time with the product owner to get to know them, and for them to get to know you. Find out how they like to work, what they think of the team, the product roadmap, their relationship with stakeholders – there is so much to learn from their perspective.
In addition to this, you should schedule regular sync meetings with your PO – they don’t have to be long, but you need an opportunity to talk about the team, what is coming up for the product, and how they think things are going.
