Ask HN: Adding scrum master responsibilities as an IC – How to approach? | Hacker News Reader

Ask HN: Adding scrum master responsibilities as an IC – How to approach?

2 pointsobvthroaway3 comments

I am a Senior Software Engineer at a large Software Company.

Due to recent changes in my Org, my manager wants me to take on responsibilities of our Scrum Master for our team, in addition to being an IC.

I think the Scrum master role is non-technical and thus I was initially hesitant to this but I am thinking about it.

Our scrum process is non-standard. As per my observation Scrum Master does the following:

1. Collaborate with PMs and Manager to estimate tasks, define sprint scopes.

2. Create features, stories, tasks for a sprint.

3. Track the above for a sprint. Move them across sprints when ending old sprints and starting new ones.

4. Conducting sprint retros and tracking feedback, bubbling it up to our Director and VP.

My manager has offered to share responsibilities but it's not clear what that means.

I have the following questions for y'all:

1. What are the pros and cons for this?

2. Has anyone done this? If so, how was your experience?

3. When I have that discussion with my manager, what should be the outcome of that? What level of detail should I get into?

If you get wrapped around the axle as to whether this is scrum or not, or whether you're a scrum master or not, you won't be very successful.

You're being asked to understand and model requirements, and then break that down into features that can be worked on by a team following some sort of iterative development process.

While this is not coding, it is certainly engineering.

To be successful at that, you'll need to lean on the team for help on this, so you should talk to your team and ask them how they feel about it and any suggestions about how to get it done.

You're also being asked to do all the legwork in managing tickets, etc. This is something you should ask your team about. A competent team with decent tooling should be able to carry this sort of thing together.

Part of the job is setting expectations with management as to when it is appropriate to interact and when it is profitable to try to steer things. I've found once a quarter is the best expectation to set. This allows a quarterly plan to be created that has buy in from mgmt, and then that can be broken down into 2 or 3 week sprints. A quarter is 91 days, or exactly 13 weeks.

If mgmt is expecting to constantly interact, then they need to learn to not drive by looking at the hood of their car, and you might not want to be in that car.

In standard scrum, the Scrum Master is responsible for managing the process around developing software, not for actually estimating, creating features, tracking, etc. A Scrum Master's tasks remain the same regardless of what product is being worked on. A Product Owner would be closer to the role you describe above.

As a SWE who moved to Agile Coach, it can be a fun challenge, but since you aren't actually doing scrum, you shouldn't worry about actually following the full process and instead should think about essentially being a product owner (no matter the title) - the interface between the development team and the customer. You'll want to watch out for you being held responsible for the team's performance instead of the ICs on the team. So some CYA could be in order, even if that's just clearly defining your roles and deliverables with management before taking it on.

As another commenter noted, you should be able to lean on your team for help with things like estimation and tracking, but that really depends on your organization's existing process.

1. Become scrum master

2. Announce that scrum is canceled

3. Become legend

Reply on news.ycombinator.com