Roles on Agile Teams

Note: This article is updated at Roles on Agile Teams.

You can think of a role as a group of related tasks, activities, and responsibilities.  By knowing the responsibilities and core types of activities up front, you can help make sure you have the right people on the team so that you can achieve project success in a healthy and sustainable way.

On smaller teams, the key roles include: team lead, team members, product owner, and stakeholders.  The team lead is often a “project lead,” or a “team coach” or, in Scrum, the “Scrum Master.”  The main activities being performed by team members include design, development, and validation against requirements and constraints.

On larger teams, additional roles include architecture owner and integrator.  Some of the key issues to orchestrate and coordinate include: architecture and technical issues, project management activities, requirements management, and system integration. As teams get bigger, the strategy becomes a "team of teams" approach.  At Microsoft, this is a common practice.

A few key concepts for Agile teams include: "whole team", "product owner," "self-organizing team", and "sustainable pace."  Whole team is an Extreme Programming (XP) practice where the team has all the skills it needs to complete the project, without relying on external experts.  Product owner, in Scrum, is a project's key stakeholder, and usually a lead user or customer advocate.  In XP, this was the on-site customer, but is now part of "whole team."  The main idea is that the customer is available throughout the project to shape, guide, and validate the priorities and acceptance criteria for the team.  Self-organizing is the idea that teams are empowered to organize themselves, rather than fit canned roles.  "Sustainable pace" (originally, "40 hour week" in Extreme Programming) is the idea that you set a sustainable, measurable, and predictable pace for the team.

In practice, there are a couple more concepts that help team success: team stability and generalists.  To achieve team stability, avoid swapping out team members.  Teams go through forming, storming, norming, and performing so swapping out team members is more than just losing the knowledge and experience, it disrupts the team chemistry.  As Fred Brooks reminds us, adding members to an already late project just makes it later.   Using generalists (that are specialists in one or more domains) helps create a more flexible team that can respond to challenges and better support a "whole team."

On the Microsoft patterns & practices team, these are the roles and responsibilities that we typically defined at project kickoff:

Roles	Responsibilities
ArchitectDeveloperDevelopment LeadLead WriterProduct ManagerProgram ManagerTestTest LeadSubject Matter Expert	Architecture and DesignBudgetBusiness InvestmentCollateralContent StructureCustomer ConnectionDesign QualityDevelopmentEvangelismFeedbackProduct Group AlignmentProduct PlanningProject PlanningQualityReleaseRequirementsScopeScheduleSimplicitySupport / Sustained-EngineeringTeam and PeopleTest ExecutionTest PlanningUsability

Nothing is worse than getting mid-way through a project, only to realize you don't have a "whole team" that can execute successfully, or that you don't have the right "product owner" to validate that what you're shipping meets the needs of your users.

You Might Also Like

• 40 Hour Work Week at Microsoft
• Agile Methodology in Microsoft patterns & practices
• Methodologies at a Glance

Comments

• Anonymous
  June 22, 2016
  great post