Do we need a Scrum Master forever?(tryscrum.com)
tryscrum.com
Do we need a Scrum Master forever?
https://www.tryscrum.com/blogs/do-we-need-a-scrum-master-forever/
65 comments
What is the problem that Agile attempts to solve?
That your organization is too siloed and ignorant of the what colleagues do to write proper requirements. And that your engineers are too ignorant and siloed to speak up when requirements aren't appropriate.
And more formality, rote obedience to procedure, and documentation are going to solve this?
Tl;dr - If your organizational culture is fucked up and not working, fix your organizational culture. There's not enough agile in the world to build on top of a cracked foundation.
That your organization is too siloed and ignorant of the what colleagues do to write proper requirements. And that your engineers are too ignorant and siloed to speak up when requirements aren't appropriate.
And more formality, rote obedience to procedure, and documentation are going to solve this?
Tl;dr - If your organizational culture is fucked up and not working, fix your organizational culture. There's not enough agile in the world to build on top of a cracked foundation.
Did anyone actually need a scrum master, ever?
Hot take, but if you're doing Scrum you sure do. A good Scrum master can make meetings much more productive.
Alternatively, agree to have an agenda for every meeting and then skip the scrum master.
Your dev team needs meetings? Sounds pretty disorganized.
Our team is productive, manages their time well, and communicates without meetings. Did anyone actually need a meeting, ever?
Our team is productive, manages their time well, and communicates without meetings. Did anyone actually need a meeting, ever?
My srcum master seems to think so.
On a perfect team, where everyone is great at time management, honest about productivity, has superb communication skills, and is enthusiastic/loves their tasks, yes, scrum is dumb. For but for the rest of us, the scrum master handles all the unpleasant organizational crap for the team, and thank god for them.
You can be quite far from perfect and not need it. And they quite commonly can amplify the disfunction in a team with issues.
This is made worse at a lot of companies by hiring the absolutely cheapest person for the role.
This is made worse at a lot of companies by hiring the absolutely cheapest person for the role.
Maybe not _need_ it, but it can help in a lot of cases. Though I have seen some cases of active resistance coming from participants, in which case toxic co-workers can really make the experience miserable.
This comes down to companies failing to fire people.
If someone is toxic to a team, they shouldn't remain at that company (much less on that team).
If someone is toxic to a team, they shouldn't remain at that company (much less on that team).
I've had a full time scrum master for, what, 4 months out of 15 years of doing scrum. It made a lot of positive difference to have someone operating on the meta level of the team.
I'm not sure if we need one but I like him and I don't have to pay for it, so why not?
You could in theory help train them learn to do something more useful.
Ironically mine was a QA minion and did the scrum master training as a means to get on the manager track.
This is one of the roles that I passionately hated in my previous company. No value add, and just wasted time with meetings. If your team, product manager, eng manager has no clue on what they are doing, then yes scrum master's role has a concrete outcome (atleast to keep people busy working). but if any one in the team has any clue on what they are doing, I found no value. Most of the scrum master/agile coaches i interacted with are more married to the whole process of scrum ceremonies rather than the concrete goal they are trying to hit at end of month.
Scrum master and Product Owner are both roles where, if I’d never seen someone do them at a high level of competency, I’d question whether they were necessary at all.
Scrum master: One time I was having an argument with a couple engineers because we couldn’t figure out how to implement a particular thing. I said “if K (a senior architect) was here, we’d be able to settle this, but I’m sure his schedule is booked up”. We continued arguing in circles, then suddenly 5 minutes later K materialized out of the ether. Our scrummaster had overheard me saying that, and silently navigated the bureaucracy to get us immediate time with the person we needed, all without being asked, and that unblocked our team. When you have a good scrummaster, they’ll know when it’s OK to bend/break rules and when to enforce them, and they’ll have a “particular set of skills” necessary to keeping the team unblocked.
Product Owner: At my previous job there was a Product Owner named Terry who I continue to hold up as the gold standard. She was totally unafraid to get her hands dirty learning about the part of the system she was stewarding. You could parachute her into a deeply technical area and within a sprint she’d have found the happy paths, the edge cases, the things customers cared about/didn’t, and she’d (this is critical) be in a position to reject stories that legitimately didn’t pass muster. She perfectly walked the difficult line of knowing when to call BS on someone and knowing when to trust their explanation.
When done poorly, scrum masters fall back on rigidly performing ceremonies or processes without considering whether they’re providing value. When done poorly, Product Owners will ask developers “what’s this thing I’m accepting?”, and hopefully the developer did their job, because the PO won’t know if they didn’t and will just rubber stamp the story. The unfortunate thing is that there are a lot of folks in these roles who are simply “performing the motions”, and so the overall reputation of these roles gets tarnished as a result. But when done well, they deliver a lot of value.
Scrum master: One time I was having an argument with a couple engineers because we couldn’t figure out how to implement a particular thing. I said “if K (a senior architect) was here, we’d be able to settle this, but I’m sure his schedule is booked up”. We continued arguing in circles, then suddenly 5 minutes later K materialized out of the ether. Our scrummaster had overheard me saying that, and silently navigated the bureaucracy to get us immediate time with the person we needed, all without being asked, and that unblocked our team. When you have a good scrummaster, they’ll know when it’s OK to bend/break rules and when to enforce them, and they’ll have a “particular set of skills” necessary to keeping the team unblocked.
Product Owner: At my previous job there was a Product Owner named Terry who I continue to hold up as the gold standard. She was totally unafraid to get her hands dirty learning about the part of the system she was stewarding. You could parachute her into a deeply technical area and within a sprint she’d have found the happy paths, the edge cases, the things customers cared about/didn’t, and she’d (this is critical) be in a position to reject stories that legitimately didn’t pass muster. She perfectly walked the difficult line of knowing when to call BS on someone and knowing when to trust their explanation.
When done poorly, scrum masters fall back on rigidly performing ceremonies or processes without considering whether they’re providing value. When done poorly, Product Owners will ask developers “what’s this thing I’m accepting?”, and hopefully the developer did their job, because the PO won’t know if they didn’t and will just rubber stamp the story. The unfortunate thing is that there are a lot of folks in these roles who are simply “performing the motions”, and so the overall reputation of these roles gets tarnished as a result. But when done well, they deliver a lot of value.
Yes when there are really good people, the roles are a godsend to developers who can then focus on writing code rather than negotiating bureaucracies and listening to users and customers.
The problem is the vast majority of times you don't get those good people in these roles and it ends up hindering then helping on average.
The problem is the vast majority of times you don't get those good people in these roles and it ends up hindering then helping on average.
In my experience, the most common failure case is that businesses will try to cut costs by either combining the roles, or stretching a PO or scrummaster across multiple teams. I’ve met people who I imagine could be good POs in a different situation, but were scatterbrained from having to manage 3-4 teams’ backlogs.
> She perfectly walked the difficult line of knowing when to call BS on someone and knowing when to trust their explanation.
This, 100%. The best PM I ever worked with had exactly the same skillset.
If your PO / PM can't internalize the technical edges of the product quickly, it's better to have no one in the role.
And that's a difficult ask, because it's extremely hard to reason logically about something you had 12 hours to cram for, with people who are experts at it. But nonetheless, I've known people who can do exactly that!
Unfortunately, there are far fewer of them than open PO / PM job roles...
This, 100%. The best PM I ever worked with had exactly the same skillset.
If your PO / PM can't internalize the technical edges of the product quickly, it's better to have no one in the role.
And that's a difficult ask, because it's extremely hard to reason logically about something you had 12 hours to cram for, with people who are experts at it. But nonetheless, I've known people who can do exactly that!
Unfortunately, there are far fewer of them than open PO / PM job roles...
Isn't that a manager? Why a scrum master, contacting a person doesn't seem to be a scrum master job, rather a manager job
I don't think I have ever witnessed a more efficient way to waste time, meant for solving technical problems, than by doing vanilla scrum (in an major corp ops team). For me following scrum "by the guide" is the pinnacle of pseudowork and by that definition the scrum master is a pseudo role.
I don’t think many companies including where I work do real scrum but some weird micromanaged thing that has a lot of artifacts of scrum without really understanding what agile should be.
In any case, when I am scrum master I put a lot of effort into keeping the backlog clean and making sure people or teams don’t block each other. I think that’s a valuable thing to do and can be close to a full time job. The big question is why we still have project managers and line managers who sort of do the same thing. Right now we have Jira to track things for the devs, but project managers use MS project so we have the same information in different tools which causes a lot of overhead to synchronize reporting.
In any case, when I am scrum master I put a lot of effort into keeping the backlog clean and making sure people or teams don’t block each other. I think that’s a valuable thing to do and can be close to a full time job. The big question is why we still have project managers and line managers who sort of do the same thing. Right now we have Jira to track things for the devs, but project managers use MS project so we have the same information in different tools which causes a lot of overhead to synchronize reporting.
A few places I've seen who do agile basically just practice standing in a circle and giving vague updates about progress ('stand ups') which nobody really listens to. If we disposed of all the scrum stuff around it, this would be effective as a way to handle questions that multiple people have an interest in. Which effectively is what it devolves into most times.
'Scrum Master' was a clever hack. You couldn't exactly fire the managers in most organizations. The concept of self-directed teams is scary to many people; but you can give managers something else to do.
The relevant question:
- We choose to do X
- Do we need someone being responsible for X?
The answer is almost always "yes". If you want Scrum, then having someone who has explicitly been dedicated to it makes sense.
- We choose to do X
- Do we need someone being responsible for X?
The answer is almost always "yes". If you want Scrum, then having someone who has explicitly been dedicated to it makes sense.
[deleted]
Does anyone still use Scrum? It seems like a fad that sort of died out 10 years ago.
Facebook, Apple, Google, Yahoo, Spotify, many major enterprises, presumably many readers of this article.
Why do you think it was a fad that died out 10 years ago?
Why do you think it was a fad that died out 10 years ago?
> Why do you think it was a fad that died out 10 years ago?
Because the last time I heard anyone in my circle of friends (which includes people who work at Facebook, Apple, Google, Yahoo, Spotify, etc) mention scrum was more than a decade ago.
I've seen people using some Agile methodologies, but not the Scrum framework.
Because the last time I heard anyone in my circle of friends (which includes people who work at Facebook, Apple, Google, Yahoo, Spotify, etc) mention scrum was more than a decade ago.
I've seen people using some Agile methodologies, but not the Scrum framework.
A set of anecdotes are a perfectly legitimate reason to ask a question, which is what they did, after all.
And they may be unreliable due to cherry-picked or otherwise non-representative samples of typical cases.
This being a perfect example. Jedberg never heard of Spotify using Scrum "for 10 years" but they'd been using it the whole time, as confirmed by jedberg.
This being a perfect example. Jedberg never heard of Spotify using Scrum "for 10 years" but they'd been using it the whole time, as confirmed by jedberg.
Maybe they've used it so long and are so used to it that they just take it for granted, and that's why they don't mention it any more.
Oh, so you're going based on a few anecdotes. Well, not even anecdotes, just a lack of mentions.
Its easy to find official blog posts of these companies and other major enterprises describing how they use Scrum, that are much more recent than 10 years ago.
I'm shocked you've never heard of the "Spotify Model" which has been compared to Scrum@Scale. Ask your friend!
Its easy to find official blog posts of these companies and other major enterprises describing how they use Scrum, that are much more recent than 10 years ago.
I'm shocked you've never heard of the "Spotify Model" which has been compared to Scrum@Scale. Ask your friend!
The Spotify model is about how people are arranged. It has nothing to do with development methodology or work tracking. From the whitepaper introducing the Spotify model (https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScal...):
> [Squads] are a self-organizing team and decide their own way of working – some use Scrum sprints, some use Kanban, some use a mix of these approaches.
> [Squads] are a self-organizing team and decide their own way of working – some use Scrum sprints, some use Kanban, some use a mix of these approaches.
And here's a version that's 8 years more recent [1]
> The foundation of the model is the squad and it acts like a Scrum team.
The Spotify model resembles Scrum@Scale which is why I mentioned it. Scrum is a development methodology.
1. https://www.pmtoday.co.uk/spotify-scaling-agile-model/
> The foundation of the model is the squad and it acts like a Scrum team.
The Spotify model resembles Scrum@Scale which is why I mentioned it. Scrum is a development methodology.
1. https://www.pmtoday.co.uk/spotify-scaling-agile-model/
From your article:
> Each of the squad has complete freedom to choose their agile methodology. So some squad uses Scrum sprints, some use Kanban and some uses mix of scrum and kanban. Sometimes to release early, squads apply the Most viable product (MVP) technique too.
The Spotify model is not related to Scrum. It organizes people. How those people manage their work is not related to how the people are organized. An article explaining the Spotify model in terms of Scrum isn’t a counterexample to that.
> Each of the squad has complete freedom to choose their agile methodology. So some squad uses Scrum sprints, some use Kanban and some uses mix of scrum and kanban. Sometimes to release early, squads apply the Most viable product (MVP) technique too.
The Spotify model is not related to Scrum. It organizes people. How those people manage their work is not related to how the people are organized. An article explaining the Spotify model in terms of Scrum isn’t a counterexample to that.
> some use Scrum sprints, some use Kanban, some use a mix of these approaches.
Is there only one "The Official" ScrumBan, or can anyone make their own?
Is there only one "The Official" ScrumBan, or can anyone make their own?
It sounds like you are conflating scrum and agile. Lots of companies are still doing agile, few innovative ones (including the ones on this list) are doing scrum. Given that scrum is defined by its very specific rules and quite zealous about “scrum-but” being heresy I don’t think you can count kanban, spotify, or other models as scrum.
Nope, talking about Scrum
Spotify uses agile and some of the teams use Scrum, but not the whole company.
Also, I just talked to my friend who is an Eng manager at Apple, and they said almost no one uses Scrum at Apple anymore. Some teams use some of the methodology, but even those teams got rid of their Scrum masters.
Also, I just talked to my friend who is an Eng manager at Apple, and they said almost no one uses Scrum at Apple anymore. Some teams use some of the methodology, but even those teams got rid of their Scrum masters.
> Spotify uses agile and some of the teams use Scrum
Wait, that contradicts what you just said. Your friend that works there hasn't mentioned Scrum in 10 years!
Thanks for confirming that there are teams at Apple using Scrum, like I said. Dev teams at Apple are pretty insular, I'm surprised your friend knows about what every team is doing! Hopefully we can trust them more than your friend who was wrong about Spotify.
Wait, that contradicts what you just said. Your friend that works there hasn't mentioned Scrum in 10 years!
Thanks for confirming that there are teams at Apple using Scrum, like I said. Dev teams at Apple are pretty insular, I'm surprised your friend knows about what every team is doing! Hopefully we can trust them more than your friend who was wrong about Spotify.
Scrum and agile are often conflated but are two different things. Agile is more a set of general principles whereas Scrum(tm) is a specific framework
[deleted]
Spotify Engineering Culture (by Henrik Kniberg)- Part 1 (2014)
https://www.youtube.com/watch?v=4GK1NDTWbkY
Spotify Engineering Culture (by Henrik Kniberg)- Part 2 (2014)
https://www.youtube.com/watch?v=rzoyryY2STQ
https://www.youtube.com/watch?v=4GK1NDTWbkY
Spotify Engineering Culture (by Henrik Kniberg)- Part 2 (2014)
https://www.youtube.com/watch?v=rzoyryY2STQ
I know for sure that Google doesn't do it and I think many of your other examples doesn't either. Some teams at Google might do it, but it isn't the norm and I didn't see any that did. Many teams do daily stand-ups, but that is about it and even stand-ups aren't that common. There are no sprints etc and I don't think I ever saw the word scrum in any message boards there even.
A lot of companies have scrum-masters but practice something other than scrum (agile). They also may be called agile-leads, but in my experience they are identical roles.
The way I have seen the role these days is Agile coach, who teaches the principles of lean and agile as needed and helps teams diagnose problems they are too close to to solve, which is a valuable service. There’s usually one per few hundred people at a company, rather than one per five or so for the scrum master.
I had job where we had an agile coach. First job at of college.. I thought it was the dumbest thing ever and pointless. Then they fire the person and replaced them. It was a complete 180. The new person was so good at just coming in sitting down and just listening. Then give some quick advice and things to try. Then leave and then follow back up after a bit and check in. Not everything they suggested worked. But it was extremely helpful.
Huge enterprises love it. At least the ones I've worked at do. It took about the last 10 years for them to get on board, but now it's entrenched.
Scrum allows for granular micro-tracking of developers at a daily level while sanctifying the ideas of developers as interchangeable cogs and that leaderships should be able to move the goalposts at the last minute.
What’s for an enterprise exec not to love?
What’s for an enterprise exec not to love?
Well said. It's funny how Scrum was sold to developers as a way to "empower" dev teams, but more often than not it simply encourages micromanagement and poor planning.
I think most of the teams adopt it’s main activities without strictly following the rules. This way, it’s easy to start using, but teams never truly master it and usually start inventing their own heuristics for planning/reviews.
Some large companies, actually invest their time in agile training and contribute to SE process research. From large companies, I can call Ericsson and Spotify (good scrum at scale examples).
Some large companies, actually invest their time in agile training and contribute to SE process research. From large companies, I can call Ericsson and Spotify (good scrum at scale examples).
I think the problem is that in most companies agile is viewed as something for the developers while the management structures and processes basically remain unchanged.
One of the few places in tech where using the word "master" is cool. It's not entirely clear why.
Scrum trunk doesn't have the same ring to it I suppose.
Masters have slaves. Which is exactly how workplaces implementing scrum view developers. Slave to the business and really the lowest level worker ant.
master/slave for drives?
master for main branch?
master for main branch?
I view the whole thing as a sort of cult/koolaid/consulting industry. The original intentions of the Agile Manifesto may be good, and I admit there are some good ideas in there, but the entire industry that has formed around it is a waste of money IMO.