Zen of Scrum: Roles and Teams


Yin Yang

The agile team concept is one of the Scrum practices that might be difficult to fully grasp. For me at least,this is a continuous learning experience.

It is also one of the most important things to get right: and where many agile transitions go wrong. Cross-functional, self-organizing teams runs counter to the classical matrix management structure with project teams.

Many organizations do sprints, Scrum boards, burndowns, and so on, but don’t change their mindset much.

This post is related to the free Scrum presentation Zen of Scrum (the previous post gave an overview of Scrum).

Scrum Roles

Scrum defines three roles. The number is intentionally kept low as more roles create overhead and complicates communication.


  • The Product Owner (PO) is the glue between the team and the customer and other stakeholders. The PO ensures the greatest possible value is delivered.
  • The Scrum Master (SM) is the "agile enabler" or "Scrum catalyst". This person helps the organization understand and apply Scrum in a good way.
  • The Team (Developers) is a cross-functional, self-organizing feature team. A feature team is a long-lived entity capable of delivering product value as a stand-alone unit.

I personally think it’s confusing to use the word Team to describe the third Scrum role when the term Scrum Team is used to describe the whole team, including the Product Owner and Scrum Master.

The idea is to emphasize the importance of team collaboration in contrast to different specialist roles such as coder, tester, analyst, documenter, and so on.

Nonetheless, I prefer to use Developers as the term for different specialist roles involved in product development. There’s still no distinction between specialists: they are all involved in developing the product.

Mapping to Traditional Roles

When changing to Scrum, one mistake that is often made is to let the project manager become scrum master. I think this is bad of two reasons:

  • A traditional project manager role involves communication with stakeholders and the customer, prioritizing work, making up release plans, and so on. This maps much better to the Product Owner role.
  • The project manager is a management role and this person often has a special position in the team. This inhibits self-organization, especially when the whole team transits to Scrum: the project manager continues managing the team.

I think it’s better to let the project manager become product owner. The product owner role has more focus towards communicating and prioritizing work, focusing on maximizing ROI (Revenue of Interest).

However, make sure the Product Owner doesn’t revert to detailed planning and managing the team.

Transitioning to Feature Teams

While transition for individuals can be tricky, a bigger challenge is changing the mindset of the organization.

An organizational shift towards feature teams, away from traditional line/project matrix structures, is not accomplished over night. It might challenge set ways, and requires real ambition to change.

This is expressed another way in an excellent article about feature teams by By Craig Larman and Bas Vodde:

people may incorrectly think they are doing Scrum or agile development simply because they are doing mini-waterfalls in a shorter and iterative cycle. But mini-waterfalls are not lean and agile development; rather, we want real concurrent engineering.

That’s it for this post. Next time I will write about the Definition of Done.

1 comment:

  1. Team needs to grow each day which is the way of it,The most basic thing is to have an outcome especially when we talk about business agility we get to learn man things which are fine enough in a way.