I’ve just qualified as a scrum master and our team are going to do scrum. What do I do?
Congratulations, you’ve earned your stripes as a scrum master and now you’re going to work with a scrum team for the first time. First step is to congratulate yourself and celebrate your achievement.
Now, you’re at work and it is time to work with the team. If you are anything like me, you got stuck in right away and start tinkering.
New scrum masters tend to tinker with everything, fiddle here and there, and decide what is scrum and what isn’t. Assess which ways of working align with the scrum guide and which elements don’t.
It’s a busy, busy, busy initial period filled with lots of enthusiasm and dogmatic approaches.
I want you to stop. I want you to breathe. And I want you to avoid doing that.
Observe
I want you to start by simply talking to the team. Take the time to observe what they are doing and understand why they are doing it in the ways they are. Have discussions with individuals on the team and discover what makes them tick and how they make decisions as both individuals and as a team.
In fact, I often recommend to new scrum masters that they simply observe for the first few weeks and don’t interfere or make recommendations for big changes.
It is critical that you integrate into the team and understand before seeking to be understood.
When you have enough information and insight, you can make the odd tweak here and there, which is helpful to the team but until you have that solid understanding of how things work and why they work that way, it is best to learn and develop relationships.
The danger of big change early in the process
Recommending big changes, early in the process, is going to trigger the team into thinking that you believe you know better than they do and that you perceive yourself to be in a better position to make decisions than they are.
In essence, believe that you can do their jobs better than they can.
That’s going to alienate you from the team and create a wall that will take a great deal of time to break down and rebuild trust with the team. Spare yourself the unnecessary difficulty and walk into the environment as a student rather than a teacher.
Discover rather than interrogate
So, take your time and understand what the team are doing and why they are doing it that way.
Maybe the team aren’t doing scrum. Why is that? How did that come about? What were the reasons for the team abandoning a solid framework and pursuing a different style of working?
Take the time to understand how the team are benefiting from that change. Learn what the primary, secondary and tertiary drivers of their decision-making to date, and get a strong grasp of the context that is unique to your team and the environment they work in.
There’s two ways to go about this.
Observe
Simply watch what the team are doing and how they work with each other as well as others within the organisation, outside of the scrum team. Look at how they approach problems and how they make decisions.
Is it evidence-based decision-making or do they make ‘gut’ calls? Do they interrogate the problem and explore opportunities to solve the problem as a team or is it an autocratic environment where the senior developers call the shots?
Take your time and maintain curiosity in all elements of the environment. You will learn a great deal simply through observation and you can make notes around all the elements that you want to discuss with individuals as well as the team.
Talk
You could approach a team meeting with an observation like, “I’ve noticed that you don’t do sprint retrospectives. Why is that?”
You may discover that the team have a great reason for not running a sprint retrospective, as outlined in the scrum framework, and may indeed have come up with an even better solution.
The team may respond that they are too busy to run a sprint retrospective and don’t fully understand the benefits of running one. Great, now you can discuss what sprint retrospectives are for, how they can help the team moving forward, and where possible, provide them with insights and evidence of how sprint retrospectives have helped other teams grow and improve.
Having discussions will allow you to understand why things operate the way they do, and it will provide you with opportunities to demonstrate, teach, coach and facilitate as needed.
Avoid making assumptions
One of the mistakes I made early on in my career was making an assumption about why a team weren’t running retrospectives. I was eager, enthusiastic and I wanted to make a positive impression straight out of the gates.
When I learned that the team weren’t running a sprint retrospective at the end of each sprint, I wanted to jump in and evangelise the benefits of a retrospective to the team. Luckily for me, a senior player on the team held me back from jumping in too early and encouraged me to observe first.
I accepted the invitation and joined the team the next morning at 9am. The team started the day by having a 30-minute discussion around what happened the previous day and how they could improve on that. In essence, a mini retrospective every morning with the intention of discovering ways that they could improve.
The team abandoned the formal sprint retrospective at the end of every sprint, not because they didn’t see the value in sprint retrospectives but instead, because they had discovered a better way of discovering opportunities to improve.
Each day they would look for a small opportunity to improve and actively implement it in the day to assess whether their hypothesis was correct or whether they needed to go back to the drawing board.
It was a great lesson for me. In observing and participating I had discovered why the team did their sprint retrospectives differently and understood why this was a better solution for them than the formal scrum event timeline.
Don’t make assumptions. You don’t need to. People are more than willing to talk to you about what they are doing and why they are doing it. You simply need to be open, willing to learn, and prepared to put dogma aside in pursuit of gaining a better understanding of what works best for the team.
Build relationships and trust
In the early days, it isn’t about pressing forward with your big ideas and making a deep impact on the team environment. Instead, you want to observe what is happening and earn the team’s trust.
Trust is earned when you demonstrate respect, professional curiosity and prioritise the team’s needs above your own. As you have discussions with individuals on the team and seek to understand how and why they are successful, you will begin to develop relationships that matter.
When the team know that they can trust you and that you are a keen observer, you will find it easier to bring ideas to the table and you will find that the team are far more open to exploring those ideas and opportunities because they know you have taken the time to understand their environment and their unique application first.
Providing insights, evidence and useful information to the team will help you build trust, credibility and deepen your relationship with individuals as well as the team.
In your first days as a scrum master, you have the opportunity to make a great impression that will serve you incredibly well in the months and years to come. So, take your time and invest in gaining a greater breadth and depth of knowledge about the team, the individuals, and the environment.
For more information on John McFadyen, visit https://www.growingscrummasters.com or connect with John on LinkedIn.
If you like the idea of becoming a scrum master, visit our Certified Scrum Master course page.
If you are already a scrum master and want to upskill, visit our Advanced Certified Scrum Master course page.
If you have several years’ experience as a scrum master and want to both validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master course page.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.
If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction to coaching course page.
#agile #scrum #projectmanagement #agileprojectmanagement #scrummaster #agilecoach #productdevelopment #scrumteam #scrummastery