There are many trains of thought about being precise with the roles used within your Agile teams. The underlying principles are about making sure that certain responsibilities are taken care of and those are typically embodied in different people. Here they are:
Product Owner / Customer
ScrumMaster / Facilitator
Team Member / Implementor
While Scrum is very specific in what the roles are called, not all organizations employ the specific names being utilized by Scrum. Perhaps the most common overlap is with the ScrumMaster role. The next most common is the Product Owner role. Rarely or never do you hear the term team member used. And whenever an absolute statement is made like that I’m sure I’ll hear from someone that speaks up and tells me that they are a team member and how dare I alienate them. It’s true, team members are people too.
Let’s look briefly at the roles themselves and take a look at the video that Ty Grigg explains a little bit more around these roles.
Product Owner / Customer
They are responsible for choosing what we will make or build. They not only are responsible for telling us to build the right thing, but what becomes more important than other potential conflicting priorities. They solely are responsible for prioritization of requests from countless stakeholders. We need to make sure the Product Owner is provided with good information to enable the best possible decisions. Various analysts can help make this role much more successful than just being the single wringable neck.
ScrumMaster / Facilitator
The team conscience. The team guide. The team facilitator. Too often this role in undervalued. I have recently worked with some organizations that struggled to find who would possibly want to fill these lowly ScrumMaster roles. Not even a year later, the organization is humming along, progressing in their agile maturity and they are seeking out more people to fill the ScrumMaster role because of how well the people have done in those roles to this point in time.
When a ScrumMaster does their job right, he or she finds ways to challenge their team(s) to continuously improve. A stagnant team is a sign of a stagnant ScrumMaster. A vibrant team that continually tries to improve comes as a result of a ScrumMaster that encourages, guides and molds them to be better than they currently are. It starts with simple refinement of meetings, backlogs, estimation and evolves into larger discussions about sustainability, cross-training, proper team size, horizontal slicing of user stories and functionality, automated testing suites, definitions of done, definition of ready and so much more.
The ScrumMaster is the role in an organization that is a catalyst for good, a spark for change and for everyone, they are the change agent needed in an organization to not settle for status quo. Let your ScrumMasters disturb some norms and truly get the organization to change and adapt.
Team Member / Implementor
Mostly responsible for the work on and completion of work requested by the Product Owner, team members take on development, testing, documentation, database engineer, architect, business analyst and so many other roles and/or responsibilities. The key here is that the team determine how best to act and they move forward accordingly. The team works together to make sure the product is built right that has been requested by the Product Owner. They also work together with the guidance of the ScrumMaster to make sure it is being built fast enough.
Regardless of the role, the responsibilities are what reign supreme. When a team works together they can accomplish the right outcomes intended for the product they are creating.