Reflections on 3 Years as a “Scrum” Master and Scrum Master

I came to be a Scrum Master after burning out on my career as a Technical Writer. Luckily, my boss at the time approached me with a new opportunity.

“We do Scrum,” he said, “and we need a Scrum Master.”

I agreed, though I knew barely anything about Scrum, so I read the Scrum Guide, took some online courses and came away thinking that I had a good feel for the framework, but not necessarily the actual ins-and-outs of really doing it.

When my boss left the company soon after, he mentioned Water-Scrum-Fall and told me that’s what the organization really did and that he had been trying to move towards Scrum. A water-fall-scrum — or Trapped in Wagile — the organization does big batch design and requirements at the start of a project, then sends those off to developers who develop and test in “sprints” and finally release once when everything is done.

At this point, I wondered how I could bridge the organizational gap and realized maybe I did not understand Scrum as much as I thought.

It was during my Certified Scrum Master (CSM) course when it finally clicked. Someone was describing Waterfall vs Scrum and said, “really Scrum is like a bunch of mini waterfalls,” when the instructor pointed out that waterfall is defined by distinct stage gates, but Scrum is not those same gates on a smaller scale, rather, all the necessary work is happening all at once by everyone on the team.

“When do the developers do the analysis?”
“Whenever they need to.”

“How much time is allocated to design?”
“As much as necessary to complete the work.”

“Does development need to be done in order for testing to start?”
“No, in fact, tests can be written before development begins.”

I’m glad I was able to correct my early misconceptions about Scrum, but I worry about those who work under the framework and were given the wrong impressions to start.

Too often, Scrum and agile are pushed upon developers. They are not given the opportunity to explore it’s pillars and values, or to think about the reasoning behind its foundations. Instead, implementing Scrum becomes yet another framework they are beholden to.

It is unfortunate that teams are asked to “do” scrum by management edict, or even worse, when a team “adopted” Scrum some time ago but really suffers under a variation of Dark Scrum.

Ideally we want our teams to be energized by the vision for the product they are building for their customers. As a practicing Scrum Master, I have learned that when a team is going to adopt Scrum, the least we can do is meet them where they are.

So with that in mind, I am sharing some things that have been helpful to me, and hope that it helps you too.

1. Throw out the buzzwords

I have seen one too many eyes glaze over in meetings where someone rattles off agile buzzwords out of context. So I avoid using them. Don’t say Agile. Don’t say DevOps. Don’t say  Continuous Anything.

Find out what people really care about, then explain it in those terms.

If a developer is concerned about lack of time available to build a robust system and meet business expectations, then talk about the empirical benefits of building stable systems. How designing and writing tests before development give us confidence that everything is in order, and we can avoid rework down the line. This saves time in the long run because our product is stable and adds value incrementally. And we don’t even have to say Test Driven Development.

If it takes too long to release the system after the product backlog items are otherwise “done”(about half the length of a sprint), see if the team can brainstorm ways to automate certain elements until releasing becomes a one-click process. It does not have to be one click the very next day, but can be done in incremental steps. You don’t need to mention DevOps to deliver continuously.

Sure, once any of these practices are well understood, it is acceptable to name them and use those names going forward, but when someone new is introduced to the group, or an outside stakeholder has questions, remember not to throw buzzwords at them.

2. Be “agile” not Agile

There is no such thing as one size fits all. Agile transformations in large companies will need different approaches based on the team situation.

As a Scrum Master, I hold this fundamental belief:

The people doing the work are in the best position to improve their work, and it’s my role to help them do their best thinking.

When I say capital-A Agile I am referring to a mindset that a coach or scrum master will be able to tell the team all the things they need to do to improve and the team only needs to follow directions until they reach perfection. While lowercase-a agile is about fostering a culture of better communication and continuous improvement, and then helping the team in ways the team asks for your help. Remember that the original agile manifesto and principles were synthesized (bottom-up) advice from years of development experience, not sent down from on high (top-down).

3. Don’t give up on servant leadership

Most people, even the most well meaning, have a breaking point. Scrum Masters who care deeply about a topic will do their best to serve the team until they reach that point, when they may try to directly manage the team.

My simple advice: Trust the team, don’t make them do it your way.

It can get worse when the Scrum Master tries facilitating with a hidden agenda, pretending to be neutral, but nudging things in their preferred direction. Even if these methods provide a temporary benefit, the team has lost an opportunity for growth, and is not likely to become a true self-organizing team. The team also loses trust in their own ability to be agile, when they realize they will be pushed in a different direction whenever the scrum master, coach, or manager disagrees.

As a Scrum master, if I think an issue is important for the team, then I talk to team members about it to gain insight, but never to coerce. Often, I find that they have a better grasp of the issue than I do. I remember the purpose of a servant leader, and always have the team’s best interest at heart as I help them realize their own greatness.

These things are important to me because I started on this path to help create high performing teams that develop interesting products and excite customers, and I believe this is the best way to do it.

My journey started out with an incomplete understanding of Scrum, which was made whole by taking a great CSM course, and then strengthened through practice and learning. I’m excited to see how this journey unfolds. As I continue, I remind myself of the three things I referenced above: 1) throw out the buzzwords, 2) be “agile” not Agile, and 3) don’t give up on servant leadership.

What do you think? Leave a comment if you have an insight you’d like to share.