Mapping Traditional Software Development Roles to Scrum

Posted by Vikas Hazrati on Mar 10, 2009

Sections

Process & Practices

Topics

Adopting Agile ,

Agile

Tags

Scrum ,

Roles ,

Adoption

Many organizations, which have embarked on the Agile adoption path, have to tackle the challenge of mapping traditional software development roles to the three roles that Scrum provides. Traditional roles like Product Manager, Project Manager, Business Analyst, Designer, DBA etc. do not cleanly map into roles defined by Scrum. In a series of views Mike Cottmeyer attempts to effectively map traditional roles to Scrum.

Mike suggested that the 'Scrum Master' and 'Scrum Team' roles are relatively easier to fill.

The Project Manager could fit into the role of a Scrum Master however, it does involve a mindset change. According to him,

ScrumMasters are process facilitators and support for the team. Project Managers are usually responsible for managing the team and ensuring that time, cost, and scope are balanced. [...]

ScrumMasters have no authority over the team. ScrumMasters are more servants of the team... Project Managers are more like a boss.

Likewise the 'Scrum Team' should involve everyone who is involved in heavy lifting of building the product.

The development team, the database guys, and QA can probably be worked nicely into the role of Team Member. These folks have direct responsibility for designing, building, and testing the code.

Once the above roles are mapped there are still a lot of roles like Business Analysts, Systems Analysts, User Experience specialists, etc which need to be mapped to Scrum roles. According to Mike, all these roles could potentially roll up into a Product Owner role.

The Product Owner is the Project Manager, the Business Analyst, the System Designer, the User Experience Architect, and every other Business Group... all rolled into one. The role is really supposed to be omnipotent and omnipresent.

However, Mike does acknowledge that this is a huge role in itself. Hence, he suggested that instead of one person who fills in all these roles, it could instead be a Product Owner Team where multiple people coordinate together. The team could include

• Product Manager - Works with stakeholders, identifies requirements and sets priority.
• Project Manager - Maintains a view of the overall objectives. Manages resources, capital expenditures, external dependencies etc.
• Business Analyst - Responsible for documenting acceptance criteria and documenting the conversations around the user story. Primary point of contact for requirements clarification during the sprint.
• Designer - Prepares some screen shots, wireframes, etc.

He represents the setup pictorially like this

Hence, instead of working in isolation, the Product Owner interacts with various other roles and helps in bringing their collective knowledge and expertise to define the correct context and provide coordination.

Thus, by grouping roles efficiently the traditional roles can fit into the three roles suggested by Scrum. The key is to map them at the correct places where they would add value to the entire team.

1. Back to top

   here's mine

   by Aaron Sanders

   I appreciate the product owner team, something I am implementing now. Perhaps I'llupdate my own roles/responsibilities post to reflect this.
   
   aaron.sanders.name/agile/agile-team-members-rol...

   Reply

2. Back to top

   Re: here's mine

   by Vikas Hazrati

   Thanks for sharing the link with the community. It is very helpful!

   Reply

3. Back to top

   And another point of view

   by Amr Elssamadisy

   Dean Leffingwell, known for his book on Scaling Agile, has written 2 of a 3 part series on the product owner in the enterprise. He takes a different approach to the Product Owner team; 1 product owner only per project and a higher-up role the Product Manager.
   
   The first part describes the need for two different roles and the second part describes the roles and responsibilities of the newly defined product owner.

   Reply

• Older >