Eugene has been at his first software development company for a little over a month, and his working his first job post-college. His manager set up their first one-on-one sit down...
"Hey Eugene, I'm checking in with you. You've been on our team for a month, and I really like your energy, you're really motivated!" -Eugene's Software Development Manager
"Thanks! I'm really happy for this opportunity. I've been learning a lot about Agileâ„¢ and our product these last two sprints." -Eugene
"The team is not going to daily stand-up on time and the team is not sticking to the 15 minute rule. We need a Scrum Master. Could I interest you in the opportunity of becoming the Scrum Master of the team? It's a great opportunity to grow."
"Yeah, this sounds amazing! What are my responsibilities?"
Little does the manager know, Eugene is excited that he won't have to code and will start framing his demeanor as a miniature manager and will update his LinkedIn immediately to say "Scrum Master" instead of "Associate Software Engineer" on his job title and will frame his duties like he's a manager.
Okay, okay... I'm off my rocker. I'm just being mean. However, I think the original intent of Scrum Master has been lost in the industry. As a matter of fact, I think the widespread implementation of the role has been a scam all along.
Honestly, I'm just an old man yelling at clouds.
A Historical Look at Scrum and the Scrum Framework
The Agile Proposal: In order for us to understand what a Scrum Master is supposed to do, we need to find out what Scrum is, and what these roles need to master. The term Scrum came from a paper in 1986 titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. This paper argues that the sequential development approach of the 1980s was too slow and not effective in a competitive business environment.
The Birth of Scrum Framework: These authors proposed that software development groups must embrace rapid prototyping, and focus on concurrent engineering (instead of sequential), while being rostered as cross-functional teams. Keep in mind that these authors states that cross-functionality is based on building teams that combine engineering, marketing, and manufacturing. Which would allow the development teams to test products more quickly, and refine products when they received feedback. It is important to note that this article only mentions Scrum once. It was a metaphor for improving product development processes by "moving the scrum downfield".
Oh yeah, Scrum is not an acronym either. How many times have you seen someone call it SCRUM. This is because Ken Schwaber, the co-write of The Scrum Guide made it capitalized. But it's still not an acronym... I don't get it.
The Scrum Team: The original work, The Scrum Guide, recommended three roles on the team.
The Product Owner: Essentially, The Product Owner is the voice of the customer and is responsible for delivering good business results. This role maintains the product backlog, and prioritizes the feature requests and defects in that backlog. The Product Owner cannot dictate how the team solves technical problems and should be customer-centric in their approach of guiding the team. This role defines and announces product releases, communicates delivery/product status, communicates risks, and keeps the backlog visible and up-to-date. There is only ever one Product Owner.
Developers: These dudes code shit and get shit done.
The Scrum Master: The purpose of this role is to facilitate the daily stand-up meeting. When not facilitating that meeting, this role is meant to remove impediments. It should be noted that this role is not a traditional Team Lead or Project Manager, but acts as a barrier between the team and distracting influences. The Scrum Master ensures that the Scrum Framework is followed by coaching the team in scrum theory. When not doing any of these, Scrum Masters can be used as meeting facilitators. This role has a few core responsibilities:
Helping product owner maintain backlog
Helping the team determine definition of done for the product
Coaches the team about Scrum principles
Educating key stakeholders and the rest of the organization on Scrum
Helping the Scrum team remove impediments
Promoting self-organization and cross-functionality within the team
Facilitating team events
Want to remove my impediments? Can you add source scanning to our CI/CD pipeline? We need that for the next release that you're trying to push us towards. While you're at it, can you fix the code coverage issues that are going to show up on the pipeline report? Thanks for being the master of Scrum.
I'm Just Going to Say it... The Scrum Master Role Proposal is a Scam
Look, if I wasn't so smooth brained, I'd create a framework and sell it to a bunch of companies, insert myself on the development teams to "coach" them, and charge them while they use my framework.
In order to sell a framework, you need to get buy-in from management, and from the developers. To get developer buy-in, just tell them things like: "all teams will be self-forming! you won't need a team lead unless you appoint them! if people are bothering you, a Scrum Master will exist to push them away!" All the engineers that aren't good at coding and have a bunch of soft skills can just do Product Owner roles, or train to be a Scrum Master.
However, what happens is that when management and finance realize that Scrum consultants cost a lot of money, they can't afford to have consultants placed on the team as Scrum Masters, so they fill in those positions. However... you can't put your best coders in those positions, because you need them to crank out code, so you end up putting new hires out of college. It's a tit-for-tat, because the manager fills a position but still can claim they're doing "Scrum", and the new engineer doesn't have to code and gets a title change (which they will use to ask for a raise later). Let's just stop this pattern.
Removing Impediments: Now, there might be engineers late in their career with plenty of knowledge that can actually coach. I usually consider them a Subject Matter Expert (SME), but if you wanted to make them a Scrum or a general process coach, and they're happy to fill that position, I'm all for it. However, when you take a younger engineer out of daily routine of coding, they won't be able to help you, because they will be out of touch and can't empathize with the engineers. Even worse, if you get someone to be your Scrum Master and they don't' know how to code at all, what kind of impediments can they remove? Some impediments might be "We have a critical defect on our backend service that needs to be triaged." Can the Scrum Master handle that?
My Beef With the Scrum Master Responsibilities
I've been a Scrum Master on two occasions, and for quite a bit of time. I do not think I've ever seen an effective use of the role. I have seen fantastic engineers try out the role of Scrum Master, and I have never really seen it improve their abilities. I think there are other ways for engineers to build their soft skills. Below are the responsibilities of Scrum Masters according to The Scrum Guide.
Help Product Owner Maintain Backlog: The Product Owner owns the backlog, how is this a responsibility? Why can't the developers help maintain the backlog too? Can you believe this is actually from the Scrum Framework?
Helping the Team Determine the Definition of Done: Why can the Product Owner not declare the Acceptance Criteria of closing the task/story/epic, and the team negotiates with the Product Owner, just like they negotiate with priority (like it says in The Scrum Guide?).
Coaches the Team About Scrum Principles: This is a consultant, meaning this will be a hefty cost. Unless this is a previous engineer with a lot of experience. However, this means a different track has to be created, but this keeps experienced engineers from management, technical leadership, etc. Who would do this that actually has great coding knowledge? While there may be some individuals, there won't be enough, which allows these individuals to charge a hefty cost per hour. That's when business and communications majors apply for this role, but those who don't understand software engineering will likely not be effective.
I genuinely believe this role was created for consultants to insert themselves in the development team to charge hefty fees.
Educating Key Stakeholders and the Rest of the Organization on Scrum: Sales people that advance the cause so they can get paid a technical engineering salary...
Helping the Scrum Team Remove Impediments: Want to help me remove impediments? Grab a laptop, a keyboard, get the latest JDK, and lets rumble. I'd rather have another software developer on my team than a fake Project Manager.
Promoting Self-Organization and Cross-Functionality within the Team: A team lead could be on the team, and if they promote "self-organization", then it is organization within the team. The teams cannot promote cross-functionality within the team. Generally, teams don't manage budget and they don't assign other employees under their managers. This is non-sensical unless it's a start-up company. If this is a start-up company, I'd prefer another developer than a Scrum Master.
Facilitating Team Events: Can we just self-facilitate? Lol... Just let a team lead facilitate, or ask a manager to do so. If not, just ask another developer from another team as a neutral party. You don't need to pay a consultant $500 an hour to do this...
It is Better to Grow Technical Leads in Your Organization
Okay, okay... Yes, this meme just says Senior Dev, but a Technical Lead should be a Senior Dev. Just sayin'.
Having a single technical lead that you grew within your organization, instead of a Product Owner and Scrum Master can be effective for growing junior developers in modern software engineering practices and in knowledge of in-house technologies. The technical lead can ensure that the team is focused on tasks that benefit the product. In terms of customer-centric, the technical lead can interact with customers, or can interact with Project/Product Managers, instead of a Product Owner.
Technical Leadership allows a growth plan for engineers that want to lead a team in product development, and allows software engineers to grow their skillsets. Having this engineer communicate with management and possibly customers can still protect the team from distractions. Technical leads are much more suited for removing roadblocks and impediments and with proper training from management can facilitate meetings as well. In the original Scrum Framework, there is no designated leader, and the framework proposes self-organizing teams to manage leadership, but I've seen this cause problems and factions within the team. Having a designated lead that is backed by the organization helps the team move forward.
Something, Something... I'm a Hypocrite
As much as I bash on the Scrum Framework, I still promote it through this site... lol. I'm still going to sign off the the super cringy Scrum questions. I probably should have offered more evidence and technical analysis, but screw that, I have some football to watch. I guess I've just had a bad beat in my career using extreme programming (XP), Kanban, agile methodologies, The Scrum Framework, Scaled Agile Framework (SAFe). It's easy to say "herp derp, no one did these right." But that's not the point, it's not like I know better, necessarily. These are all implementations on how to produce products faster and better. I think the problem is that with corporate environments, there will always be low performers that try
to find roles for themselves for self-preservation, and there will always be out-of-touch management that will try to fill the gaps of roles they don't understand.
Do this instead. Just think critically in your work environment. If you're a leader, talented engineers with potential need to do more of what they're doing to improve their skills, don't just put them on the path of learning soft skills immediately. Let the skilled coders do more coding, and find projects that accelerate their growth. On the other hand, if you're a software engineer with a Software Engineering or Computer Science degree, and you don't like coding... Well, first, why the hell did you get the degree? But, if you're not liking the path you are going, don't just jump to a role that has no future and no growth (Scrum Master). Instead, maybe find another field in your industry you might like, such as: data science, site reliability engineering, cloud engineering, etc.
What are your thoughts? Was I too harsh? Or, do you believe the Scrum Master role was devised so consultants could ensure engineering programs fully adopted their framework and pay those consultants fat royalties? Do you think the Scrum Master role is safe haven for developers that can't code? Or is it a pivotal role for teams to be agile? Also, what did you do yesterday? what are you doing today? Any roadblocks? *shivers*.