I got fired for being a Scrum Master
And why it was the best thing that ever happened to me.
Once upon a time, I worked at a large corporate organization. It wasn’t rewarding by any means, but the long-standing company provided stability. I spent 14 years there as a front end engineer. During my final 3 years, I played the role of Scrum Master (SM), but with the management-imposed requirement that it only be a part-time responsibility for me.
The powers-that-be had decreed, “We’re going agile,” and like most large companies longing to dip their toes in Agile waters, Scrum was their weapon-of-choice. My department went through a 2-day Certified Scrum Master (CSM) class, and what our trainer said resonated with me. Everything made sense. Without knowing it, for years I’d longed for something like this. He’d described the a role as a Scrum Master.
When class ended, we got back to work, but nobody wanted to change. Not really. The company’s willingness to send us to training sold a promise, knowing full-well it’d be one that they’d never deliver upon. I felt like I’d been lied to; hoodwinked. As we struggled to implement Scrum, several of my managers even stated, “We’ll never have a Scrum Master role here.”
Sure, we worked in Sprints, held Sprint Retrospectives, refined our backlogs, and performed all the events you’re s’pose to when rolling with Scrum. But making real, impactful change wasn’t a priority. Commitment, courage, focus, openness, and respect were just words on a page. Teams weren’t trusted, given authority, or permission. As you’d expect, not much improved.
Like most folks, I’d received countless LinkedIn messages from recruiters— their modus operandi — over the years. I never considered answering the call though. This time however, when a recruiter message hit my inbox, it felt like kismet. Stars aligned, planets were in retrograde. The recruiter promised to deliver on my desire to do what I loved, and coaxed me away from my security blanket of a stable company. My career as a real-life Scrum Master had officially begun.
“It’s never too late to become who you want to be. I hope you live a life that you’re proud of, and if you find that you’re not, I hope you have the strength to start over.” — F. Scott Fitzgerald
I was placed at a medium-sized organization a little closer to my house. I loathe driving long distances in heavy traffic, especially for work, so it sweetened the deal. For the sake of this post, I’ll call the company Baguette Co. During my initial interview, they said that they followed Disciplined Agile (DA). At the time, I hadn’t heard of DA, but after some initial research, I figured that I had enough knowledge to at least know what to expect. Nevertheless, I was excited to start.
At first I merely observed. It didn’t take long for me to figure out that something was off at Baguette Co. First, my manager kept introducing me to everyone as the new project manager. My primary team consisted of three software developers, and two quality assurance engineers— which I found amazing since folks have a tendency to think of QA as an afterthought.
However, the team had consistently been asked (forced) to take on more work than humanly possible. It was commonplace for teams to work 60+ hours every week. Seemingly every process was manual. On top of that, QA kept being questioned why testing efforts took so long, and if they could “work faster.”
What felt like every Sprint, management asked me to cancel Sprint Reviews, and Retrospectives because “We don’t have time for those.” It’s a mentality that’s certainly not unique to Baguette Co., but it became clear that their notion of what constituted work was heads-down coding. In their eyes, anything outside of that was waste. Focusing on work-work-work, meeting deadlines as the only goal, not taking a breath to see how you’re doing, and not adjusting accordingly based on those assessments is a dangerous way of working.
I attempted to bring these behaviors to light by regularly asking questions:
- “We typically spin up conference calls at night in order to deploy to production. What are some ways we can we reduce manual processes?”
- “The team takes on work each Sprint, but they keep saying that it’s too much, and won’t finish. Is there a way we can negotiate a right-sized amount of work to help maintain a steady, consistent deliverable each iteration?”
- “Historically, we don’t give much consideration to QA during planning. What are some ways we can enable the team to focus on delivering quality, and minimizing defects?”
- If we don’t finish X, what breaks? How can we minimize that risk?
Nothing too off the wall. Fairly standard Scrum Master questions, right? Being an SM is an exercise in patience, persistence, and frustration. Calling out dysfunction is part of the gig. However, doing so can make folks uncomfortable, especially when their business-as-usual behavior is so deeply ingrained. Lemme be clear. Being a Scrum Master isn’t about being a PITA for the hell of it, but for the good of the organization; to help identify areas where we can do better.
I’d been at the gig for about 3–4 months, and I remember getting ready for work the day after New Years. After my usual routine of stopping at my neighborhood coffee shop, I headed into the office. 10 minutes into my daily drive, my phone rang. It was my recruiter. She said that Baguette Co. opted to terminate my contract, and that I shouldn’t to go into the office.
Happy New Year!
After the dust settled, I met with my recruiter, and she said that I probably should never have been placed there. Apparently, Baguette Co. was looking for a project manager who could take direction without rocking the boat. They didn’t want someone whose main focus was improvement, but opted for an SM due to the lack of interest in the posting. Baguette Co. stated that maybe Scrum wasn’t a good fit, and it might be better to revert back to “a more traditional project management style.”
It stung. I’d left the comfort, and stability of a company where I’d spent the last 14 years. I regretted my decision, and the dreaded impostor syndrome settled in, rearing its ugly head. But less than a week later, I’d been placed elsewhere; the technology department of a medium-sized healthcare organization. I remain there today. It’s here where I’ve been encouraged, given opportunities to flourish as a Scrum Master, and now as an Agile Coach. I’m fortunate to work with a group of SMs, and coaches who actually get it.
We used to roll with SAFe, but have since shifted to more of a continuous-planning model. It’s not perfect, but at least people keep thinking about how we can improve. Both Scrum, and Kanban teams are the norm, and leadership acknowledges the potential benefits for the organization.
Ultimately, getting fired was the best thing that happened to me. My experience at Baguette Co. helped tune my Agile BS detector. It gave me things to keep on my radar. There’s lots of information out there; some good, some bad. It can be difficult to distinguish one from the other, so it’s important to develop an acute Spider Sense. Sometimes it’s easy to spot. Alarm bells should be blaring when you come across job titles like Scrum Agile Master Coach/Trainer, or Lead Project Manager/Scrum Master (actual job titles I’ve been contacted about on LinkedIn).
Your ears should perk up when job descriptions, or responsibilities (again, from actual postings) include:
- “Assess priorities against business value to ensure epic release schedule is aligned to business priorities.”
- “The Scrum Master is responsible for management of assigned technical projects. The Scrum Master executes day-to-day management of project segments. In addition, the Scrum Master manages the group of projects as a whole, providing a single point of knowledge and control for the aggregate effort.”
Red flags like these might be telling you something. They could mean that organizations are really looking for project managers, haven’t really bought into Scrum, or be indicators of where they are in their evolution from traditional project management (a.k.a. Waterfall). If it’s your current spot, it could also mean it’s time to bounce.
I’d never advocate for Scrum Masters to quit if they find themselves in a similar situation. I get it. We’ve all got bills, and responsibilities. Who knows? Maybe you have an endless well of patience, and you’ll be the catalyst for impactful change in your organization. My time at Baguette Co. showed me otherwise. It opened my eyes. Getting fired showed me what could go wrong if you’re not the right fit. It gave me the experience to spot dysfunction, identify whether a potential employer will be the right place for me, and helped shaped my mindset. It’s a lens that I still use today.
A hard truth I had to learn was no matter how much blood, sweat, tears you put into an organization, it’ll still go on without you. I became a Scrum Master because it’s something I enjoy, and I wanted to be good at it. I changed my perspective. You gotta do what’s right for you.
“You look at the world one way and it’s filled with hatred, right? You look at it another, the same world’s filled with love, passion. Same worlds, it’s only the perspective that’s changed. “ — Emma Leaphorn, Coyote Waits by Tony Hillerman
Being fired was a scary, confusing time which evoked self-doubt. Looking back, it was the best thing that happened for my career. Not only did it open my eyes to what can go wrong when an organization weaponizes Scrum, but it also opened the door to other opportunities. Embracing the values that Scrum holds dear has the potential to make organizations better. If you’re a Scrum Master in that environment, it could have the same potential effect. Finding a place where you fit isn’t always easy, but sometimes it’s about understanding where you don’t.