Tales of a growing Scrum Master: breaking through the surface layer

I'd like to share with you a story: an engineer who became a Scrum Master because one was needed, and then became a better Scrum Master because one was needed. I am very curious what my fellow Scrummers think of my perspectives.

Two years ago I was hired as a developer in an “ops-y” pipeline team. Although the team was convinced it was Scrumming, it had apparently bought into a common myth: “Scrum is a set of best practices and you cherry-pick from it what is relevant to your work environment.” The team had (most notably):

- Not seen its Scrum Master in months.

- Chosen to drop the idea of a recurring sprint cycle, planning, retro and review ceremonies.

- Not maintained a product backlog at all.

- Dismissed the idea of a Definition of Done.

After all, there were too many unpredictable support requests and panic-y production issues for all that to be applicable! We were firefighters first, pipeline developers second! Nothing had changed in the last couple of months, conflicts about approaches were frequent, and my new teammates seemed unhappy.

Coming from a dev role in a highly disciplined Scrum team and knowing the Guide from studying for my Professional Scrum Master 1 exam, I saw an opportunity to enthusiastically start scrum-mastering. Emphasizing timeboxing, helping the PO + team chop big vague stories to small refined ones, facilitating conflict resolution, teaching core elements of the Scrum framework… In other words: going by the book.

And it worked. Stories got better defined and “Done”, impasses and conflicts were resolved etc.. However like with exercising and dieting, the first advantages happen in the first few weeks or months, but then you hit that lull when you get used to a new status quo. So how does a Scrum Team break through the surface, instead of disappointedly concluding it’s just the umpteenth hollow buzzword circus? How do you change your lifestyle instead of just reshaping habits?

Like always, no silver bullet exists. It took a year for us to really let this sink in for us as a Scrum team. The key lies in diving into the questions of how to practice transparency, inspection and adaptation. Just going by the book helps to start getting in shape, but it certainly doesn’t do magic for your actual insights. Scrum, with its values and ceremonies, merely facilitates your growth and improvement. It requires putting more effort into extra work, tough decisions and difficult discussions to convince people to find ways to do things out of their barb-wired comfort zones.

So, we learned and we practiced. We started focusing on the Scrum values and the preferences in the Agile manifesto during our retrospectives and refinements. This inspired focus on workflows and value delivery instead of well-intended but ultimately confining work instructions. Rather than robotically asking ourselves The Three Questions and filling the Sprint Backlog to a calculated story point limit, we focused on Sprint Goals during standups and Sprint Planning meetings. Transparency and openness about the Product Backlog with stakeholders increased feedback quality and shared visions on product and value. We proudly pointed to our Definition of Done as a guarantee for quality. We tried to use problems as inspirations for change rather than collateral damage or things to blame on others. Rather than escalating impediments to the responsible people and chasing them to fix it, we worked to respect and trust other people’s intentions and commit to doing what we could do from our side. This in turn increased respect and trust that we received from others and willingness to collaborate. Most of all, we learned that we were just getting started.

It seems that those who somehow find their way to these rewarding insights find Scrum to be an extremely helpful Swiss army knife that facilitates continuously shaping and improving value delivery. Those who are still scratching that surface may not grasp the importance of all those chances for transparency, inspection and adaptation, much of it as unnecessary overhead and drop it, which (indeed) reduces the remainder to unnecessary overhead. We were lucky with a very committed team that was willing to keep trying new things and learning from its own history, and a management that kept trusting us during the time it took for us to learn all this.

As they say, easy to learn but hard to master. Come to think of it, doesn’t mastery (as in “Scrum Master”) imply completion, thereby risking complacency? Food for thought 😊

Keep scrumming!