Scrum Roles Q&A Recap and Recording
On a Scrum team, there are three roles: ScrumMaster, Product Owner, and Development Team. For teams transitioning to Agile, there can be a lot of confusion around how individual Scrum roles and titles might change to fit into a new environment.
Recently, our Agile coaches Braz Brandt and Brian O’Fallon sat down and addressed questions on Scrum roles and how each role affects the individual and their organization. Check out the webinar recording and Q&A transcription here:
Q: What’s the difference between a Product Manager and a Product Owner?
Brian: This comes up fairly often. The real similarity, of course, is that both are responsible for understanding the product, setting its vision, and getting buy-in. However, the PO is much more hands-on with the execution of the product. They help with the communication between the team and the stakeholders.
Braz: Right. We’re expecting the Product Owner to have two very distinct skill sets. The first being a clear, customer-focused vision of the product. The second being they have that same expertise and availability they give to customers for the development team as well.
Q: Can you combine roles (PO and SM, PO and developer, SM and developer, etc)?
Braz: You can do anything. The question is will you be effective? It can be difficult to change hats so often. So make sure that the individual who wants to play more than one role has a very firm grasp on each role. However, even then, I wouldn’t recommend it.
Brian: It’s also important to consider the motivation. Is this an HR move to cut down on employees and save some money? Or is this an individual who wants to learn about another role and develop some new skills? I’m always more willing to let someone learn new skills because they’re interested in teamwork and building interpersonal relationships than I am to combine roles just to cut down on costs.
Now, can a ScrumMaster be a developer? Absolutely, but it works best on mature teams.
Q: What if we have missing roles, like no dedicated ScrumMaster? Can we rotate roles?
Brian: You’re best off finding someone to permanently fill that role. When it comes to rotating roles, I don’t advise it. Each role, particularly ScrumMaster, requires practice and attention so the individual can build up the necessary skills.
Rotating the ScrumMaster usually means there is always someone new in the role, meaning skills aren’t fully developed, and the team doesn’t get what they need out of the ScrumMaster. If you need to rotate, I wouldn’t recommend doing it any more often than quarterly. That at least gives the team a bit of stability.
As far as rotating the Product Owner role, please don’t. It never leads to good results because that Product Owner needs to have such a long-term understanding of a product’s development.
Q: Does the ScrumMaster need to understand the business/technical aspects of the product?
Braz: The ScrumMaster doesn’t really need to understand the business or technical aspects. Of course, it can help the ScrumMaster recognize problems or inconsistencies at times, but it’s definitely not necessary.
Q: Should the Development Manager be on the Scrum team as an advisor?
Brian: This is something we see all the time. It’s very common to walk into an organization and find that an HR person or someone in a position of authority has been assigned to each team. That person usually writes performance reviews and takes care of professional development.
The truth is that it’s very hard to be honest and open when there is someone else in the room responsible for judging your performance. It can also make people defensive of their work as opposed to being open to suggestions and feedback.
Braz: Yeah, I agree. The Development Manager should definitely not be on the team. It runs the risk of creating an unsafe environment for the team.
Q: I’ve run into a lot of uncertainty in organizations with newly minted Agilists asking “where does my career path go from here?” Could you talk a bit about moving up the ladder, starting from a Product Owner or ScrumMaster?
Brian: On the PO side, it’s a little more straightforward. When Product Managers are transitioned into Product Owners, their path doesn’t change all that much.
For ScrumMasters, it’s not really a traditional “ladder” career path. It becomes more about skill acquisition and how effective you are as a facilitator. You can play the same role but maybe move up to play the role for a higher level team. There are also options like the ones we took: a ScrumMaster could evolve into an Agile coach at some point.
Q: How about Tech Leads? Is there a strategy to equalize them with the Dev Team when promotion/career tracks require it as a stepping stone?
Brian: Traditional roles like Lead positions can get really interesting when we start to implement Scrum. The old ways of measuring people in terms of their ability to push a project through or help manage the project is not as effective as it once was. Now we have this self-organizing team and that skill set is subsumed by the process.
To be blunt, it’s a hard question. If you mean in terms of the team perspective, meaning how do we equalize them with the leads, we lean on the ScrumMaster to do that in a grooming or refinement meeting. Leads or authority positions often have a tendency to take over the conversations in the meetings. There needs to be an understanding that the ScrumMaster is there to intervene and all voices are heard.
It can be tricky, because Leads might start to feel a bit devalued. However, they can very well exist in an Agile environment as long as they’re more descriptive than they are prescriptive of what happens on the team.
If your career path requires it, it’s important to be careful not to let that drive the processes that Scrum implements.
Q: Scrum roles are a work function, not titles, right?
Brian: You’re right. Your HR title doesn’t necessarily define your work. We always recommend that folks let the title that they get promoted and paid on exist in a slightly different space than the role they play in the team. Your title is not particularly indicative of what you’re doing on a day-to-day basis for the Scrum team. I’ve been called a Development Manager while playing the role of the ScrumMaster.
Braz: Absolutely. I would love to see that more often. One of the big things in Agile and Scrum is the idea of servant leadership, and it would be great to have more managers in roles that develop those skills.
It can be beneficial to include HR as soon as we begin our Agile adoption to help them better understand and help with the transition.
Q: Do we still need a Technical or Dev Lead, when we have a ScrumMaster?
Braz: I think sometimes you do. Like we mentioned earlier, the ScrumMaster doesn’t always have the technical expertise, so they’re often going to need deep technical and business experts that they can lean on when they have questions.
Now let’s be clear, that expertise doesn’t have to come from a Technical or Dev Lead. Not all teams need to have that role filled, but Leads can definitely come in handy.
Q: Should the role definitions be shown within the Scrum team’s working agreement(s) as a reminder/information radiator?
Brian: I have to admit, I haven’t tried that.
Braz: I haven’t either, but I don’t think there’s a problem with that. It might be helpful that have the 3 Scrum roles (Product Owner, ScrumMaster, and Dev Team) clearly defined and displayed to help individuals find their place on the team. It reminds everyone not to create new roles or silos, which in turn, encourages collaboration.
Brian: Yeah, I think that would be a great idea, especially for new teams. It can’t hurt to be very transparent about what each of these roles entails.