A few months ago I presented a webinar on projectmanagement.com on how to transition from being a Project Manager to being a Scrum Master and working in an agile environment. If you’ve not had the chance to look at it; I’d strongly recommend taking a look! It’s one of my favourite webinars that I’ve ever presented.
After this webinar, I received a lot of emails and comments from people asking for a follow-up and additional questions about the issues that they had in transitioning so I’ve collated a few of these and given you a summary of the webinar below.
During the webinar, I discussed the conflicts that exist between the two methodologies and this being one of the biggest struggles that many Project Managers face. Whilst the difference between “People vs. Resources” isn’t so difficult for a lot of Project Managers to change, the change from “Likely to Will be” is perhaps one of the hardest things for Project Managers to understand and then implement. Working in a traditional Waterfall environment, you are primarily focused on fixed elements; fixed scope, deadline and therefore cost. When you move towards an agile project and environment, the flexible nature of the methodology causes a lot of Project Manager and stakeholders to either demand strict boundaries or alternatively they try to keep the team working within loose boundaries and lose trust with the team and their abilities.
Another big topic that I’ve had a lot of questions regarding is the role of a Scrum Master and the differences between this and being a Project Manager. As a PM you’re used to fixing the problems as they occur and directing them but as a Scrum Master you’re coaching and guiding your team to solve the issues for themselves. This core mindset change can be really difficult for Project Managers to accept and adapt to. Being a Scrum Master means that you’re working based on a larger element of trust. You’re not a Manager anymore, you’re a mentor, a servant leader and most importantly a change agent. Your aim is to make it as easy as possible for your team to work undisturbed and enable them to be the best that they can be. Whilst you may do that as a Project Manager in different ways; the control aspect is the core difference here. One Scrum Master asked:
“Emily, How do you trust the team if the team is not skilled enough? “
My answer was: Easy – I would train them! There are so many things that you can do to skill up your team. If you have Juniors at the start of your project; they don’t need to remain juniors throughout.
If you’re doing IT Projects you can do pair programming or mentoring by a more senior member of the team. This would not only help in training them but also help with team building.
One area that a lot of people have struggled with is going through the phase ‘denial’ and some Scrum Masters report that they struggle to have their teams and themselves leave that phase. Whilst looking through the root causes of why the team can’t leave the ‘denial’ phase, I’d also recommend making sure that you have some core fundamentals in place. Such as creating a Team Name and manifesto. This is also an integral part of the team building. Once this is in place, as a Scrum Master you can understand what the teams’ core values are and then you can move forward in building trust and getting a well-oiled team working more cohesively together.
Once the team have gone through Denial, the next stage is Guilt. Almost all new Scrum Masters experience this level of guilt and some try to go over and beyond to make up for their failings. One way of getting through this is to make sure that you’re being open, communicative and very clear about expectation management. Guilt is a natural emotion and it’s important to realise that you need to go through these stages and understand that process to be able to empower your team. When you realise that you’re the problem, work on what you can do to resolve this and work on creating an environment where people want to excel and where mastery is allowed.
Question: When you said your team was stuck in ‘storming’, can you explain what you meant by giving them the space to move out of that step?
Answer: During the storming phase I was getting the feedback during the sprint retrospectives that the team were struggling with outside influence and not being able to complete their work. I focused in the next 2 sprints of ‘shielding’ them from any outside influence to enable them to live in a ‘team bubble’. The only contact with the ‘outside world’ in a business environment was the PO and myself.
The value of giving them space also enabled them to work together as a team to resolve issues discovered during the sprint and allowed me to coach and facilitate.
The next stage is my least favourite one… it’s Anger. A lot of people when it comes to change get Angry. Any change, they start shouting, getting angry and a lot of conflicts can occur. When conflict does occur – you need to be handling it in a culturally sensitive manner as going around shouting is not acceptable in a lot if any cultures! So when we’re in our anger stage – look at what is the root cause of the anger? Is it a reaction to the change? Is it a personal reaction to the changing way of working? Is it a ‘natural’ process for your team to follow. One thing to also remember about the changing nature of teams is that the process may begin again/reform when you add more members to the team. This is something to keep in mind when you’re looking at the root causes for anger within your scrum team.
This next stage is most likely to happen when things go wrong e.g. there’s a low velocity in one sprint, where the team is storming rather than performing. What do you do when you see this?
- Analyse what’s going wrong and what can you do resolve it.
- What is the root cause of the issue?
- Take a step back and look at the metrics that you’re working with and be very transparent to your team
- Continue to use the best practices.
- Give your team the room to develop and take ownership of the issues that they are seeing.
This is one of the interesting phases of transition. This is where there are a lot of benefits of your hard work are being realised. The team tend to be happier and the comments in the retrospectives are positive. This stage is one of the key transition steps for being a Scrum Master because you’re seeing that it works and you’re seeing the benefits that it can bring.
This is the final stage of the change towards becoming a Scrum Master. You are fully aware of the changes that are going on, you are in control of your role and do not overstep boundaries and your team are happy and performing well. You realise that things may go wrong; such is life – but your team are empowered enough to handle the bumps in the road and can work together to resolve the issues as they occur.
If you or your organisation is new to working in agile, one thing that really helped me was having some experienced coaches on hand to support me and also my bosses and key stakeholders going through this transition. It was through this change that the full understanding of:
“ To excel at something, you need to suck at it first”
really sunk in for me. As a Project Manager, I strive for perfection and strive to be the best. Transitioning to a Scrum Master was a really steep learning curve for me and it was one that I struggled with initially. Being able to trust the team that I was working with was a really big part of my improvement and learning. I thoroughly being part of the transition into a Scrum Master but it was a learning period that took time, dedication and a lot of understanding.
Here’s a list of all of the questions that I received during my webinar. I hope that you find it useful!
What part of your transition to scrum was the most difficult?