Back to Blog
Agile Practices 101
As a teacher turned agile enthusiast, I recently decided to take the plunge and become a Certified Scrum Master (CSM). 🎓👩🏫
To be honest, I had a pretty solid idea of what I was getting myself into. After all, I’ve spent the past two years learning about agile - specifically retrospective - best practices through countless interviews with experienced agile coaches, scrum masters, SaFE trainers, and facilitation experts and by reading the blogs, books, Reddit posts, and YouTube comments of hundreds of agilists around the world.
I knew that my desire to become a CSM was significantly different from others in my cohort. Specifically, my teammates were pivoting their careers or were looking for a way to improve the scrum framework at their perspective organization. I, however, wanted to learn what new scrum masters did and did not know about agile, including how to build a career and what questions they may have once they put their training into practice.
Like many new CSMs, I went to one 2-day training. Sure, experiences in other trainings with other trainers are going to be different. However, what I’m sharing here is not just about my experience and takeaways from the training. We have a total of seven CSMs at Retrium that have completed their certification with different instructors at different times. It’s these combined experiences paired with those shared online that have helped compile the questions you may have once you complete the training - and the ones you should be asking yourself.
According to the official Scrum Guide written by Ken Schwaber and Jeff Sutherland, the
“Scrum Master is accountable for the Scrum Team’s effectiveness… They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.”
What does that mean, exactly? 🕵🏽
Let's take a second to state the obvious. A large organization with dozens of scrum teams will have different needs than a startup with only one. To remain adaptable, the scrum method is a “lightweight framework.” Meaning Scrum in its purest form is purposefully flexible. The guide remains open for interpretation and adaptation based on the CSM’s unique needs. So there are not any strict guidelines on how to run events or what specific artifacts should look like.
There are multiple examples of events and artifacts that leave new scrum masters wondering “when is there a prescribed process or best practice?” It can be confusing.
For example, what is the best way to prepare the Product Backlog Artifact? Some might say stories are the best way to create a Product Backlog Item (PBI). Other trainers will disagree on the grounds that the backlog items should never be more than a few words. Who is right? 🙃
Similarly, daily scrum should definitely be run using the standard “what did you do yesterday, what are you doing today, what are you stuck on” format except for the teams that should avoid this format so it doesn’t become just a daily report out.
So, what does it mean to be a successful scrum master? In truth, it’s hard to get or give a straight answer to this question. A lot of how you define your success comes with experience, which you probably don’t have as a new CSM. Instead, approach your entry into scrum mastery with curiosity and a willingness to learn so you can adapt what you’ve taken from your training to your team’s needs. Your success will follow.
And with every step, ask your team what they need to be successful. You don’t have to pretend to know everything. In fact, don’t do that at all! Be honest with your team about your observations and challenges, and build systems that fit your opportunities together. And when those systems falter, keep adapting. Remember, Scrum is based on Transparency, Inspection, and Adaptation. As long as you keep those pillars in mind as you work with your team, you will be successful.
The official recommendation for handling conflicts over events is to explain the value of the event to the team members. 🤔 Which isn’t a lot to go off of.
As any coach will tell you, conflict is healthy. Let me qualify, healthy conflict is healthy. Conflict without boundaries, alignment, or respect creates a toxic work environment that hurts productivity and mental health. So how do you, as scrum master, handle conflicts in a way that helps your team grow and evolve without creating a toxic environment? Especially when the organization is just starting to adapt to scrum, and management is struggling to buy in, or when you are going against the habits of a developer that is twice your age and has been with the company for four times as long. These are moments when you need to be prepared to handle tough conversations in effective ways.
“Vulnerability is not winning or losing; it’s having the courage to show up and be seen when we have no control over the outcome. Vulnerability is not weakness; it’s our greatest measure of courage.” -Brené Brown, Rising Strong
In these situations, it is important to remember that luck favors the prepared. Learning from other facilitators like Leslie Riley, Amy Edmonson, and Brené Brown will give you the tools you need before hard conversations, so you can facilitate effectively.
Some of our favorite advice on facilitation comes out of the webinar, 5 Things I Wish I Knew Before I Started Facilitating Retrospectives with Leslie Riley, the Executive Director of Full Circle Inspiration and storyteller extraordinaire, whose experiences as a cadet at West Point, working in Corporate America, and running her own business shaped her unique perspective as a facilitator.
To understand number 3, let’s do a bit of role-playing. 🎭
Imagine that you are the new scrum master on the team. Congrats! You ask the team members about their experience with scrum. Here’s what you hear:
Your senior architect responds, “I have been around since agile was the new thing that everyone had to try. So I try to just keep to the basic principles and don’t pay too much attention to whatever framework management is trying to push.”
Your junior UX developer explains, “My professors at <amazing university> encouraged us to use a kanban format for all our projects.”
And your new senior javascript engineer states, “We used a strict SAFe format at my last job.”
What have you learned? If you haven’t already gone above and beyond your scrum training, you haven’t learned much.
After all, you took Scrum training, why would your trainer spend time on other frameworks or abstract concepts.
However, taking some time to understand the basics of other frameworks and the original origins of scrum in agile development would help new scrum masters connect with team members that have a variety of experiences and better anticipate where issues and misalignment will occur.
While we are role-playing, let’s keep going.
It is time for your retrospective! 🧐
What are you going to do for the meeting?
If you are going off your training and the scrum guide, it is going to be a very quiet (or loud) hour.
A similar story could be told about your sprint review or sprint planning.
Just like we discussed in item 1, What does it mean to be a successful scrum master, it is up to you to learn different formats and techniques for the events. The retrospective being the event that needs some of the most research. While sprint planning, daily, scrum, and sprint review have specific agenda items you need to cover, the retro can be more abstract. Does your team need to retro on a specific system or a set of behaviors?
While it is important to remain flexible, understanding the value of various retrospective techniques will help you, as a new scrum master, prepare and organize high-value opportunities for collaboration and continuous improvement while feeling more confident in your facilitating abilities.
A good place to start is by reading articles and blogs or taking our in-app technique picker quiz to familiarize yourself with the value and functions of different retrospective templates. And if you have the chance to read Esther Derby and Diana Larsen’s Agile Retrospectives, take it! It is filled with tools and tactics to run transformative and effective retrospectives. (There’s a Second Edition in the works with a new third coauthor so be sure to be on the lookout for that!)
If you go to LinkedIn, Indeed, AngelList, or any other job site and search for scrum master you will find an abundance of “and” jobs.
Scrum Master and Product Owner. Scrum Master and Product Engineer. Scrum Master and Project Manager.
While the agile and scrum purists reading this might protest that behavior and -rightfully- say, “those teams aren’t practicing real agility,” that is the role - or dual role - many new scrum masters must fill.
Let’s face it, getting started as a new scrum master can be hard especially if you don’t have a decade of technical experience. Many new scrum masters take these “and” jobs hoping that it will be an opportunity to launch their career as a scrum master only to get burnt out from juggling multiple responsibilities within the first year.
This circles back to the importance of understanding the full agile ecosystem and the experience of your team members with different frameworks. When scrum masters understand what is expected to help their teams be successful and know how to manage and adapt to those expectations, they are better able to serve the organization, the team, and themselves.
Our best advice for those in these roles is to remember the importance of a growth mindset and focus on the tasks and issues that are under your control. Looking for small ways to improve will bring you more happiness than focusing on larger issues outside of your circle of influence. And every day try to make the job a little closer to what you and your team need.
Agile is not just a job, it’s a mindset. 🧠
Bonus the Agile Mindset!
When I think about what makes scrum and agile great, it is the flexibility and focus on adaptation. Something isn’t working? Change it. Experiment. Something is working fine? How can it be improved? What can we do better?
Taking the time to learn, explore, and observe what it means to be agile is one of the best ways to develop your agile skills, regardless of what framework your team follows.
.png){kind=small}
