Scrum is a lightweight framework that describes roles and events but leaves the implementation details for teams to define. The Scrum Guide specifies that there are three roles: product owner, developer, and ScrumMaster. It’s essential that a Scrum team have each of these roles to help it work well. But depending on how you implement the roles, you may end up hurting rather than helping your Scrum process.
One trap teams fall into is equating the roles with exclusive job functions. Focusing on the “who” rather than the “what” leads us astray. Just like with a soccer team, having too much emphasis on the role and not how it fits into the overall purpose of the team can lead to a mindset of siloed responsibilities rather than collaboration.
There’s an all too common dynamic that occurs as agile ideas become more mainstream: conflating “role” and “job title.” This confusion speaks to a misunderstanding of what makes agile work.
There’s also a tendency in our industry to want to formalize things as soon as possible, perhaps to reduce uncertainty, but at the risk of making the interdisciplinary models that streamline software development hard to implement. Consider DevOps, which is a model where developers and the operations team work with each other’s domain in mind. In essence, DevOps is about an approach where the development team thinks about deployment and monitoring so that they can develop production-ready applications. At the same time, the operations team creates infrastructure that the developers can work with easily. There are still special skills, domains of primary responsibility, and areas of focus, but the groups work together closely, and perhaps begin to overlap over time.
Given the interdisciplinary nature of DevOps, we wonder why we see job postings for “DevOps engineers” (which are really for operations engineers who have a collaborative or agile mindset). Specifying “DevOps engineers” can create an artificial boundary and give another name to an existing role, without changing the dynamics.
Likewise, in Scrum, having people filling roles on the team doesn’t mean that certain items are the sole responsibility of the person with that role. We need a product owner who has the final say in priorities and feature specification, but Scrum works better when developers apply their insights to help build the product roadmap. Having someone keep the process running is essential to keeping everything on track, and while the ScrumMaster could be that dedicated person, the responsibility could be shared with a developer or someone else on the team.
While the team should be mindful of conflicts of interest, it’s important that you don’t create an environment where people feel that they cannot contribute outside of their “job.”
Scrum teams often stumble when their process moves further away from supporting Scrum goals, which include being cross-functional. The Scrum process is meant to help you reach your goals, and if you find the prescribed roles getting in the way, think about how you are implementing them. Remember that roles do not need to equate to job titles, and delivering value is the end goal for everyone in the process.
