Charlotte Fouque
March 2018 marked the end of my fourth year as a Scrum master. I began with a Certified ScrumMaster workshop in 2014 and haven’t stopped learning since. I keep a running list titled “Lessons Learned,” where I jot down thoughts I find significant as they occur to me so that I can go back to the list and draw from my little bank of personal wisdom.
Some of the items on the list are practical (“Estimate size, derive duration!”), some are abstract (“Don’t let the process get in the way”), and some are just reminders (“Stop being resistant to change, let yourself be flexible”). They are the distilled product of my experience working with Scrum teams. Here are a few that I would like to share with you; I hope you will find them useful in your own path.
1. Learn about people
Learning about Scrum and Agile is essential to a Scrum Master’s formation. There are multitudes of books, blogs, podcasts, and other materials available to fulfill that need. However, a more well-rounded curriculum includes learning about people. After all, the Agile manifesto begins with “Individuals and interactions over processes and tools.”
The Scrum Master role is about dealing with people and how they communicate and work together, more than it is about process and process frameworks. Without understanding people and the nuances of their interactions, how can a Scrum Master be an effective servant leader?
I suggest reading about teams, leadership, management, psychology, and anything else that might give you insight into people and how they work. Here are some examples:
- The Five Dysfunctions of a Team by Patrick Lencioni is an excellent place to start. It is an enlightening introduction to the roots of the problems you have likely observed on your own team, and gives some practical ideas for how to address them.
- If you work in software development, chances are you have some introverts on your team. Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain will help you understand what it’s like for those individuals to work on a team and how you can help them.
- Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink gives great insight into the intrinsic motivation factors of autonomy, mastery, and purpose that align neatly with the Agile values.
2. Buy sticky notes - lots of them, all the colors
Not just sticky notes: index cards, colored markers, sticky dots, funny stickers, cork boards, whiteboards, magnets, flip charts, tokens, butcher paper, the list goes on. If a team is co-located (even temporarily), physical exercises will come in handy. I don’t mean jumping jacks, but activities where everyone is actively participating instead of watching one person move virtual cards around a virtual board on a screen.
The team will feel more engaged and involved if they are standing, moving around the room, physically doing the planning, or the writing, or the moving of cards. I have observed this firsthand in activities like user story mapping, user story writing workshops, sprint planning, retrospectives, and daily standups.
The act of writing on paper can be much more powerful than typing and can be more easily displayed publicly. A team’s Definition of Done should be visible and obvious - write it on a flip chart sheet and hang it up on the wall of the team room (better yet, have the team write it together). The act of writing will help them remember it, and help them own it.
A physical burndown chart that team members update every day as part of standup brings everyone’s attention to it, where they might not think to go look at their digital tool. Have fun with it too - one team I work with uses emoji stickers to mark tickets that will require lengthy QA time.
3. Don’t force it
It may be intuitive for many people who find themselves in the role of Scrum Master to try to make development teams conform to Scrum, or make organization leaders see that they need Agile in their lives, or make managers understand how they should interact with the team, or make their team adopt new engineering practices.
This type of “command and control” approach is not compatible with the Agile mindset, and can be extremely detrimental to fledgling teams (even more so to ones who have already been working in Agile), who will chafe at being told what to do and react negatively. It’s also going to be frustrating for you when it doesn’t go your way - and it won’t.
Instead of trying to force the results you want, first examine your reasons for wanting those results: is it because it’s in the best interest of the team, or is it just what you want? Then consciously let go of what you want, even if it’s what you think is best for the team.
Start asking questions: Why isn’t the team paying attention to the sprint burndown? Ask them instead of becoming frustrated when they aren’t heeding your daily reminders to stay aware of the sprint’s progress. Maybe it’s hidden away behind some easy to miss menu in their digital tool, or maybe they don’t feel ownership of the sprint work enough to care about its progress. Why aren’t team members practicing pair programming daily, when you have repeatedly made the case for its usefulness? Maybe your team is composed of introverts who are uncomfortable sitting close to others and talking out loud for extended periods of time, and feel they produce their best results when they are allowed to achieve a state of flow in isolation and privacy.
Ask the team, instead of trying to come up with the answers on your own. It’s easy to think or assume you know what the other party’s motivations are, but the only way to know is to ask. Once you understand the reasons why by asking the right questions, you can begin addressing the root cause in a way that will truly help whoever you’re working with achieve their goals, not the results you want from them.
4. Curb your inner helicopter Scrum Master
Let the team fail and recover on their own instead of swooping in with advice or corrective action at every sign of danger. Not letting the team make mistakes seems intuitive - after all, you are partially responsible for their success, and failure may reflect negatively on your work with the team.
It is the responsibility of the Scrum Master to ensure that impediments are removed, and you may see future pitfalls as impediments in the team’s way. However, it will be more beneficial for the team in the long term to help them learn how to identify those dangers and take action themselves, rather than relying on you to constantly be on the lookout in their stead.
It is a core concept of the Agile mindset that learning from mistakes is more effective and valuable than learning from success. Instead of preventing mistakes and failures, ensure that the team has a safe environment to make mistakes, where failures are low-risk and low-impact:
- You can foster a culture of trust where the team will not be afraid of ridicule and repercussions for making mistakes.
- Working in short iterations means that, if unsuccessful, one sprint won’t be likely to sink the whole project.
- You could encourage the use of testing environments where experimentation can be carried out safely without impacting the live product and its users.
- Continuous integration and deployment practices make implementing and testing small changes to the code effortless, and help lower risk at the time of release.
Don’t attempt to solve or prevent all of the team’s problems for them like a helicopter parent might “hover” over their children, even if the solution is obvious to you. Instead, let them make the mistakes, and ensure that they can learn from them and use that knowledge to improve as a team and prevent future mistakes.
5. Know what success looks like
When a team is first formed or adopting an Agile framework for the first time, they will likely need the Scrum Master to guide them through everything, from facilitating every meeting to removing every impediment. A good Scrum Master can shine in these moments, jumping at every call for help and doing everything they can to see their team through difficult situations.
It feels great to be needed and depended upon for your expertise, and there’s a lot of career advice that emphasizes the benefits of making yourself indispensable to gain recognition and job security. But is it actually a good thing when a team that’s been working together for months or years continues to look to their Scrum Master for help at every turn?
I believe that the best sign of a Scrum Master’s success is that their team no longer needs them. This will mean that he or she has set their team up to be independent, self-organized, empowered, and striving to continuously improve without being pushed to do so. This isn’t going to happen overnight, and it will require careful consideration about whether the team is ready to take over the responsibilities that the Scrum Master has been fulfilling.
A good way to pilot this is to just not show up and see what happens. Don’t attend every standup, miss a sprint planning or retrospective every now and then, or even take a vacation and don’t worry about having anyone fill in for you. Did the team keep functioning normally? Maybe stay silent during a conflict. Did the team resolve it without your input? If yes, then you have achieved success: your team no longer needs you.
So what now? You don’t have to dust off your resume quite yet. The team may still need your assistance in some cases, such as removing organizational impediments that are outside their sphere of influence, or individual team members may still need coaching. You may be called upon to see them through some major changes, or help them kick off a new project.
You will also expand your efforts working with others in the company, such as managers and executives, to help them create an environment where the development teams can continue to flourish. Check in with your team at regular intervals - even if they don’t need you, they may still want you around!
