Agile requires a shift from roles to responsibilities. Standard Agile roles, such as Scrum Master and product owner, are really an encapsulation of important team functions. The important question is whether the team handles those responsibilities, less than ensuring that someone occupies a formal role. Teams are the best arbiters of who among the team members is best suited to carry out these responsibilities, so a simple one-to-one mapping of old Waterfall job to new Agile job puts team productivity and cohesion at risk. The question of standardizing roles across teams is more significant at the value stream level, not within an individual team, since groups outside these teams need some idea with whom they need to deal about specific team-related questions.

Here are the main points to remember.

• The importance of team self-organization
• The limits of team self-organization
• The translation of team structure from Waterfall to Agile

It is “responsibilities and roles” and not the other way around

One of the common phrases in Business-speak is “roles and responsibilities,” which includes an assumption that often creates mischief in Agile adoption. To make a successful transition to Agile, the organization must stop treating the role as the primary part of that concept. Nowhere do we see the importance of making this subtle but critical mental shift than the mapping of old roles to new ones.

Responsibilities over roles

When first adopting Agile, organizations often look for a simple one-to-one mapping between old roles and new ones. Superficially, the project manager might look a little like a Scrum Master. Similarly, a business analyst or product manager might be a likely candidate to assume the mantle of product owner. The mapping is usually imperfect: for example, since ceremonies were not part of the old, pre-Agile order, a Scrum Master’s role in ensuring the team follows ceremonies like stand-ups and retrospectives isn’t part of a project manager’s to-do list. Similarly, the business analyst may have never faced a task as demanding as the strict prioritization of the backlog for an Agile team.
Because of this imperfect mapping, the organization has to drop the idea that the old job is like the new one. More profoundly, it has to treat the responsibilities, such as following ceremonies and prioritizing the backlog, as primary over the role that most frequently includes them. The best way to apportion these responsibilities is a puzzle for the team to figure out, and two teams might not resolve that puzzle in exactly the same way. For example, in one team, the product owner may schedule the demos; in another team, the Scrum Master might handle this task. The important question is whether someone handles the responsibility, not which role “owns” that task.

People over roles

While Agile compels a re-examination of the role to which responsibilities attach, it also leads to important questions about the people who occupy these roles and discharge these responsibilities. A person’s suitability to be a good Scrum Master or product owner depends more on their experience and temperament than their previous job description.

For the product owner, the backlog is a puzzle that needs to be solved. What is the best strategy for delivering the most value in the shortest amount of time? Business analysts who were comfortable relaying requirements from customers, without asking questions about them, might not feel interested in solving this kind of puzzle, or comfortable holding customers to task for making unclear requests.

For the Scrum Master, the team is a puzzle that needs to be solved. How can the team meet its immediate commitments, while improving its productivity and reliability over time? A project manager accustomed to a formalistic approach — follow these project management best practices, and all will be well — might find the less formal, but no less demanding job of Scrum Master maddening.

Therefore, the people who occupy the old roles may not be best positioned to assume the new responsibilities. Ultimately, the team is best positioned to make these decisions, since team members know each other’s work habits, personal inclinations, and ability to handle certain tasks more intimately than anyone outside the group.

The value stream over complete self-organization

That being said, there is still a good reason for some standardization of roles across teams (but not the assumption that every project manager will be a good Scrum Master, or business analyst a good product owner). People outside of the team, in the rest of the value stream, need some predictable expectations about how to deal with each team. With whom does the security team work to ensure that teams follow important security guidelines? Who on each team is responsible for reporting status information that feeds into cross-team progress dashboards?

In situations like these, it is often easier for the organization to have some consistency of role definitions across teams, to maximize flow across the value stream, reduce risk, and ensure alignment. Behind the scenes, teams won’t necessarily handle product ownership or Scrum Mastership in exactly the same ways. When the team has to interact with the rest of the value stream, the role variance is much less.

Summary

This reevaluation of roles, responsibilities, and people is one of the healthier discussions that Agile adoption ignites. Successful transformation often turns on whether organizations stay focused on the question, “Is someone handling these responsibilities effectively?” instead of getting bogged down in past roles.