How to get started with a remote team, as a new Scrum Master with 1 year experience.
Step-by-Step guide, mindset and agenda
👋 Hello,
Welcome to the ⭐️ free monthly edition ⭐️ of my weekly newsletter, the “Winning Strategy.”
I’m Vibhor, and every week, I answer one question (that comes from you) about agile, product, roles, processes, frameworks, career growth, working with humans and anything else that’s stressing you at your office.
Send me your questions here, and in return, I’ll offer actionable, down-to-earth, and straightforward advice.
If you are new to the newsletter, here is what you may have missed::
Note: If you enjoy reading this post, would you mind showing your support by clicking the little gray heart below the title above? It would really mean a lot and help spread the word about this growing newsletter. 😍
On to this week’s question!
Q: I have only 1yr of experience as a Scrum master with 2yrs of development background. Currently the Managers and Scrum Master etc are located in the USA and the Dev, QA, BA are in India. Can you suggest what steps should I take ?
Thanks for the question.
I understand that being a Scrum Master can be tough when your team is spread out all over the place and working in different time zones. It's a pretty common problem for companies with remote teams. Having said that, there are some things you can do to make things easier. I have documented some steps that I used to follow in similar situations.
But before we jump right in, I want you to get into the right mindset to help your new team.
Imagine that you’re planning to run a marathon. Think of your role just like when you start training for that marathon. When you first start training, you don't immediately try to run the full 26.2 miles on your first day, right? You start small. You might aim to run a mile without stopping, then gradually increase your distance over time.
Similarly, as a Scrum Master, your mindset should be focused on setting achievable, short-term goals first instead of trying to change everything all at once.
Your role isn't to create a massive upheaval, but rather to slowly and steadily improve processes and support your team.
For example, a short-term goal could be understanding the team's current workflow in the first week. You could plan to sit with different team members to observe their working styles, participate in team meetings, and examine the tools and platforms the team uses. This will give you a sense of the team's current processes and dynamics.
Here’s an article I found useful from HBR
A potential milestone could be something like,
"By the end of my first week, I want to understand the current work process of each team member and identify at least one potential area for improvement in the existing workflow."
The idea here is to "learn the ropes" before you start making changes. Just like a marathon runner gradually increasing their distance, you want to steadily grow into your role, understanding each aspect thoroughly before moving to the next. This way, when you do start implementing changes, they'll be based on a solid understanding of the team and their needs, making your efforts more effective in the long run.
So, don't stress about making big waves straight away. Take a breather, observe, learn, and then slowly bring about change.
Below are the exact steps I used to follow to ramp up a new team (co-located or remote).
Steps to get started with a new team (remote or not)
1. Get the right “first” introduction: I can not emphasize this enough. Getting the right introduction to the team is the most important step. It sets the foundation of your Scrum Master journey with the new team. There are only 2 conditions to make this right.
The person introducing you to the team must be important, one that holds some kind of authority. This could be the Manager of the team (not the manager you report to as part of the Agile Center of Excellence), the Product Manager of the team, or the VP involved.
This must be done as your first interaction with the team. Why does it work? Well, let’s just say that there is a lot of power in authority.
2. Set Expectations with the Hiring Manager: Knowing what's expected of you will guide your actions and goals. This should be your next step after the initial introduction. Have a chat with them, and ask what they expect from you as a Scrum Master. This will give you a clear direction and make sure you're both on the same page.
3. Find out Who’s Who: Identifying the Product Owner, Dev team, and Key stakeholders early on will give you a clear understanding of your team's structure and who you'll be working with. Get to know them, their roles, and their personalities, because you're all in this 'party' together.
4. Identify a champion: This is someone who has the information about the team, the product and their current process. Usually, the Product Owner this person is someone who can get you insider information. It’s important that you are on good terms with the Product Owner.
5. Understand the Product: With the Product Owner’s help, get to know the product. Knowledge about the product or service your team is working on will help you understand your team's goals, end-user needs, and potential challenges your team is facing while developing a valuable product.
6. Understand the current Process: Ask the Product Owner to briefly explain the current process. What steps are currently being followed? Think, is there a better way 🤔? Understand the process the team is using to develop and deliver the product. This will give you a clear picture of where you can bring in Scrum principles for improvement.
7. Check the Tools Available for Communication and Collaboration: Now that you understand the team and the product, knowing what tools are available for effective communication and collaboration is the next step. This could be tools like MS Teams for communication and Jira for product based collaboration.
8. Find out the core hours: These are the hours when all the remote team members are available for collaboration. identify the timeframe during which everyone is available for meaningful interaction. This will help in planning your Scrum events.
9. First independent meeting with the team: Now that you have all the necessary background information and tools, plan and conduct your first “independent” (no external support available) meeting with the team. You will use this meeting to:
clearly explain your role to the team,
set expectations (team availability etc.), and most importantly,
let them know you are there to support them with the Scrum process
10. Set 30-minute 1:1 Meetings with all team members: Personal interaction with each team member will help you understand their individual roles, strengths, and areas of improvement. It will also help in building a close work relationship with them.
11. Conduct a team retrospective: Conducting a retrospective after you've built a basic rapport with the team can help you glean all the team’s pain points. This is not just to gain insights but also to show that you’re there to support them.
12. Send the Invite for Scrum Events: Based on all the information and insights you have gathered, you can now schedule and invite team members to Scrum events like daily stand-ups, sprint planning, sprint reviews, and retrospectives.
Based on these steps, below was my schedule for the first month.
Suggested schedule for the first month
Week 1:
Day 1-3: Set Expectations with the Hiring Manager
Day 4-5: Find out Who’s Who
Week 2:
Day 1-2: Understand the Product
Day 3-5: Understand the Current Process
Week 3:
Day 1-3: Check the Tools Available for Communication and Collaboration
Day 4-5: Check the Core Hours for Collaboration
Week 4:
Day 1: First Meeting with the Team
Day 2-3: Set 30-minute 1:1 Meetings with All Team Members
Day 4: Conduct a team retrospective
Day 5: Send the Invite for Scrum Events
This information is more than enough to get you going. For those looking for more, below is an extremely detailed breakdown of my schedule.
Week 1: Understand the Current State
Day 1-3: Set Expectations with the Hiring Manager
Before you can begin a new journey as a Scrum Master, it's important that you know where your compass is pointing. That's where your conversation with your hiring manager comes in. The hiring manager can provide valuable insights into the broader organizational goals, expectations from the Scrum team, and how your role fits into this picture.
Here's how you could approach this:
Day 1: Preparing for the Meeting
Before you sit down with the hiring manager, you should gather your thoughts about what you need from this conversation. Remember, this meeting is not only about listening but also about asking the right questions.
Jot down your expectations and questions. Think about:
What you understand your role to be
What are the expectations regarding team performance and delivery
What challenges you anticipate
How open the organization is to changes in the Scrum process
Any specific goals for the team or the product that you should be aware of
This will help you clarify your thoughts and get you ready for an open and fruitful conversation.
Day 2: The Meeting with the Hiring Manager
Now that you have your points ready, it's time for the meeting. Approach this conversation with an open mind, ready to listen and understand. Here's how you could structure your conversation:
Begin by sharing your understanding of the role and expectations. Invite the hiring manager to confirm or correct your understanding.
Discuss the specific goals for the Scrum team and how these tie into larger organizational objectives.
Ask about any past issues or challenges the team has faced. This might provide you with valuable context about the team dynamics and potential areas of improvement.
Lastly, talk about how flexible the processes are. As a Scrum Master, you might identify areas for process improvement. Knowing how open the team and the organization are to changes is important.
Make sure to take detailed notes during this meeting. This will help you reflect on the conversation later.
Day 3: Reflect on the Meeting
Post-meeting, take some time to reflect on your discussion.
Did your understanding of the role and expectations align with what the hiring manager said?
What are the most important goals for your team?
Are there any specific challenges that you need to be aware of?
Is there flexibility to change the process if needed?
Document these reflections. These will form the foundation of your strategy as you move forward.
Day 4-5: Find out Who’s Who
The last 2 days of the week revolve around getting a rough understanding of the team structure, roles, and responsibilities and getting a sense of the team dynamics. Setup a meeting with the Product Owner (your champion) and chat about the following:
Team Member’s Roles: Map out all the team members and identify their specific roles. Your team will likely consist of the Product Owner, Developers, QA, and BA, among others. If it's not already clear, find out who holds which position and document this information. Also, while you are at it, think about if these responsibilities align with what you expect from the Scrum Guide or if there are deviations.
Understand their Responsibilities and Pick a Champion: After you've identified everyone's roles, dive deeper into what each role entails. What are the responsibilities of each team member? What is their involvement in the current project? Pick a champion based on your findings.
Understand Interactions and Dependencies: Ask the Product Owner about how the team members interact and how their roles are interdependent. For example, developers will depend on BA for requirement clarifications and on QA for finding bugs.
Identify Key Stakeholders: Lastly, ask the Product Owner to give you the names of the key stakeholders. These are people who, while not directly part of the team, have a vested interest in the project. This could include managers, executives, clients, end-users etc.
Below is an example Excel sheet I used to document this information:
Note that the “Personality column is empty. You will fill this out after individual 1:1 meetings.
Week 2: Deep Dive into the Product and Processes
Day 1-2: Understand the Product
The goal of these two days is to understand (as much as you can) the product that your team is working on. This understanding is crucial because it informs all your decisions as a Scrum Master. Here's how I would approach it:
Meet with the Product Owner: The PO is typically the one who has the most comprehensive understanding of the product. Set up a meeting with them again to discuss the product in detail. You can cover the product’s
intended functionality,
its users,
its market positioning, and
any important historical context.
Ask about the overall vision for the product and the strategic goals associated with it.
Product Overview: Ask the PO to help you get access to all product documentation and resources. This could include
product requirements documents,
user stories,
design documents,
product manuals, and
even existing user feedback.
If there's a product demo or a sandbox environment where you can use the product, be sure to use that.
Understand the Users: Every product exists to serve its users. Understand who these users are and what their needs are. Review any user personas that have been developed. If there aren't any, or if they're outdated, consider working with the product owner to develop or revise them. Also, do not forget to ask the PO to walk you through the user journey.
Product's technical aspects: While you don't need to know how to code, a basic understanding of the product's technical aspects is quite helpful. You might want to meet with the technical lead or a senior developer to get an overview of the product architecture, the technologies used, any technical debt, and any important technical constraints or opportunities.
Product Challenges: As a Scrum Master, you'll be looking for ways to improve how your team works. Understanding the challenges faced by the product, such as tough competition, technical complexity, regulatory compliance, etc., can give you insights into what areas might need improvement. Again PO might be able to help you with this.
Understand the Product Backlog: The product backlog is the list of all the features, functions, requirements, enhancements, and bug fixes identified for the product but not yet worked on. Ask the PO to walk you through the current state of the product backlog, including how items are prioritized and how frequently it's groomed.
Don’t forget to note down any questions or issues that you might need to address later and any potential improvements that you think could be made in how the team works on the product.
Below is an example of the information you will gather during these 2 days.
Day 3-5: Understand the Process
Once you've gained a deep understanding of the product, it's time to understand the process your team is currently using to deliver it. Here’s a suggested approach:
Understand the current workflow: Start with mapping out the current workflow. How does a task go from being an idea to being part of the product? You can gather this information from process documents, if they exist, or by interviewing team members and stakeholders.
Existing process: Find out what methodologies/frameworks are currently being used. Is the team using Scrum, Kanban, or a mix (Scrumban)? How strictly are they adhering to the process, and what custom practices have they introduced?
Sprint Planning and Execution: Understand
how the team is planning and executing their sprints,
how are sprint goals set, and
how are tasks distributed among team members,
how long are the sprints, and
what is the team's definition of "done."
Look at past sprints to understand how effectively they have been completed.
Meetings and ceremonies: Find out what meetings and ceremonies the team has in place. This includes
daily stand-ups,
sprint planning meetings,
sprint reviews, and
retrospectives.
Are these meetings effective? Are team members actively participating, and is there a tangible outcome from each meeting?
Communication: Understand how the team communicates, both formally and informally.
How are updates shared?
How are problems communicated and resolved?
How do team members collaborate?
Pain Points and Improvements: While carrying out these steps, constantly be on the lookout for your team’s pain points in the current process and potential areas of improvement. These could be:
bottlenecks,
inefficiencies, or
sources of friction among team members.
Keep in mind that Scrum is not the answer to all team troubles.
Below is an example documentation of this step.
Adapt this step to your own context. The goal is to get a clear picture of the current process, identify where the pain points are, and start thinking about potential improvements.
Week 3: Understand the Tools and Timing
Day 1-3: Communication and Collaboration Tools
Since your team is mostly distributed, communication and collaboration tools play a more crucial role. Here are the suggested activities for these 3 days:
Identify the Tools: First, create a list of all the communication and collaboration tools currently in use. This could include tools for:
instant messaging (like Slack, Microsoft Teams),
video conferencing (like Zoom, Google Meet),
project management (like Jira, and Trello),
document sharing (like Google Drive, SharePoint), and
code sharing (like GitHub, Bitbucket).
Understand how they are used: For each tool, understand how it's used by the team. Are there guidelines on when to use which tool? For example, Slack might be used for quick questions, while email might be used for more official or formal communications. There might also be specific channels or threads set up on these platforms for different purposes. Make a note of these practices.
Assess effectiveness: Evaluate whether the current use of these tools is effective.
Are communications clear and timely?
Is the information easy to find and share?
Do the tools integrate well with each other?
Look for any gaps or challenges, like missing notifications or redundant tools.
Check for consistency: Check whether all team members are using the tools consistently. Sometimes, team members might have different preferences or habits, leading to fragmented communication. Everyone should be on the same platform to avoid miscommunication or missed information.
Prepare a list of Improvements: If you identify any areas for improvement, list them out. This could include introducing a new tool, eliminating an unused or ineffective one, changing how a tool is used, or providing additional training. However, remember that changes should be proposed and implemented gradually to avoid disrupting the team's workflow too much.
Below is an example documentation of this step.
Day 4-5: Check the Core Hours for Collaboration
As you're working with a globally distributed team with time differences, finding overlap in working hours where everyone is available is crucial. This will make sure that you have a window for collaborative work, meetings, or Scrum events. Here are the suggested activities:
Gather Information: Start by gathering information on the work timings of all team members, including the product owner, developers, QA, BA, and any other stakeholders. Collect data on their usual start and end times, break times, and any regular commitments they have during their workday that cannot be moved.
Time Zone Conversion: Convert all these times to a common time zone for easier comparison.
Find Overlap: Identify the overlap in working hours where everyone is available. There may be more than one such period during the day, but usually, there is a certain 1-2 hour window where all team members are working. If there's no complete overlap, find a time slot that works for most team members and consider alternatives like rotating meeting times or recording meetings for the ones who can't attend.
Set Core Hours: Based on this overlap, set 'core hours' during which everyone agrees to be available for meetings and collaborative work. This should be a time when everyone is comfortable working and not at the very start or end of their workday.
Communicate: Once the core hours are decided, clearly communicate this to the whole team. Make sure everyone understands the importance of these core hours and agrees to prioritize being available during this time.
Consider Flexibility: Understand that sometimes there might be personal commitments and the need for flexibility. Balance the need for collaboration with respect for personal time.
Review Periodically: This is not a one-time activity. People's schedules may change, new team members may join, or daylight saving changes may affect working hours. So, it's essential to review the core hours periodically to ensure they still work for everyone.
By the end of day 5 of week 3, you should have a clear understanding of when your team can come together for collaborative work.
Here’s an example worksheet:
Week 4: Connect with the Team and Plan
Day 1: First Meeting with the Team
After spending time understanding the product, processes, tools, and team dynamics, it's time to have your first formal meeting with the team. This is your chance to
formally introduce yourself,
share what you've learned and
set the stage for how you plan to work together.
Prepare for the Meeting: Prior to the meeting, gather all the insights you've collected over the past weeks. You should have a clear understanding of the team's dynamics, the product, the processes, and the tools in use. Also, consider any improvements or changes you think are necessary based on your observations.
Set the Agenda: Set a clear agenda for the meeting. This could include
sharing your observations,
discussing any proposed changes,
explaining the Scrum framework if needed, and
setting expectations for the future
Keep in mind that this meeting is not just about you talking. It is an opportunity for team members to ask questions, share their concerns, and discuss their expectations.
Share Your Observations: Share your observations about the team's current working methods, the product, and the process. Be diplomatic and constructive in your feedback. The goal is not to criticize but to identify areas for improvement.
Discuss the Scrum Framework: If needed, provide an overview or a refresher of the Scrum framework, its events, roles, and artifacts. It's important that everyone on the team has a good understanding of Scrum. It is a framework that requires active participation from all members.
Propose Improvements: If you've identified areas for improvement, propose them to the team. Discuss these suggestions and encourage feedback. Remember, any changes should be agreed upon by the team.
Set Expectations: Clearly outline what the team can expect from you as a Scrum Master. This might include things like availability, how you'll handle conflict, and how you plan to facilitate the Scrum events.
Summarize and Next Steps: End the meeting by summarizing the key points and next steps. This could include any agreed changes, upcoming Scrum events etc.
By the end of this meeting, you want the team to have a good understanding of
who you are,
how you plan to work, and
what changes (if any) will be happening.
It's a crucial step in establishing a strong working relationship with your team.
Day 2-3: Set 30-minute 1:1 meetings with all team members
The next step is to meet individually with each team member. These 1:1 meetings will help you to understand each individual's roles, responsibilities, challenges, and aspirations better. Here's a step-by-step guide on how to conduct these meetings:
Schedule the meetings: Send out meeting invites to each team member for a 30-minute 1:1 meeting. I like to invite them over for coffee. Spread these meetings out over two days, giving yourself time to process the information after each meeting. Also, consider the core hours you identified to find a time that works best for both of you.
Prepare an agenda: For each meeting, prepare an agenda. The agenda could include topics like
the team member's role,
their perception of the team and the project,
any challenges they face,
their career goals, and
their expectations of you as a Scrum Master.
Start with a casual conversation: Begin the meeting with a casual conversation to make the team member comfortable. Do some small talk. Make it about non-work related things like hobbies, interests, or any common ground you may have discovered.
Discuss the agenda: Next, dive into the pre-defined agenda. Start with open-ended questions like "Can you tell me more about your role and responsibilities in the team?" or "What are some of the challenges you've been facing?" This gives them a chance to talk openly and provide you with valuable insights.
Ask for feedback: Ask for their feedback on the team's processes, the Scrum framework implementation, and their thoughts on potential improvements. Also, ask them about their expectations from you as a Scrum Master.
Discuss Career Goals: If appropriate and time allows, discuss their career goals. As a Scrum Master, you play a part in helping your team members grow professionally. Understanding their aspirations can help you support them better.
Summarize and Thank Them: At the end of the meeting, summarize the key points discussed, and thank them for their time and input. If there are action points or follow-ups from the discussion, note them down and ensure they are addressed.
These 1:1s will give you a deeper understanding of each team member. This information will be invaluable as you work to guide and support your team as their Scrum Master.
Day 4: Conduct a team retrospective
After meeting individually with all team members, it's time to conduct a team retrospective. Here's how you can conduct your first retrospective as a new Scrum Master:
Schedule the Retrospective: Schedule a retrospective at a time when everyone can attend. Ideally, it should be an hour or two long, but this may vary based on the team's size and the scope of topics to be discussed.
Set the Agenda: As with all meetings, set a clear agenda. Feel free to use a format that best fits your team. Use “What went well?", "What didn't go well?" and "What can we improve?” to avoid going overcomplicated in your first retro.
Prepare a Safe Environment: Retrospectives require honesty and openness, which can only occur in a psychologically safe environment. Start the retro by reminding everyone that the purpose is to improve, not to blame.
Facilitate the Discussion: Start with the first agenda point, typically "What went well?". Allow everyone to share their thoughts. As a Scrum Master, your role is to facilitate the discussion, ensuring everyone has an opportunity to speak and keeping the conversation on track.
Document Everything: Document all the feedback. This can be done using Confluence or even MS Teams. Everyone should be able to see the input.
Identify Actionable Improvements: After discussing what went well and what didn't, move on to "What can we improve?". The goal here is to come up with actionable steps to address the issues identified. Ensure that these improvements are specific, measurable, and assigned to someone for accountability.
Follow Up on Action Items: At the end of the retrospective, summarize the key points and confirm the action items. Make sure these actions are followed up in the next sprint and revisited in the next retrospective.
Close on a Positive Note: Finally, close the retrospective on a positive note. Appreciate the team's honesty and participation, and express your commitment to supporting them in making the identified improvements.
Day 5: Send the Invite for Scrum Events
After the initial meetings and retrospectives, you will have gathered much insight into the team's dynamics, workflows, and areas of improvement. Now, it's time to plan and schedule your Scrum events. Below is a suggestive guide:
Identify the Events: Identify which Scrum events are applicable to your team and project. Typically, these would include the daily stand-up, sprint planning, sprint review, and sprint retrospective. You may also include backlog refinement sessions.
Decide on Timing and Frequency: Decide on the timing and frequency of each event. Keep in mind the core hours you identified earlier.
For daily stand-ups, pick a time when everyone is generally available and ready to start their workday.
For longer meetings like sprint planning and review, make sure you allocate enough time for meaningful discussions.
Create Meeting Invites: Once you've decided on the timing and frequency, create meeting invites for each event. Include
the purpose of the meeting,
expected outcomes, and
any pre-work that participants should do before the meeting.
Communicate the Schedule: Share the schedule of the Scrum events with the team. Make sure everyone understands the purpose of each event and their role in it.
Ensure Tool Availability: Make sure video conferencing works for all remote team members, including microphones (these are the main culprits).
Send Reminders: Before each meeting, send out reminders to make sure everyone is prepared and punctual.
Thing to remember
The above suggestions are there to get you started. These are not the guidelines set in stone. Use your judgment and the situation at hand to customize the schedule and agenda.
Also, read the following.
This is it 🙏
If you have any questions (related to this topic), don’t forget to use the comments section to ask the community. I will try my best to get you an answer.
Big change is coming to the newsletter.
Starting next week, the “Winning Strategy” newsletter is going paid.
Free Readers:
You will continue to get this same newsletter, but only about once a month. If that's enough for you, by all means, stick with it.
Paid subscribers will receive the newsletter weekly + bonuses.
The weekly editions will be more in-depth
Subscriber questions will be prioritized
In-depth, training-ready coaching cards
In-depth topic series eg. “Understanding Agile Products,” Coming Soon
Access to future offerings
Your support will mean the world to me. Also, it'll help me make this newsletter even better!
What will it cost?
$120 per year, or $12/month
I suggest that you consider expensing this. My pitch to you (or your manager) is that if this newsletter can help you make one better decision each year, it’ll pay for itself. And if it doesn’t, you can cancel anytime.
If you are unable to expense or afford it, I can offer you a deal. Simply send me an email explaining your situation, and we can discuss a solution that works for you. It's important to me that the price doesn't become a financial burden for anyone.
🙋🏻♂️ Your Questions!
If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.
If you’re finding this newsletter valuable, consider sharing it with friends or subscribing if you aren’t already.
Till next week!
Sincerely,
Vibhor 👋
P.S. Let me know what you think! Is this useful? What could be better? I promise you won’t hurt my feelings. This is an experiment, and I need feedback. You can reply to this email to send your message directly to my inbox.
“I share things I wish I knew in the starting years of my career in the corporate world."
Vibhor Chandel