Hacker News new | ask | show | jobs
by y2hhcmxlcw 3039 days ago
Something I have wanted to ask the HN community, that this article brings up: what exactly does a scrum master do?

From what I have observed at one business, there is one scrum master on every team. Many of them know nothing about the business that business does, and have no technical background. I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.

But what I can't figure out, is what they are actually supposed to do. At best, I see two points: 1. They do the traditional work of a project manager but on a team level, and communicate status up. 2. They are supposed to be some kind of "thought leader" on agile methodologies.

Can HN help shed some light on what this role should do? Perhaps my background has just been a bad experience in this regard. I suppose where I get stuck is, this seems to be the work that a dev lead used to do. Why make a full time job for a non-technical person to lead a technical team, below the management level?

3 comments

In my company, each team has a scrum master (a SM being part of 2/3 teams). They have near-zero technical knowledge, and this is what they do (no particular order):

- Give an organisation to the team, and make sure that this organisation does not decay with time - Help the devs work faster by helping them with the methodology - Help identifying & solving problems (a problem goes from "a dev spent one hour more than expected on this ticket" to "the client has no vision on what the product should be"). This is probably the most important task - Help the client to lead his project. This is a huge part too, the client does not know how to lead a project (they just came to us with a business problem they want to solve): there's no way the project will succeed if the client doesn't manage to have a clear vision for his product, prioritise tasks, build indicators, get user feedback...

Minor tasks: - Organise meetings/demos - Lead the meetings, make sure they're productive

We're a service company without management, "communicating status up" is a concept that doesn't exist.

> This is probably the most important task - Help the client to lead his project

For someone to do this, they would have to have client communication skills, at least somewhat thorough understanding of software development or the process, and an understanding of the client's business. I see this as a good thing. However, your example sounds to be a company that has external clients that you write software for. Do you not have account managers/principle types who interact with the clients, or is that more or less what a scrum master does there? Just curious, if you were an internal only dev shop that just develops software for stakeholders at your own company, would you see the role of a scrum master as significantly different?

I've never had a scrum master across 7-8 companies. Usually it was a rotating role, or a manager/tech lead. But certainly not one person dedicated to it.
Yeah, it's supposed to be a role for a dev to play for 10 minutes a day.

Unfortunately I've seen people with it as a job title. They were the absolute joke you'd expect.

spotify seems to have a few professional scrum masters and it seems to work for them. I'm less interested in typical cynicism and more interested in how this gets done -well-. Any spotifier's care to comment on having fulltime scrum masters?

edit: It seems they are called "Agile Coach"es.. is that any different?

>I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.

Your scrum masters really aren't. The SM role is supposed to be a few minutes a day, and focus more on how people work rather than the technical details.

Examples are things like telling management that the team has often missed deliverables because a key resource (some piece of hardware, etc) is often unavailable. Or even telling managers that their employees think one of the manager's policies sucks.

To an extent, it's about holding the team accountable as well: Why are some people working on a lower priority item when no one is working on a higher priority item?

Don't get me wrong - I'm no fan of scrum, and am not saying a SM is needed. But, as with management, a good SM is a valuable contribution to the team.