, Josh Anderson and I explored the good and the bad around defining roles and responsibilities in agile contexts.

It’s a mixed bag really that requires some common sense and nuance. I think we landed on the need for them, but caution around the negative effects that they can have IF you’re trying to create a healthy instance of self-directed agile teams.

The Basics

One place to start is looking at the and how it handles the Scrum roles.

Beyond the basic definitions of the roles, I really like the collaboration advice given BETWEEN the roles. I’ve found that it’s the interplay between the Team, Product Owner, and ScrumMaster that really makes the difference in high-level team performance.

I’d recommend you read (and share) the guidance in the Scrum Guide.

Establish & Share

I wrote in 2014. In it, I started with questioning the need for defining roles and responsibilities. In the end, I convinced myself that having clarity around them, and sharing them often, is a good practice.

I don’t think I amplified enough in that post, but I’ve often seen the anti-pattern of Role Confusion in agile teams. This surfaces in situations like:

• Cases where multiple individuals are essentially doing the same thing and don’t realize there is overlap and redundant work;
• Or cases where no one is taking on a responsibility because they think someone else is doing it.
• Or even cases when you hear someone say – Well, that’s not my job!

All these cases are wasteful and the latter two can build quite a bit of late found risk into the team’s deliverables.

If you see any of these happening in your organization, chances are you have a role confusion problem. And you might consider reverting back to establishing / defining roles and responsibilities for your teams.

SAFe bashing…again?

As I was thinking of roles and responsibilities, it dawned on me that Josh and I hadn’t explored them in other agile contexts. For example, in the scaling frameworks. Most of them don’t add additional roles, but SAFe is the clear exception.

One of the harsh realities of SAFe is that it tries to solve large, at-scale collaboration challenges by creating new roles and reaffirming old ones.

For those of you jeering at me right now I present…The Release Train Engineer (RTE) as a prime example of a created role. And in SAFe 4.0, we now have a Value Stream Engineer (VSE) as well. It also reaffirms roles too, often by placing them in “teams”. For example, there is a Systems Team, a Product Team, and Business Owner Teams.

Architecture and architects is another one of the emphasis points of SAFe, as they guide everyone’s Architectural Runway. For example, we have:

• Enterprise Architects
• Solutions Architect / Engineer
• System Architect / Engineer

Which are roles established in the upper 3-tiers of SAFe 4.0. While architecture is important, that’s quite a few people telling the teams how to build things. And at times, I find it can become a bottleneck to creativity and system ownership within the release trains and their teams.

The Scaled Agile folks have even jumped on the ScrumMaster and Product Owner certification bandwagon’s, by creating a Certified SAFe version of each. Now what in the world, besides revenue generation and competing with the Scrum Alliance and Scrum.org, would have initiated those?

I can’t imagine that the best interest of their customers wasn’t served by adding more confusing and competing certifications. But then again…

But the real point here is that the framework you may be using or other factors may even increase the number of roles in-play in your agile instance. In these cases, role confusion can be even more of a problem.

Distributed or Outsourced Teams

Another context where roles and responsibilities are important is with distributed teams. Often in these cases, the cultures are quite different from team member to team member. Or there might be more of a client / service relationship between members.

This can often limit the behaviors around expectations, communication, and responsibility.

Back to role confusion. If you think it resides in localized teams, it has a much greater likelihood of surfacing in distributed teams. Again, the way to reduce or avoid it entirely is to take some time and establish clarity around your roles.

@ Velocity

One of the key practices we use at Velocity to onboard our client teams is something we call a Sprint 0. Now in real practice, Sprint #0’s aren’t the healthiest of practices. But that’s not what we’re doing.

In our case, it’s more of a relationship chartering activity where we get to know the client’s details and work to integrate our team (culture, practices, methods) with the clients. Roles and responsibilities are often an element of this. Paying particularly attention to the “interface points” between our team and the client.

As an example, usually the client fills the Product Owner role for our teams. So, we explore the nuance of the role, answering questions like:

• How does the client view the responsibilities of the role?
• How do we view it?
• Are there any glaring differences? If so, how do we connect them?
• The team needs “connection” to the Product Owner, how do we plan on supporting that?
• How will the Product Owner refine the backlog with the team?
• How will the Product Owner plan the sprint with the team?
• How will the Product Owner plan the Sprint Demo with the team?

Exploring questions like this early-on, as part of a Chartering / Sprint #0 effort, helps to avoid role confusion, frustration, and poor results later on.

Wrapping Up

I know, I know, roles and responsibilities is a boring topic. And it really shouldn’t be that important in agile contexts.

But my experiences say that it is. And I hope you consider giving it its due and getting everyone – on the same page.

Stay agile my friends!

Bob.