The year was 1995, and Quentin Tarantino’s Pulp Fiction wasn’t the only chaotic thing shaking up the world. Javascript had just hit the scene and everyone in the software development industry was frantically trying to build things as quickly as possible, mostly leaving process to happenstance. At best, any attempt to build faster was ineffective. At worst, it was counterproductive.
After five years of witnessing antipattern after antipattern emerge, Ken Schwaber and Jeff Sutherland unveiled a new approach to developing products that promised to end those woes.
We all know it today as Scrum.
Sounds utopian doesn’t it?
With so much disorder, the industry clung to this beacon of structure. But like any utopian ideal, it bred a group of people adhering to an extreme. We call them “Scrum Purists,” or those who have a very rigid, if not puritanical way of applying the Scrum methodology.
Take The Scrum Alliance, for example. They lay out the framework as follows:
The Roles: Scrum Master, Development Team, and Product Owner
The Ceremonies: Sprints, Daily Scrums, and Retrospectives
The Artifacts: Product and Sprint Backlogs
They go on to say, “If the team were to remove or alter any of these components, they are no longer using Scrum. Scrum exists only in its entirety.” In other words, it’s all or bust.
Here’s the irony: Most engineering and product development leaders today find that this all-or-nothing philosophy actually strips the innovation process of its flexibility and agility, slowing down the very thing Ken and Jeff were trying to speed up in the first place. Scrum has become a modern day antipattern. It’s largely process for process’s sake, instead of the thing we all really want it to be — a method for delivering high impact outcomes, faster.
Breaking Free from Scrum Purists
When we asked our community of experts to weigh in on why religious adherence to Scrum has become ineffective, we were met with a unanimous response: Scrum purists over-index on status reporting to the Scrum Master.
We spoke with three experts who explain why having a Scrum Master is counterproductive.
About the Experts
In our conversations, we dug into:
Why does a Scrum Master fail at driving quality and speed?
What is a Scrum Master actually trying to solve for?
What is a better solution to these problems?
We’ll tackle these questions in this article.
Why do Scrum Masters fail?
At a time when there was no real process at all, it would make sense that Jeff and Ken would want to implement a system that stopped teams from cutting corners when it came to prioritizing and executing key tasks and creating a culture of constant communication.
In theory, having a Scrum Master doesn’t sound half bad: Who doesn’t want someone to proactively help teams resolve bottlenecks and keep things on track in an organized, timely manner?
In practice though, what actually plays out is that the Scrum Master — having no real technical expertise and no real sway or influence over the team and their direction — ends up just slowing down development by adding superfluous layers to the process.
The big drawback is they’re diligently reporting everything. The status reports are as accurate as you’d ever want them to be. But who cares? The only thing we care about is how do we move the product forward faster? There’s an overfixation on reporting, and not enough fixation on creative solutions you’re supposed to be solving.
– Sachin Rekhi, Founder/CEO of Notejoy
When the focus becomes reporting, it’s easy to lose sight of the end product goal.
“Adhering to the process religiously tends to get people into this process over outcomes mindset, where they’re focused on the process and not what they’re actually trying to achieve with the process.”
— Ely Lerner, former Head of Consumer Product at Chime
What are Scrum Masters Trying to Solve for?
If we take a step back and break down what a Scrum Master is actually trying to solve for, we can categorize it into four buckets:
Project management
Bottleneck busting
Transparent and constant communication
Accountability
Let’s deep dive into each of these concepts and explore how the purist would tackle them versus how our experts think through these responsibilities.
Project Management
Prioritization largely belongs to the Product Manager, but then you need someone to plan out the sprint realistically and keep track of the progress.
Scrum Purist: Prescribes a Scrum Master for the job.
Reforge Experts: Project management should be part of an Engineering Manager or Senior IC’s role.
Tackling Big, Hairy Problems with Sprints
Sprint planning requires teams to break down big, hairy problems into a set of smaller tasks. Sachin points out that because Scrum Masters are not versed in the technical problems engineers are working on, they can’t accurately do that breakdown, let alone effectively improve this process. Instead, they just end up playing a sit-listen-and-write-down role, without providing much value.
Estimation
Estimation is another valuable skill promoted by Scrum, but individual engineers can only improve their accuracy if they’re given guidance by someone more senior with the experience and knowledge around how long something is going to take.
One example from Sachin: An IC developer might estimate one week to accomplish a specific task. If a more experienced engineer is running the sprint planning meeting, they might notice that this IC didn’t account for a specific set of subtasks associated with the umbrella task.
This subset of tasks may take a few more days to complete. Knowing this, the more experienced engineer can encourage that IC to factor those subtasks into their estimation. The Scrum Master wouldn’t be equipped to give this guidance and improve estimation accuracy because again, they lack the technical know-how.
Matt emphasizes that more so than just being unable to provide the right guidance to improve estimation, Scrum Masters over-index on making sure the individual contributors get their estimation right on the next iteration or sprint.
“Do you want to be great at estimation or do you want to be great at shipping high quality software? Both take time and energy. The focus should be on getting the work done.”
— Matt Marenghi, former VP of Engineering at Netflix
Should Engineering Managers play Scrum Master?
Sachin advocates for the Engineering Manager to instead play this role. To effectively play the role of project manager, you need someone who is going to be able to both keep the team on track because they understand the amount of time the tasks at hand require, but they can also shield the team from over committing, providing for a more realistic sprint. He believes Engineering Managers have both the technical know how and authority to protect the team from unrealistic timelines or requests.
He says, for example, this may play out where a Product Manager wants things done yesterday, and, naturally, a beholden engineering team may try to meet the request. In this instance, a Scrum Master would not have the influence to push back. An Engineering Manager, on the other hand, would have the ability to give authoritative weight to the accuracy of the engineer team's estimates, which then gives the sprint plan an impactful dose of reality.
Matt, Ely, and Sachin also see a scenario in which a senior IC looking to gain managerial experience could effectively fulfill this role as well. Allowing an individual contributor to take on project management responsibilities provides a solid growth opportunity for them beyond the primary focus of development, architecture, and implementation.
Bottleneck Busting
It’s no secret that development teams need to break through challenging bottlenecks.
Scrum Purists: Task the Scrum Master with identifying and resolving both process and tradeoff issues.
Reforge Experts: Technical expertise and a deep understanding of customer problems is essential for identifying creative solutions or trade-offs effectively.
Facing Trade-Offs Requires Technical Know-How
Imagine your team is faced with making a tradeoff between two features. From his experiences at various organizations of all sizes, Sachin feels it’s best to have someone who:
Is in tune with customer sentiment
Understands these customer tradeoffs
Has the technical expertise to effectively break through this blocker
Having someone who isn't equipped with deep customer insight and technical know-how, like the Scrum Master, isn’t helpful because they aren’t adding any ingenuity value or impact. Rarely does a Scrum Master verse themself in customer problems and needs. And why spend time getting the Scrum Master up to speed on customer insights when you already have a Product Manager or Engineering Manager for that? It becomes another layer in getting the product moving forward, faster.
Ely adds another common scenario that engineering teams face. An IC developer will be waiting on something passively before they move on with the project they’re tasked with because they’re unaware that there’s an active action that can be taken. A senior engineer serving as a project lead would be able to see that gap and provide the clarity to keep the ball rolling. A random Scrum Master would not have the technical expertise to recognize this opportunity to speed things up.
Process Flexibility and Agility
Adding to this inability to break down bottlenecks is the Scrum Master’s religious adherence to Scrum itself. Sachin, Matt, and Ely say this strict adherence is what doesn’t allow Scrum Masters to be flexible or adaptable because they aren’t keen on changing processes. Their default is to follow what scrum dictates without question, when that’s not the point.
Instead, the point is to discover and pinpoint the process that works best for your team or improving those processes. The focus should be actively and creatively thinking about new processes or alternatives that are going to resolve the issues your team is facing, not policing team’s back into scrum.
Sure, it’s not ideal for developers to be in a constant state of thrash, and sticking to the plan of attack during a two-week sprint can have experimental value. However, Ely stresses that what’s really important isn’t “sticking to the code” because Scrum says so; it’s having intentional discussions about trade-offs rooted in outcomes.
Scrum Master’s may be equipped to facilitate those conversations, but they’re not adding much value to those conversations nor are they in a position to enact change once those conversations are had.
**Matt **seconds this train of thought. He says there needs to be a cultural understanding that generally these estimates to get something done by a certain date could be way off, that potentially it could take twice as long to build the thing after it gets refined. If you have a date driven culture, where the goal is always to get something out by a specific date, you fall into the trap of pruning the scope unrealistically, lose the agility to pivot, and derail focus from the real goal of delivering high impact outcomes.
“When teams start allowing the date to dictate the way they operate, it’s a little like the tail wagging the dog. It comes down to company culture and everybody involved understanding that things do change. If we learn that the task is way more complex than we thought and we need to build something first for us to be able to achieve our initial goal, we shouldn’t look at it like we’re behind schedule. We should accept it and see it as an impactful learning that allows us to reset and go forward with the new information.”
— Matt Marenghi, former Vice President of Engineering at Netflix
Driving Progress Should be the Focus of Daily Stand-Ups and Sprints
Let’s think about it through the lens of the daily stand-up that the Scrum Master is responsible for facilitating. Sachin says if you’re not actively solving for how the team can stay on track or get back on track for what they set out to accomplish in that daily stand-up, then even that 15 minutes is wasted. And yet, Scrum Masters tend to utilize the daily stand-up for a status update read-out rather than an arena to bust through bottlenecks.
“To assess how you’re doing on timeline and to resolve with creative solutions how to get back on timeline is the only reason to do a daily stand-up. Unfortunately, a lot of people never get there because they don’t have someone facilitating who has the ability to do these things. You need someone who is technical enough to come up with these solutions.”
– Sachin Rekhi, Founder/CEO of Notejoy
We can even think about it through the lens of a two-week sprint. Matt adds that two-week sprints aren’t always the best solution for quicker turnaround — especially in today’s reality where typical software undergoes continuous integration and deployment, and teams are constantly refining things throughout the day. It’s a very different reality than the one from the late 90s and early 2000s.
With the new way of the world, it’s not that the work a Scrum Master does isn’t valuable, but** it’s more valuable when it’s performed by someone who’s embedded within the team and has the ongoing daily context of the project**, rather than someone who does the role as a bit of an outsider.
Should Engineering Managers play Scrum Master?
When it comes to bulldozing through those bottlenecks, Sachin advocates for the Engineering Manager to play the role of the Scrum Master because they have the authority to be a shot caller. Not only can they help identify what went wrong and how to solve for it going forward, but they’re also in a place of authority to enact change. They have the decision-making power to implement the discovered solutions.
Furthermore, it’s already a part of their job to enhance processes within the team and to work closely with the product manager. Why hire a separate Scrum Master to try to do the same thing?
“It’s this combination of 1) technical know-how, 2) the ability to call it like it is because you’re in a leadership position, and 3) successful mentoring and coaching that’s rooted in experience that I find why it’s most useful to have the engineering manager play this role.”
– Sachin Rekhi, Founder/CEO of Notejoy
**Matt **has a slightly different perspective. Bottleneck busting doesn’t belong to just one person. It belongs in the hands of close knit product and engineering teams.
“The teams that I’ve seen work the best are where the product manager is really close and embedded with the engineering teams. A Scrum Master can be an [interfering] layer between the product owner and the implementation teams.”
– Matt Marenghi, former Vice President of Engineering at Netflix
Transparent and Constant Communication
The origin of a daily stand-up, or daily scrum, lies in its intention to foster a culture of constant and transparent communication and reflection — an admirable concept we can all probably agree is best for teams.
Scrum Purists: A Scrum Master should lead a daily 15 minute meeting for the development team to synchronize activities.
Reforge Experts: Develop and customize an operating rhythm that combines async collaboration and context sharing tools with bottleneck busting meetings.
Daily Stand-Ups in a World of Async Collaboration Tools
In 1995, tools like Slack, Zoom, Google Docs (and many other collaboration tools we take for granted today) weren’t around. As such, it makes sense that Ken and Jeff believed having a Scrum Master around to diligently ensure these discussion touchpoints weren’t being bypassed was important.
But in today’s world, async collaboration tools have largely replaced the need for in-person status updates, keeping everyone in the loop without the need for a meeting. Especially since Scrum Masters, over time, lost sight of what was important for these meetings — bottleneck busting — and began over indexing on reporting every single update to a backlog during the stand-up.
Nowadays, with the help of these tools, not only are there daily touchpoints, but multiple touchpoints throughout the day. It’s not a bad idea to hold daily stand-up meetings for bottleneck busting, but only if it makes sense for the flow and productivity of your team, not because the Scrum Master said so.
The Power of Context Sharing
Matt reminds us not to overlook the power of context sharing when creating a culture of transparency and constant communication. Timely context sharing allows people to solve many blockers on their own, whether it be in the form of a shared document or in the form of a meeting announcement, largely because most blockers are rooted in a missing piece of the puzzle that new information or context provides.
“At Netflix, the default was to have every document fully open to the company and everyone felt empowered to chime in with comments or questions. Timely communication wasn’t just about Slack, it came largely in the form of document commenting as well. It was an incredibly effective way of resolving issues.”
– Matt Marenghi, former Vice President of Engineering at Netflix
Should Engineering Managers play Scrum Master?
Engineering managers tend to be more cross-functional than individual contributors, allowing them to provide more context to teams more easily. However, Matt cautions that it shouldn’t always be an authority figure because then there’s an implied hierarchy when you want your team members to feel a sense of ownership and accountability.
Accountability and Self-Ownership
Let’s be frank, creating accountability loops with self-ownership is better than just doing something because your boss tells you to. It creates a drive in engineers to deliver their best work in the allotted time they’ve self-committed to. It’s why Scrum advises teams to appoint a Scrum Master. The idea is that it stimulates this accountability because the drive is no longer coming from a place of obligation to an authoritative figure or manager.
Scrum Purists: Appoint a Scrum Master, aka someone who isn’t a manager or doesn’t have direct authority, corralling people to sign up and estimate for their own tasks.
Reforge Experts: Put the responsibility of ticketing back in the hands of the individual engineers and empower them to own and report on their own tasks.
However, in practice this largely fails at creating that accountability loop and sense of self-ownership because Scrum Masters tend to take on the placement of tickets for the engineers.
Sachin says when you remove all project management responsibilities away from the engineer, you remove their level of ownership. For him, the ideal is to allow ICs to fill out their own tickets, estimate their own timespans, and sign-up for their own tasks — all with the coaching and mentorship of an Engineering Manager. Adding an outside Scrum Master just adds an unnecessary layer to getting things done faster.
Ely reminds us of the importance of aligning your team on the why of the task they’re performing. If developers don’t understand the why and its critical outcomes, they can’t effectively offer recommendations to the discussion around trade-offs.
Instead, they end up just taking orders. By arming your team with the why and asking them the right questions to steer those trade-off discussions toward the desired outcomes, you establish a sense of ownership in your team, which can be a motivating force in the speed and quality of your product.
Another way to invigorate your team is to encourage healthy competition amongst your developers. Sachin recalls a time when he motivated his developers to close down as many tickets as possible when the team was over indexing on delivering robust, scalable code.
By publicly rewarding ticket-closers with praise at team syncs, he signaled that this was an outcome he wanted the team to opt for and the team read him loud and clear. If a Scrum Master attempted to do the same thing, the same vigor to impress this person would not carry the same weight as someone with authority.
Scrum Master is a Shared Hat, Not a Single Person
After talking to our experts, the key takeaway is that the work Scrum Masters are responsible for is valuable, but it’s most valuable when it’s performed by an engineering and product development team member who is deeply embedded in the work.
We embarked on this journey to break down the myth that hiring a Scrum Master — or learning how to become a Scrum Master yourself — is the key to delivering high impact outcomes faster.
What we found in our discussions with our experts is that the Scrum Master is less of a person, and more of a hat — a hat that can be worn by one or various team members within the engineering and product development team, customized to fit the unique needs, project problems, and culture of that team. You don’t need a Scrum Master certification to do that.
In a rapidly changing product world with the constant emergence of new tools and working norms, we implore you to avoid process for process’ sake. Instead, focus on what it takes to deliver high quality and impact, faster.
The year was 1995, and Quentin Tarantino’s Pulp Fiction wasn’t the only chaotic thing shaking up the world. Javascript had just hit the scene and everyone in the software development industry was frantically trying to build things as quickly as possible, mostly leaving process to happenstance. At best, any attempt to build faster was ineffective. At worst, it was counterproductive.
After five years of witnessing antipattern after antipattern emerge, Ken Schwaber and Jeff Sutherland unveiled a new approach to developing products that promised to end those woes.
We all know it today as Scrum.
Sounds utopian doesn’t it?
With so much disorder, the industry clung to this beacon of structure. But like any utopian ideal, it bred a group of people adhering to an extreme. We call them “Scrum Purists,” or those who have a very rigid, if not puritanical way of applying the Scrum methodology.
Take The Scrum Alliance, for example. They lay out the framework as follows:
The Roles: Scrum Master, Development Team, and Product Owner
The Ceremonies: Sprints, Daily Scrums, and Retrospectives
The Artifacts: Product and Sprint Backlogs
They go on to say, “If the team were to remove or alter any of these components, they are no longer using Scrum. Scrum exists only in its entirety.” In other words, it’s all or bust.
Here’s the irony: Most engineering and product development leaders today find that this all-or-nothing philosophy actually strips the innovation process of its flexibility and agility, slowing down the very thing Ken and Jeff were trying to speed up in the first place. Scrum has become a modern day antipattern. It’s largely process for process’s sake, instead of the thing we all really want it to be — a method for delivering high impact outcomes, faster.
Breaking Free from Scrum Purists
When we asked our community of experts to weigh in on why religious adherence to Scrum has become ineffective, we were met with a unanimous response: Scrum purists over-index on status reporting to the Scrum Master.
We spoke with three experts who explain why having a Scrum Master is counterproductive.
About the Experts
In our conversations, we dug into:
Why does a Scrum Master fail at driving quality and speed?
What is a Scrum Master actually trying to solve for?
What is a better solution to these problems?
We’ll tackle these questions in this article.
Why do Scrum Masters fail?
At a time when there was no real process at all, it would make sense that Jeff and Ken would want to implement a system that stopped teams from cutting corners when it came to prioritizing and executing key tasks and creating a culture of constant communication.
In theory, having a Scrum Master doesn’t sound half bad: Who doesn’t want someone to proactively help teams resolve bottlenecks and keep things on track in an organized, timely manner?
In practice though, what actually plays out is that the Scrum Master — having no real technical expertise and no real sway or influence over the team and their direction — ends up just slowing down development by adding superfluous layers to the process.
The big drawback is they’re diligently reporting everything. The status reports are as accurate as you’d ever want them to be. But who cares? The only thing we care about is how do we move the product forward faster? There’s an overfixation on reporting, and not enough fixation on creative solutions you’re supposed to be solving.
– Sachin Rekhi, Founder/CEO of Notejoy
When the focus becomes reporting, it’s easy to lose sight of the end product goal.
“Adhering to the process religiously tends to get people into this process over outcomes mindset, where they’re focused on the process and not what they’re actually trying to achieve with the process.”
— Ely Lerner, former Head of Consumer Product at Chime
What are Scrum Masters Trying to Solve for?
If we take a step back and break down what a Scrum Master is actually trying to solve for, we can categorize it into four buckets:
Project management
Bottleneck busting
Transparent and constant communication
Accountability
Let’s deep dive into each of these concepts and explore how the purist would tackle them versus how our experts think through these responsibilities.
Project Management
Prioritization largely belongs to the Product Manager, but then you need someone to plan out the sprint realistically and keep track of the progress.
Scrum Purist: Prescribes a Scrum Master for the job.
Reforge Experts: Project management should be part of an Engineering Manager or Senior IC’s role.
Tackling Big, Hairy Problems with Sprints
Sprint planning requires teams to break down big, hairy problems into a set of smaller tasks. Sachin points out that because Scrum Masters are not versed in the technical problems engineers are working on, they can’t accurately do that breakdown, let alone effectively improve this process. Instead, they just end up playing a sit-listen-and-write-down role, without providing much value.
Estimation
Estimation is another valuable skill promoted by Scrum, but individual engineers can only improve their accuracy if they’re given guidance by someone more senior with the experience and knowledge around how long something is going to take.
One example from Sachin: An IC developer might estimate one week to accomplish a specific task. If a more experienced engineer is running the sprint planning meeting, they might notice that this IC didn’t account for a specific set of subtasks associated with the umbrella task.
This subset of tasks may take a few more days to complete. Knowing this, the more experienced engineer can encourage that IC to factor those subtasks into their estimation. The Scrum Master wouldn’t be equipped to give this guidance and improve estimation accuracy because again, they lack the technical know-how.
Matt emphasizes that more so than just being unable to provide the right guidance to improve estimation, Scrum Masters over-index on making sure the individual contributors get their estimation right on the next iteration or sprint.
“Do you want to be great at estimation or do you want to be great at shipping high quality software? Both take time and energy. The focus should be on getting the work done.”
— Matt Marenghi, former VP of Engineering at Netflix
Should Engineering Managers play Scrum Master?
Sachin advocates for the Engineering Manager to instead play this role. To effectively play the role of project manager, you need someone who is going to be able to both keep the team on track because they understand the amount of time the tasks at hand require, but they can also shield the team from over committing, providing for a more realistic sprint. He believes Engineering Managers have both the technical know how and authority to protect the team from unrealistic timelines or requests.
He says, for example, this may play out where a Product Manager wants things done yesterday, and, naturally, a beholden engineering team may try to meet the request. In this instance, a Scrum Master would not have the influence to push back. An Engineering Manager, on the other hand, would have the ability to give authoritative weight to the accuracy of the engineer team's estimates, which then gives the sprint plan an impactful dose of reality.
Matt, Ely, and Sachin also see a scenario in which a senior IC looking to gain managerial experience could effectively fulfill this role as well. Allowing an individual contributor to take on project management responsibilities provides a solid growth opportunity for them beyond the primary focus of development, architecture, and implementation.
Bottleneck Busting
It’s no secret that development teams need to break through challenging bottlenecks.
Scrum Purists: Task the Scrum Master with identifying and resolving both process and tradeoff issues.
Reforge Experts: Technical expertise and a deep understanding of customer problems is essential for identifying creative solutions or trade-offs effectively.
Facing Trade-Offs Requires Technical Know-How
Imagine your team is faced with making a tradeoff between two features. From his experiences at various organizations of all sizes, Sachin feels it’s best to have someone who:
Is in tune with customer sentiment
Understands these customer tradeoffs
Has the technical expertise to effectively break through this blocker
Having someone who isn't equipped with deep customer insight and technical know-how, like the Scrum Master, isn’t helpful because they aren’t adding any ingenuity value or impact. Rarely does a Scrum Master verse themself in customer problems and needs. And why spend time getting the Scrum Master up to speed on customer insights when you already have a Product Manager or Engineering Manager for that? It becomes another layer in getting the product moving forward, faster.
Ely adds another common scenario that engineering teams face. An IC developer will be waiting on something passively before they move on with the project they’re tasked with because they’re unaware that there’s an active action that can be taken. A senior engineer serving as a project lead would be able to see that gap and provide the clarity to keep the ball rolling. A random Scrum Master would not have the technical expertise to recognize this opportunity to speed things up.
Process Flexibility and Agility
Adding to this inability to break down bottlenecks is the Scrum Master’s religious adherence to Scrum itself. Sachin, Matt, and Ely say this strict adherence is what doesn’t allow Scrum Masters to be flexible or adaptable because they aren’t keen on changing processes. Their default is to follow what scrum dictates without question, when that’s not the point.
Instead, the point is to discover and pinpoint the process that works best for your team or improving those processes. The focus should be actively and creatively thinking about new processes or alternatives that are going to resolve the issues your team is facing, not policing team’s back into scrum.
Sure, it’s not ideal for developers to be in a constant state of thrash, and sticking to the plan of attack during a two-week sprint can have experimental value. However, Ely stresses that what’s really important isn’t “sticking to the code” because Scrum says so; it’s having intentional discussions about trade-offs rooted in outcomes.
Scrum Master’s may be equipped to facilitate those conversations, but they’re not adding much value to those conversations nor are they in a position to enact change once those conversations are had.
**Matt **seconds this train of thought. He says there needs to be a cultural understanding that generally these estimates to get something done by a certain date could be way off, that potentially it could take twice as long to build the thing after it gets refined. If you have a date driven culture, where the goal is always to get something out by a specific date, you fall into the trap of pruning the scope unrealistically, lose the agility to pivot, and derail focus from the real goal of delivering high impact outcomes.
“When teams start allowing the date to dictate the way they operate, it’s a little like the tail wagging the dog. It comes down to company culture and everybody involved understanding that things do change. If we learn that the task is way more complex than we thought and we need to build something first for us to be able to achieve our initial goal, we shouldn’t look at it like we’re behind schedule. We should accept it and see it as an impactful learning that allows us to reset and go forward with the new information.”
— Matt Marenghi, former Vice President of Engineering at Netflix
Driving Progress Should be the Focus of Daily Stand-Ups and Sprints
Let’s think about it through the lens of the daily stand-up that the Scrum Master is responsible for facilitating. Sachin says if you’re not actively solving for how the team can stay on track or get back on track for what they set out to accomplish in that daily stand-up, then even that 15 minutes is wasted. And yet, Scrum Masters tend to utilize the daily stand-up for a status update read-out rather than an arena to bust through bottlenecks.
“To assess how you’re doing on timeline and to resolve with creative solutions how to get back on timeline is the only reason to do a daily stand-up. Unfortunately, a lot of people never get there because they don’t have someone facilitating who has the ability to do these things. You need someone who is technical enough to come up with these solutions.”
– Sachin Rekhi, Founder/CEO of Notejoy
We can even think about it through the lens of a two-week sprint. Matt adds that two-week sprints aren’t always the best solution for quicker turnaround — especially in today’s reality where typical software undergoes continuous integration and deployment, and teams are constantly refining things throughout the day. It’s a very different reality than the one from the late 90s and early 2000s.
With the new way of the world, it’s not that the work a Scrum Master does isn’t valuable, but** it’s more valuable when it’s performed by someone who’s embedded within the team and has the ongoing daily context of the project**, rather than someone who does the role as a bit of an outsider.
Should Engineering Managers play Scrum Master?
When it comes to bulldozing through those bottlenecks, Sachin advocates for the Engineering Manager to play the role of the Scrum Master because they have the authority to be a shot caller. Not only can they help identify what went wrong and how to solve for it going forward, but they’re also in a place of authority to enact change. They have the decision-making power to implement the discovered solutions.
Furthermore, it’s already a part of their job to enhance processes within the team and to work closely with the product manager. Why hire a separate Scrum Master to try to do the same thing?
“It’s this combination of 1) technical know-how, 2) the ability to call it like it is because you’re in a leadership position, and 3) successful mentoring and coaching that’s rooted in experience that I find why it’s most useful to have the engineering manager play this role.”
– Sachin Rekhi, Founder/CEO of Notejoy
**Matt **has a slightly different perspective. Bottleneck busting doesn’t belong to just one person. It belongs in the hands of close knit product and engineering teams.
“The teams that I’ve seen work the best are where the product manager is really close and embedded with the engineering teams. A Scrum Master can be an [interfering] layer between the product owner and the implementation teams.”
– Matt Marenghi, former Vice President of Engineering at Netflix
Transparent and Constant Communication
The origin of a daily stand-up, or daily scrum, lies in its intention to foster a culture of constant and transparent communication and reflection — an admirable concept we can all probably agree is best for teams.
Scrum Purists: A Scrum Master should lead a daily 15 minute meeting for the development team to synchronize activities.
Reforge Experts: Develop and customize an operating rhythm that combines async collaboration and context sharing tools with bottleneck busting meetings.
Daily Stand-Ups in a World of Async Collaboration Tools
In 1995, tools like Slack, Zoom, Google Docs (and many other collaboration tools we take for granted today) weren’t around. As such, it makes sense that Ken and Jeff believed having a Scrum Master around to diligently ensure these discussion touchpoints weren’t being bypassed was important.
But in today’s world, async collaboration tools have largely replaced the need for in-person status updates, keeping everyone in the loop without the need for a meeting. Especially since Scrum Masters, over time, lost sight of what was important for these meetings — bottleneck busting — and began over indexing on reporting every single update to a backlog during the stand-up.
Nowadays, with the help of these tools, not only are there daily touchpoints, but multiple touchpoints throughout the day. It’s not a bad idea to hold daily stand-up meetings for bottleneck busting, but only if it makes sense for the flow and productivity of your team, not because the Scrum Master said so.
The Power of Context Sharing
Matt reminds us not to overlook the power of context sharing when creating a culture of transparency and constant communication. Timely context sharing allows people to solve many blockers on their own, whether it be in the form of a shared document or in the form of a meeting announcement, largely because most blockers are rooted in a missing piece of the puzzle that new information or context provides.
“At Netflix, the default was to have every document fully open to the company and everyone felt empowered to chime in with comments or questions. Timely communication wasn’t just about Slack, it came largely in the form of document commenting as well. It was an incredibly effective way of resolving issues.”
– Matt Marenghi, former Vice President of Engineering at Netflix
Should Engineering Managers play Scrum Master?
Engineering managers tend to be more cross-functional than individual contributors, allowing them to provide more context to teams more easily. However, Matt cautions that it shouldn’t always be an authority figure because then there’s an implied hierarchy when you want your team members to feel a sense of ownership and accountability.
Accountability and Self-Ownership
Let’s be frank, creating accountability loops with self-ownership is better than just doing something because your boss tells you to. It creates a drive in engineers to deliver their best work in the allotted time they’ve self-committed to. It’s why Scrum advises teams to appoint a Scrum Master. The idea is that it stimulates this accountability because the drive is no longer coming from a place of obligation to an authoritative figure or manager.
Scrum Purists: Appoint a Scrum Master, aka someone who isn’t a manager or doesn’t have direct authority, corralling people to sign up and estimate for their own tasks.
Reforge Experts: Put the responsibility of ticketing back in the hands of the individual engineers and empower them to own and report on their own tasks.
However, in practice this largely fails at creating that accountability loop and sense of self-ownership because Scrum Masters tend to take on the placement of tickets for the engineers.
Sachin says when you remove all project management responsibilities away from the engineer, you remove their level of ownership. For him, the ideal is to allow ICs to fill out their own tickets, estimate their own timespans, and sign-up for their own tasks — all with the coaching and mentorship of an Engineering Manager. Adding an outside Scrum Master just adds an unnecessary layer to getting things done faster.
Ely reminds us of the importance of aligning your team on the why of the task they’re performing. If developers don’t understand the why and its critical outcomes, they can’t effectively offer recommendations to the discussion around trade-offs.
Instead, they end up just taking orders. By arming your team with the why and asking them the right questions to steer those trade-off discussions toward the desired outcomes, you establish a sense of ownership in your team, which can be a motivating force in the speed and quality of your product.
Another way to invigorate your team is to encourage healthy competition amongst your developers. Sachin recalls a time when he motivated his developers to close down as many tickets as possible when the team was over indexing on delivering robust, scalable code.
By publicly rewarding ticket-closers with praise at team syncs, he signaled that this was an outcome he wanted the team to opt for and the team read him loud and clear. If a Scrum Master attempted to do the same thing, the same vigor to impress this person would not carry the same weight as someone with authority.
Scrum Master is a Shared Hat, Not a Single Person
After talking to our experts, the key takeaway is that the work Scrum Masters are responsible for is valuable, but it’s most valuable when it’s performed by an engineering and product development team member who is deeply embedded in the work.
We embarked on this journey to break down the myth that hiring a Scrum Master — or learning how to become a Scrum Master yourself — is the key to delivering high impact outcomes faster.
What we found in our discussions with our experts is that the Scrum Master is less of a person, and more of a hat — a hat that can be worn by one or various team members within the engineering and product development team, customized to fit the unique needs, project problems, and culture of that team. You don’t need a Scrum Master certification to do that.
In a rapidly changing product world with the constant emergence of new tools and working norms, we implore you to avoid process for process’ sake. Instead, focus on what it takes to deliver high quality and impact, faster.