How to Stop Chasing your Team for Scrum Events? What to do if Product Owner is not Present for Sprint Planning Meeting?
Common issues faced by Scrum Masters and their simple solutions.
š Hello,
Iām Vibhor, and welcome to my weekly newsletter, the āWinning Strategy.ā Every week I answer one question 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.
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 questions!
Q: Greetings from Netherlands! I am deeply inspired by your No-To-Dos that you posted on LinkedIn a few weeks ago. You mentioned that a Scrum Master should never chase the team for Scrum events. I 100% agree with the notion. Can you suggest how to accomplish this?
Absolutely! Thanks for the question.
As a Scrum Master, I've learned many lessons throughout my career, and I'd like to share one particular story that taught me to "never chase the team to make them attend scrum events.ā
I was once part of this diverse team of developers, designers, and testers, all working on a groundbreaking application for the healthcare industry. My main responsibility (as per their expectations) was to facilitate the Scrum method and ensure that the team was on track to meet their goals.
During my first week, I noticed that the team members were not very enthusiastic about attending the daily stand-up meetings. Some team members would show up late, others would be fiddling with their phones, and some wouldn't attend at all. It was clear that they didn't see the āvalueā in these scrum events.
To improve the situation, I did the obvious.
I started chasing the team members, reminding them about the importance of the meetings. I increased the rate of sending calendar invites and email reminders. At first, it seemed to work. Attendance improved, and the team seemed to be more engaged during the stand-ups.
However, after a few weeks, I noticed that the team members were becoming more resistant. They seemed to view the daily stand-ups as a chore, something they were being forced to attend. The atmosphere during the meetings became tense, and it was clear that my efforts were not helping the team to work more effectively.
I decided to take a step back and reconsider my approach. I realized that by chasing the team and trying to force them to attend the scrum events, I was only creating resentment and further disengagement. Instead of trying to control their behaviour, I needed to find a way to demonstrate the value of these events and help the team see the benefits for themselves.
What came to my rescue was a āRetrospective.ā This always works when nothing seems to be working.
I organized a retrospective meeting to discuss the team's āfeelingsā about the daily stand-ups and other scrum events (you might want to check out the LinkedIn post I created on how to conduct retrospectives based on feelings a few weeks ago).
After the retrospective meeting, it became clear that many team members felt the scrum events were taking time away from their actual work, and they didn't see how the events were helping them achieve their goals.
To address these concerns, I worked with the team to modify the format of the stand-up and introduced some techniques to make them more efficient and focused. I have described one such format below.
We experimented with a few different approaches and eventually settled on a format that the team found more engaging and valuable. I also made sure to highlight the positive outcomes of the scrum events, such as,
improved communication,
faster problem-solving, and
a better understanding of project progress.
If an event didnāt promise at least one of the above 3 outcomes, the team was allowed to discard it.
As the team began to see the benefits of the scrum events, their engagement and attendance improved naturally. They started to take ownership of the process, and I no longer needed to chase them or remind them about the meetings.
Walk-the-talk stand-up format
Hereās how it worked:
Walking meetings: Instead of holding the stand-ups in a fixed location, we decided to conduct them as walking meetings. The team would gather at a designated starting point and walk together along a predetermined route, either inside the office building or outside if the weather was nice. This change in environment helped stimulate creative thinking, improved team camaraderie and created a more relaxed atmosphere for the discussions.
Paired updates: To encourage deeper connections between team members and foster collaboration, we introduced paired updates. Each day, two team members would walk together and share their updates with each other. After a few minutes, they would switch partners to share updates with another team member. This rotation would continue until everyone had shared their updates with each other.
Designated discussion points: Along the walking route, we marked several designated discussion points where the team would stop and discuss specific topics, such as potential obstacles, opportunities for collaboration, or ideas for improvement. These discussion points allowed the team to address pressing issues and brainstorm solutions together. This enabled a more collaborative problem-solving approach.
Closing circle: At the end of the walking route, the team would gather in a circle to briefly summarize the key takeaways from the paired updates and discussion points. This closing circle allowed the team to ensure everyone was aware of each other's progress, challenges, and plans for the day, fostering a shared understanding of the sprint status.
Optional audio recording: Since the "Walk and Talk" format was more dynamic and less structured than traditional stand-ups, we offered the option for team members to record their paired updates and discussion points using a voice recording app on their phones. This allowed team members to review the information shared during the stand-up easily. All recordings were supposed to be deleted by end-of-day every day.
What should be done when the Product Owner is unable to attend the Sprint Planning meeting? Can you provide some guidance on how to handle this situation?
Before diving into the solution, letās first understand why the attendance of a Product Owner is crucial in Sprint Planning meetings.
The analogy Iād like to use is that of a Screenwriter for a Netflix series. The Screenwriters are like team Product Owners. They provide the script, the essence of the story, and the emotional journey it should take.
The Development Team is the crew members, such as the director, actors, cinematographers, and editors, who bring the story to life.
The Scrum Master is like the Production Manager, who ensures everyone understands their tasks, resolves issues, and ensures the project is completed on schedule.
Letās suppose that one day the Screenwriter (PO) hands over the basic story outline to the team without providing further details. The Production Manager (SM) and the crew (Dev Team) are left with many questions,
What's the motive of the main character?
What are the key turning points?
What is the underlying emotion of a particular scene?
Without specific instructions and details from the Screenwriter (PO), the team could interpret the story differently, potentially leading to a play that doesn't match the original vision of the Screenwriter.
Similarly, in Scrum, without the Product Owner's active involvement in Sprint Planning, the team may end up developing something different from what the PO intended, which could fail to deliver maximum value to the stakeholders.
What can be done if the Product Owner is absent during the Sprint Planning meeting?
It is necessary for the Product Owner to be present, but in the event of an unexpected absence, there are some actions that can be taken.
Product Owner Proxy: Work on finding a proxy in advance. Usually, a BA, a person deeply familiar with the project and its goals, can help you make the crucial decisions that keep the sprint on the track. However, it's crucial to remember that this stand-in role (proxy) is to echo the PO's vision, not to come up with a new one.
Reduce Sprint's Capacity: People can't be present at all times - even the PO! Whether it's a well-earned vacation or an unexpected absence, respond by fine-tuning the planned capacity for the current sprint. Maybe decrease the workload for this sprint by a reasonable amount through careful consideration. Remember, the goal is to maintain a sustainable pace and deliver consistent value, not to maintain velocity.
Seek Input from Stakeholders: Stakeholders can offer valuable insights about customer needs, market trends, and higher-level business objectives. So seek their attendance in POās absence.
Dive into the Existing Product Backlog: The Product Backlog is your roadmap, and it should always stay primed for action. So, in the absence of the PO, put your faith in your prior planning sessions and the mutual understanding you've developed as a team. With caution and collaboration, you can take up the challenge and move forward. Keep in mind that this method does come with a bit of risk, but hey, you're an agile team. You thrive on adaptation!
Use remote tools: This is more common now than before 2019. Have the Product Owner attend Sprint Planning via audio or video conference if they are too sick to be physically present.
To put it simply, the objective is not to keep everyone occupied 24/7. Your aim should be to establish a sustainable process that can accommodate minor disturbances throughout the project's duration. A good process should function as a means of smoothing out any issues over time rather than as a tool to coerce individuals to work harder or engage in busy work due to easily foreseen deviations.
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.
šš»āāļø 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