So, you just got your first assignment as Scrum Master, and you are wondering how do I get started?
Let’s assume you are assigned to an already existing team. If you have to create or start a new team from the beginning then you can have a look at my post about Team Liftoff, which complements these 10 practical tips I offer in this post.
The first and most important objective during my first weeks with a team is building trust and relationships with team members and stakeholders. Coaching is a relationship based on trust, safety and confidentiality, so I start by that.
Agile Manifesto for Scrum Masters
I try to follow the Agile Manifesto as a guideline for my role as Scrum Master. With the following personal interpretation:
- Individuals and interactions over processes and tools – My priority when I arrive at an organization is to start building relationships with individuals in the team as well as with stakeholders, managers and other people involved.
- Working software over comprehensive documentation – I start with little changes as soon as possible. Little changes that don’t destabilize the system but that with little effort can bring quick improvement in any area. Then I build on top of that with my first Retrospective.
- Customer collaboration over contract negotiation – As Scrum Master you must develop a strong relationship with Product Owner and Product Managers. You must help them and they must help you. I see it as a kind of symbiosis. To certain extent in most organizations Product Owners are the representatives of the customer within the team. It is also important that you get to know stakeholders and build relationships with them as much as possible.
- Responding to change over following a plan – As a Scrum Master, Agile Coach or Coach you must forget plans and agendas. You must observe, be open minded, listen, be present and adapt to your team and organization. The plan is not yours is your team’s in any case.
Ten Practical Tips
- Meet all team members individually. Ask for their background, if they want to know something about you or your role, offer help, ask if there’s anything they’d like to change or improve, if they have any pains personally or in the team. As much as possible, treat this as a coaching session when you are just listening to understand, to get context, not trying to solve anything or provide answers or solutions, empathize and build rapport.
- Meet all stakeholders individually (line managers, product managers, CTO, …). This is not going to be easy. These people are always busy. But make the effort and insist, to at least have a first personal conversation and afterwards try to set up a regular catchup meeting with all stakeholders. You must make them clear that their help is needed, that some changes will require their help and some other changes will impact them. You need their support to deal with organizational stuff that transcends team’s boundaries.
- Make sure you understand what are the expectations from stakeholders and line managers in regards to your role. Don’t assume it, you would be surprised by what stakeholders will want from you as a coach or scrum master. So, ask and manage those expectations.
- Listen and observe, don’t hurry to changing stuff. Most probably you will see in all teams the same problems. Be patient. I you are observant and present plenty of opportunities will show up to make changes on the run, specially at a process level. Don’t force things, you don’t have to demonstrate anything.
- Work on the basics of Scrum process – don’t try to boil the Ocean. You will be overwhelmed by the amount of things that can be improved. Be patient. Start small, baby-steps. You will need at least 6 months to help a team develop. And the system is powerful !!!
- Get to know your team’s maturity level. Some people refer to it as Shu-Ha-Rei, others use the Scrum Master Maturity Model by Angel Medinilla, others Situational Leadership. Whichever method you use, make sure you approach the team in a way that is aligned with their maturity and their expectations towards you. You can adopt a teaching approach, a consultant approach or a coaching approach depending on the team. Maturity can be assessed at a process or teamwork level. If you want to assess team’s level of Scrum adoption you can use a survey, there are many out there.
- Beware of Transference and Counter-transference. This concept of Transference comes from Psychology. Typically, many teams will behave towards you as they behave towards their management, on the other hand management may be treating you as they usually treat their teams. You can also suffer from transference yourself when dealing with managers and teams.
- Get social. Use any mechanism and opportunity available to build informal relationships with team members: go out for beers or dinner, have lunch together, take coffee, …
- Understand the product. It is important that you get some understanding of the product or service your customer is selling. So, ask team members to provide you some introduction to the product from all possible perspectives: product management, sales, marketing, technology, …
- Scrum/Agile training. If the organization hasn’t provided sufficient Scrum training you will have to do that. You don’t need to do a full CSM training or to be a CST. But might need to deliver the basics so all team members are aligned and you can solve typical concerns. Afterwards coach on the run.
The first Retrospective
For most of scrum events you will probably have a well-defined script, but maybe you are wondering how to tackle your first Retrospective.
Continuous Improvement is key to an Agile culture, and Retrospectives are fundamental part of it. So, from the beginning I make it clear that Retrospectives are not optional and I do them in a way that fit the context.
For instance, what I do, instead of asking team members to come up with topics, I place stickers in the wall with all the topics I have identified in previous days, and I give them some minutes to come up with more items. If I have done my work properly very little new things will be posted on the wall, which means that I was present, observing and listening. This is a way of showing respect for team’s problems and ideas. Acting as a mirror by returning everything that you perceived.
Afterwards, I have the team vote the items and select a few, 5 at most.
Now, you can apply any mechanism you want to define actions. What I do some times is to do a Lean Coffee with the 5 most voted items, and after the discussion I facilitate definition of action items using scientific approach: Hypothesis – Experiment – Success Measures.
By doing a Lean Coffee you get the team talking about things they care about, and you will get a lot of useful information about team dynamics.
As you can see, not much Scrum stuff in this post. This is the kind of knowledge that you won’t get in most CSM trainings.
It is not only the process or framework that you need to work on, but many other aspects which have much greater impact on the performance of your team. The process is the easiest part.
This is what I do, and probably other Scrum Masters and Agile Coaches will have different approaches that work well for them.
What do you guys do? I’d like to listen to other approaches.
Thanks for reading, commenting and sharing.