Discovery and recommendation phase in your first few weeks as a Scrum Master

So you’re finally ready to join your new team as a Scrum Master! That’s a big step, and it can be pretty nerve-wracking. Sometimes, the organisation’s Agile coach or another Scrum Master will help you get started. Other times, though, you might need someone to guide you through your first few weeks on the team. So, how are you supposed to figure out what to do and how to spend your time? Here are some guidelines I typically follow when joining a new team as a Scrum Master. I called it the “discovery and recommendation phase”. Enjoy!

Know your goal

Naturally, the more time you spend within the organisation and alongside your team, the better sense you’ll gain of how things operate. While it’s certainly possible to wait passively for this understanding to come to you, as many Scrum Masters emphasise proactivity on their resumes, taking the initiative is wise. Later in this article, I’ll give you the “tools” at your disposal for gaining a deeper understanding, but for now, the main point is that you should strive to gather as much information as possible during your first four to five weeks. Why, you might ask? Well, at some point, every Scrum Master who joins a team will consider proposing changes. The information you gather during discovery and recommendation will be the foundation of the changes you’ll present to your team. The key, however, is to suggest the right changes at the right time and in the right manner.

Find the low-hanging fruit

Let me break it down. What are the right changes? Surely, the first changes you propose will not be the last ones (at least, that is my hope!), but choosing the right ones will give you a significant advantage in the future and may determine how easy it will be to propose the next ones. Seek out areas that will impact the team most but require a relatively small effort. In other words, you want to maximise the value (hmm… does this not sound familiar?). The best are the low-hanging fruit, but sometimes you may choose to tackle a more challenging issue. Just remember, do not begin your journey with nearly impossible-to-solve problems. For instance, if you observe that your team has a Technical Product Owner and a Product Owner above them, with a Product Manager above the latter, resulting in a significant gap in Product Owner’s role responsibilities, do not make this your first proposal for change. It requires too many (and tough) conversations to convince others to remake the organisational hierarchy, and if you lack credibility (which you do, being new), you may waste your time and lose trust. A good example is setting up Sprint Plannings or Product Backlog Refinements if they have not yet been established.

Not too early, not too late

Now, when is the right time to propose new things? Of course, it varies from team to team, depending on the complexity of the product and other factors, but I believe it is typically around four to six weeks after joining the team. Why this time? Because after this period (if you use it wisely), you will have gained enough understanding of why things happen the way they do, become acquainted with people, and have some basic knowledge of the product. If you begin implementing changes too soon, you are more likely to face resistance from the team members. Conversely, if you wait too long to propose changes, people may think you are not doing your job.

Engage your team

And lastly, how can we propose the right changes in the right way? Well, you’ve been gathering the observations for four weeks already. Now it’s time to collect those notes and organise them into meaningful categories based on our observations. Afterwards, set up a meeting with your team and present your findings to them. You can start by telling them your vision for this team, i.e. a self-managing team that delivers a high-quality product that meets the user’s needs. Then you can move on to sharing what you think are the team’s strengths and what areas are still to be worked on. Invite them to the discussion, to create and order your team’s Backlog of changes with you. In many cases, your team will engage not only in developing the plan for future improvements but also they will contribute to it with their additional insights and ideas. However, be prepared that your team will only want to listen to your findings. Don’t be discouraged! Even presenting your observations and recommendations to your team will let them know what they may expect from you.

Meet, ask and note!

I spoke of the notes I take in the discovery phase. Yes, I take notes all the time, and I write down most of what I hear. Some things will repeat themselves – good! You may have uncovered an important challenge that your team faces. Other information may be significant or may require attention at a later time. Be sure to attend all team meetings, as this allows you to observe the team dynamics, who speaks the most, and who rarely speaks. This information will be useful when facilitating future team meetings. I also take notes during 1:1 meetings, which are a significant part of my discovery phase. During the first weeks, I try to talk to everyone in the team, including managers, the Product Owner, designers, and anyone who affects the team. These meetings serve two purposes: they allow me to form relationships with the people, and they give me the opportunity to ask many questions.

Key areas to observe

Now, it’s time to talk about what you should look into during your first few weeks on the job. Of course, you’ll start to pick up on the team’s dynamics and biggest challenges during meetings and one-on-one chats. But there are important things that team members may not share unless you ask. One of these is knowledge about the product they’re building (which may not be as obvious as it seems), the users they’re making it for, and the vision and goals for the product. However, keep in mind that the answers may vary depending on who you ask – developers and product owners may have different perspectives.

There are other areas worth investigating as well, such as:

• Scrum eve: Do they occur as planned, and does everyone understand their purpose?
• Cross-functionality: Does everyone have the same level of understanding about the product, or is one person holding most of the knowledge?
• Sprint metrics: Does the team deliver what they commit to, and how much do they commit to?
• Product backlog management: Is the backlog updated and prioritised? Does the team refine backlog items?

These are good places to start, but once you begin asking questions, you’ll uncover even more areas to explore. People are usually happy to share their observations and ideas, so don’t hesitate to use them (and make sure to give credit where it’s due!). Remember that the Scrum Master’s job isn’t to solve all the team’s problems alone but to encourage the team to work together to find solutions.