Agile teams are software development teams first and members of a department or business unit second.  If team members are first developers, testers, business analysts, and so on, they would not be nearly as effective in a cross-functional, team-based environment.  Everyone is a team member committed to a common vision and goal.  In order to achieve these goals, team members do what is needed at the time it is needed.  This can be a bit unnerving for a number of folks used to strict roles and titles, but is critical for the common good of the team.  Statements like “I can’t write tests, I’m a developer,” have no place in an agile team.

Naturally, everyone comes into the team room with their own area of expertise and experiences. Outside of the current project, the team still needs to fit into the larger organization, so you may have to keep titles. But if an entire team can make this shift in thinking, the results can be amazing.

On most teams, there are a few standard areas of expertise. There are team members with product and domain knowledge.  These people interact closely with users and /or customers and, in a commercial software scenario, attempt to understand and research what benefits the market.  They serve the team by creating and prioritizing work, along with helping understand when work is complete.  Commonly called a Product Owner (Scrum), this group can also consist of Product Managers, Business Analysts, the Customer (XP) and anyone with deep domain knowledge.  A critical success factor for this person or group is to act and speak as a single, deciding voice for software product decisions. 

There are also team members who possess all the cross-functional skills necessary to build, validate, and deploy the product, and to determine how, if necessary, it inter-operates within a larger system.  This group of core team members can consist of developers, testers, UX designers, architects, business analysts, team leads, and technical writers.  This group works as a single team to design, code, test, and implement a software system.  The skills required to do so are extensive, and as a result, it is critical that everyone on the team work together as a single unit. This does not mean that the team doesn't consist of agile developers, agile testers, agile UX experts, etc. --  just that they all work and collaborate together in the delivery of a software system.  As a result, team members often perform multiple roles in addition to their primary responsibility.  This willingness to do what it takes to deliver a software project defines the success (or not) of the team to operate as a true team.

Teams typically have some form of a leadership role.  In Scrum, this role is typically referred to as the ScrumMaster, but on other agile projects may take on the Project Manager, Program Manager, Team Lead, or other title.  On agile teams, the primary goal of this person or group is simply to enable and ensure the success of the team.  This servant-leadership role is in sharp contrast to the traditional task-master and resource management focus.  Additional responsibilities may revolve around managing stakeholder expectations, company communication, progress reporting, facilitation, motivating team members, budget management, staff management, etc.  Just because the team is operating in an agile fashion does not mean that all organizational requirements disappear, but every effort is taken to ensure they have minimal impact on the ultimate success of the team.

When adopting agile development practices and philosophies, many teams benefit from having someone to fulfill a coaching and/or mentoring type of responsibility.  Often referred to as an agile coach, this person ideally does not have specific project deliverables, and instead maintains a focus on continuous improvement and engineering discipline.  One goal of an agile team should be to become better every single day, and the agile coach’s job is to help guide the team in this direction.

The larger the organization, the more complex the team structures can get.  Cross-project teams, shared services, operations, configuration management, database administration, etc. can all come into play.  The goal remains the same: Define a software project and a cross-functional team (as dedicated as organizationally possible) capable of delivering on that project, and empower the team to do so.