Are You Sick and Tired of Being an Agile Scrum Master?

Are you sick and tired of being an Agile Scrum Master? The standups, planning meetings, and retrospectives? Handling tasks that could be accomplished by administrative assistants (no offense to assistants). Taking on low level work because you are “removing impediments”? Trying to keep your standup 15 minutes when there is always that one person who wants to give a speech on solving the energy crisis? Facing pressure from management to be more “Agile” while facing pressure from management to provide a long-term Gantt Chart?

What about the burndown charts, user stories, points, and the like? And how about those Agile PMOs (Is that an oxymoron?)? Some companies have strict rules on what processes and tools teams must use to be Agile. I guess they missed that whole “individuals and interactions over processes and tools” thing.

These are some of the pains of being an Agile Scrum Master. It’s not an easy job, and sometimes it feels thankless. I know I should not complain but here me out. I’ve been in IT delivery over 20 years. The past 10 years leading software development projects. I've gone under various titles, including Scrum Master. My beef is not with Agile. To the contrary, I’m very much an advocate of Agile and lean iterative development. My issue is what the Agile Scrum Master role has become. When the Scrum Master role first appeared, it seemed like a cool evolution of the project manager. Now it feels more like a low-level facilitator.

How did we get to this point, where things like planning poker seem more important than delivering quality software? I blame a lot of it on Agile training. Once Agile gained popularity many were eager to sell it through trainings and certifications. To provide training, they put rigid definitions around Agile team roles and processes. The result? Certified Scrum Masters with little experience telling experienced technologists what to do. You could see how things could go wrong.

Somewhere along the way we lost sight of what’s important in the Agile Manifesto. Instead, we began focusing on specific frameworks and “by the book” agile practices learned in Agile courses. What your burn down chart or Scrum board looks like became more important than how your team collaborates.

I’ve worked with many senior developers who couldn’t care less about what they teach in Agile trainings. Yet, their actions and behaviors are more aligned with Agile principles than those who preach Scrum.

Here’s my conclusion. Each team should develop software in a manner that works best for them. If a team chooses to do "by the book" Scrum, and that works for them, great. If a team chooses to use traditional waterfall, and that works for them, fine. If a team uses a hybrid Agile and Waterfall approach, so be it.

What’s important is that teams work together in an authentic way, not in a way that’s faked to appease management. My only rule is that teams try to embrace Agile principles.

As for being an Agile Scrum Master? It’s time we embrace the fact that a leader of product development teams is much more than what they teach in Agile training. Whether called a Scrum Master, Project Manager, or something else, those who lead software teams need to be sharp and empathetic. The best of them understand that sometimes it’s best to break all the rules.

About the Author: Mike MacIsaac is a principal consultant for MacIsaac Consulting. MacIsaac Consulting, based out of Minneapolis MN, provides IT Agile and Digital Security Consulting.    

Follow @MikeMacIsaac or subscribe to the MacIsaac Consulting blog.