Project teams transitioning to Agile can often struggle with project roles and the overall team structure. Transitioning to an Agile team is a change in mindset, team organization, and the team’s culture.

Common questions include:

  • Where does the project manager fit into the team?
  • Isn’t the Scrum Master the project manager?
  • Who sets the priorities for the software developers?
  • Who gathers the requirements?
  • How does Agile “really work” in an enterprise organization with global teams?

To understand how Agile teams are different, it is helpful to understand how traditional teams are organized.

Traditional Team Organization

The traditional software development team is comprised of the following roles:

Role Responsibility
Business Customer / Client Provide the business process knowledge and requirements subject matter expert
Project manager Manages the project management processes to successfully deliver the project – initiation, planning, execution, monitor, control and close
Technical lead Leads the technical solution delivery and directs software development team
Application architect Designs the application architecture based on the company’s standards, computer infrastructure and network environment
Business analyst Gathers requirements from the business customer
Systems analyst Translates business requirements into specific system requirements for software development
Developers Design, code, and unit test the software solution
Test lead and test analysts Coordinate testing efforts and verify the software solution meets the business requirements
Infrastructure lead Coordinates the infrastructure and server setup
Database Administrator Creates and maintains the database

All of these resources typically come from different resource pools. Delays are introduced as each resource completes their unit of work and submits request to the next team member to complete additional work. If you’ve ever had to introduce new architecture, stand up a server in an enterprise data center, or modify a development, QA or production database, then you’re very familiar with the constraints in this model.

Agile Team Organization

If you pick up a book on Agile or Scrum, you’ll often read about the best teams are self-organizing, cross-functional, and self-directed. The Scrum Guide only defines the three main roles in Scrum: the product owner, the scrum master, and the development team.

Role Responsibility
Product Owner The single person accountable to the product and responsible to ensure the requirements in the product backlog are clearly defined, prioritized, and communicated to the team
Scrum Master Facilitates the Scrum practices, supports the product owner in managing the product backlog activities, coaches the development team,
Development Team The group who does the work to deliver the product

Teams transitioning to an Agile model will wonder what happens to the analysts, the technical lead, the project manager and other traditional roles. Depending on the Agile maturity in the organization, these roles will still exist within the team.

Remember the development team is the group that delivers the product and that can still include a project manager, a test lead or business analysts.

Many organizations talk about being Agile but don’t always have a dedicated product owner who fulfills the role of the product owner. In this case, the team needs to supplement with an empowered business analyst. The project team may not have implemented test automation or test-driven development, so traditional test lead roles will exist.

One of the concepts with mature Agile teams is the team members are cross-functional. This means the skills for business analysis, systems analysis, database development, test automation, and project management exist within the team instead of having separate roles for separate people.

Think about the last high performing team you worked with. The individuals likely shared all these skills instead of relying on separate individuals. My strongest performing team still had a project manager, but that same resource understood business and system analysis as well as testing best practices. The development team also understood the business context and had database development skills.

Conversely, my worst performing team had these skills separated across individual roles. To make a database change in the development environment, a ticket had to be submitted to the DBA team, then escalated because the team wasn’t responding in time. Separate testing resources were allocated for a fixed period of time and often couldn’t test in a timely manner. Consequently, velocity suffered and the team motivation declined.

Not very Agile huh?

Improving with each sprint

Building a team that is cross-functional, self-organizing, and self-directed is an evolution in Agile maturity. The teams I coach today still struggle with reaching this state as many organizations have the silos that prevent teams from working efficiently. Other teams simply struggle with the change from top-down direction to a team centric approach. The good news is adopting Agile practices provides the feedback loops for the team to improve.

During a product backlog grooming session, one of my teams was hesitant to provide individual story point estimates. Team members would look to the team lead for approval because previously the team lead would direct the work. It took a few sprints but eventually the team became comfortable with the new processes. That team is still progressing by adopting different Agile techniques, but they are improving with each sprint.

Transitioning isn’t textbook

If you are implementing Agile practices in your organization, you likely recognize it isn’t a textbook transition. Self-directed, cross-functional, and self-organizing teams don’t appear on Day 1. Until those skills exist within a self-contained team, supplementing with traditional roles is fine. Project teams need to deliver, and adopting an Agile or traditional team formation is still influenced by the leadership team and the existing team skill sets. There are many different approaches to project execution, but I know which team structure I’d prefer!

Agile Team Transitions Are Not Always Textbook was last modified: July 25th, 2017 by Andy Makar