How a Scrum Master can Support and Foster an Agile Culture within the Organisation
The scrum framework consists of three types of roles, the Product Owner, Development Team, and Scrum Master. The main focus of the Product Owner is maximising the value of the product, setting a vision, prioritising the backlog, and delivering value to the stakeholders. The Development Team is responsible for the execution part, and the Scrum Master is responsible for ensuring that the Scrum framework is implemented correctly, facilitating scrum events, and removing impediments. In the past 4+ years working as a Scrum Master, I have closely worked with the Product Owner and supported them in the execution of their responsibilities.
In my current organisation along with handling two scrum teams, my focus is also to support the organisations with overall agility which includes:
Communicating and coordinating with the other Scrum Masters
We have successfully built a strong Scrum Master community where we share experiences, bounce ideas off each other, challenge each other, and brainstorm on various topics that help us grow in our role. We share best practices and facilitate mock-up events such as new retrospective activities, team canvas, and team building activities, providing an opportunity to get quick feedback and improve based on the inputs before we actually facilitate these activities to our teams.
Supporting new members with sessions on organisational agility
On boarding is one of the crucial events for a new hire, along with all the other onboarding sessions that will help the new hire have a smooth transition and support them with the essential knowledge to help them uncover the unknowns in the new role. We also include a session on Agile Ways of Working, which provides an overview of the Agile framework, Scrum, and basic information on the common agile practices followed in the organisation.
Promoting a culture of continuous improvement
We assist multiple teams in addition to our own teams by arranging retrospectives as external individuals, design team off-sites, team kickoffs, and various team building activities.
Providing Training and Coaching
As Scrum Masters, we create awareness about agile practices and give training in a variety of ways, such as assisting teams in learning how to use tools and techniques like JIRA, MIRO, and Mindmaps. We provide training to help non-development teams like HR, Sales, and Customer Operations adapt an agile mindset.
Sharing my experience of coaching sessions with Product Owner
During one of the Retrospective that I was facilitating as an external Scrum Master we uncovered a list of potential challenges that the team members were facing. Being an external Scrum Master, I had no prior knowledge about the team’s ways of working or any potential issues. It was like a clean slate for me; my focus was to help the team uncover problems and think about possible ways of improvement. During this Retrospective, the Product Owner highlighted the challenges she was facing, which got me thinking about how I could support the Product Owner in this situation. I asked her if we could set up just four coaching sessions to brainstorm and help her overcome the challenges. I explicitly used the word "brainstorm," as this is a journey we both have to take to figure out possibilities and help resolve these challenges.
We did 30–45 minutes four sessions over a span of one and half month.
1st Session:
This was the 1st session I wanted to make it engaging and kickstart a conversation. I started with the 8 stances of a Product Owner. I created a MIRO frame and added the 8 stances of the Product Owner to it. During our discussion we went over these 8 stances and tried to categories the day to day work based on these stances. By the end of the session we realised that as a Product Owner she is playing more of a mediator role in team meetings or refinements.
#1 challenge: The role of the mediator during refinements
The team doesn’t have a dedicated Scrum Master and every team member has different expectations from the refinements. The Product Owner is currently struggling with the responsibility of being the mediator between the team members. During the decision we realised that the team estimated using work days. Like every other team this team has a combination of developers with varying experience and seniority level. The level of expertise also plays a crucial role. When estimating in workdays implies that everyone takes the same amount of workdays to finish a certain work item and keeping in mind all the above variation of experience, knowledge it makes it practically impossible. Putting a lot of pressure on new joiners or medium or junior experience level team members. The Product Owner during the refinement and estimation finds it difficult to communicate and create common ground. The team doesn’t have a dedicated Scrum Master, every team member reports to a different Engineering manager making it difficult to include anyone from the leadership team to help with this situation. The go to person or the responsibility to negotiating on these trivial issues ultimately falls on the Product owners shoulders.
How did we fix it?
There isn’t one single thing that could help us fix this situation, it took a couple of months to resolve this challenge.
Highlighted the current team situation to Leadership and how it was impacting the team. We worked towards making sure all the team members report to one Engineering manager.
I facilitated another Retrospective on Psychological Safety which helped uncover the potential issue the team member were facing with estimations and pressure that was building up. Action item were derived and everyone was made aware of the challenges faced by team members with varying level of experience and expertise.
2nd Session:
We tried to dig in deep to find out the “WHY” behind the first challenge. We assume apart from not having a dedicated Engineering manager or a Scrum Master to support the team the reason could be that the previous Product Owner played two roles within the team — Engineering Manager and Product Owner. The team was used to this behaviour no one ever tired to bring this to the teams notice that now they have a dedicated Product Owner. There is a split in the responsibilities that comes with this change.
#2 challenge: The blurry boundaries of the roles and responsibilities
The team doesn’t have a clear understanding of the roles and responsibilities. The team needs to be educated about the responsibilities of these three roles. A dedicated Engineering manager or Scrum Master is not the ultimate solution. The team needs to be aware about the responsibilities and boundaries of these roles.
How did we fix it?
During our next Retrospective we did a Roles and Responsibilities activity. Where the team got the opportunity to discuss and have a shared understanding. This not just helped the Product Owner but it also helped the team to understand WHY the Product Owner shouldn’t be help responsible for responsibilities of either the development team, EM or SM.
3rd Session:
During the third session we focused on highlighting What were the other challenges that the Product Owner was encounter while carrying out the responsibilities of the PO role.
During this session we came up with a number obstacles that the Product Owner was facing.
#3 challenge: Multiple challenges
Small backlog, enough work just for the next sprint but less insights on the bigger picture. The main stakeholder is the Marketing team and there is no roadmap visibility.
The teams roadmap is very dynamic and keeps on changing which makes it hard for the team to plan and refine stuff. Changing priorities is also a problem.
Too generic company KPI. For example “fix our shit”. But the team has not defined what exactly do they plan to fix this quarter. No clear boundaries makes it difficult to measure the KPI’s success rate.
New buzzing stuff puts pressure and the Product Owner tries to address it which again leads in change the priorities ultimately contributing to the dynamic roadmap.
How did we fix it?
During our 4th session we tried to categories challenges as internal and external. Internal challenges will be attended by the team and external challenges will be addressed by PO and EM by either reaching out to leadership or other teams.
4th Session
As mentioned above the 4th session was actually to explore ways to to find out how can we fix these challenges, the first step was to start categorising these challenges as internal or external. Once the challenges we marked the next step was to discuss on how to actually resolve them but with the right set of people.
Gradually with everyones efforts the team was able to create a clear and transparent roadmap. Within no time the team was swamped with projects.
This was also the first time I worked with a Product Owner apart from just supporting with backlog management or team specific work. These sessions were more focused exploring how can I as a Scrum Master support the Product Owner in in any manner that is practical. The first step was to identify these challenges and then decide how can we work towards resolving them. We weren’t sure what to expect from these sessions, but I was surprised to find that they were really beneficial. When we started with these sessions it was like walking in the dark, just figuring out the next step and it worked. We even decided to just end the session if, at any point, we felt it was not helping, fortunately we went through all the 4 planned sessions.
Comments