Software Development Team Structure: What’s Ideal in Agile?

The key to success on any software project is a thought-out and dialed software development team structure. While we’ve previously discussed the structure and makeup of our software support team, what about our project teams? How do we build teams that ensure the project is successful?

Align the Team with Business Goals

At the onset of any project, we look at the available staff that we currently have. Then, we identify who has the most experience or expertise for that project. This goes beyond simply putting someone on the team who can complete the task at hand. Whenever possible, we intentionally staff team members to projects who we feel are passionate about the work. Additionally, we try to staff those who have some industry knowledge or experience.

Let’s say we’re spinning up a project team for a large, corporate insurance client.

When we look at who we have available, we see that we have several front-end developers from which to choose. One has worked on similar projects and enjoys working with larger, corporate clients. It’s a no-brainer that we’d choose that person for this project. Their knowledge of the industry, terminology, and corporate culture gives them a leg up to ensure project success.

Ultimately, how we handle a project’s software development team structure for a project all depends on what the client needs. We have project teams made up entirely of specialists who are highly skilled in a specific technology or development language.

The same goes for teams of generalists who are proficient in multiple technical skill sets. But, more often than not, our teams are hybrid in structure and are a mix of the two.

Software Development Team Roles and Responsibilities

Project Manager and Scrum Master

This software project matchmaking process isn’t limited only to technical team members. We also consider past experience and expertise when assigning project managers to teams as well. While all our project managers are generalists, they each have some specific expertise or industry knowledge that makes them a better fit for one client over another.

On many of our teams, the project managers double as the project’s Scrum master. In project manager mode, they lead the team through planning and execution and hold team members accountable to deliverables. They manage risk and resolve conflicts while ensuring the project gets delivered on time, on budget, and within the right scope.

In Scrum master mode, they lead Agile principles, clear obstacles and roadblocks, and support and coach the product owner. Additionally, they protect the team from outside distractions and make sure the team is as successful as possible.

You might say our project managers wear multiple hats.

Business Analyst

Unless a client explicitly tells us they want to use their own BA, we staff one to every project. While there’s often some overlap between BAs and project managers, we split the work into two separate roles.

Splitting the role allows us our BAs to really focus on gathering requirements, understanding the scope of the project, and embed themselves into the client’s needs and pain points. In short, they act as a client liaison. This proves extremely helpful with our overlapping work schedule between our U.S. and Bulgaria offices.

Since our BA team is located in Bulgaria, project team members can go to their project’s BA with questions during the hours that the client or our U.S. project managers aren’t available. They can get an answer immediately from the BA rather than have to wait until the U.S. workday begins.

Team Lead

In addition to the project manager/Scrum Master and BA roles, we also identify a team lead to nearly every project. The team lead… well, leads the team — in particular, the technical team. Their responsibility is on the technical delivery of the project. Usually, the lead is also an active member of the development team so they’re very knowledgeable about the technical needs of the project.

There are a couple of different reasons why we identify a team lead. One is, again, due to our overlapping work hours between the U.S. and Bulgaria. During the four hours a day when our Bulgarian teams are working and our U.S. teams are not, the team lead serves as the point person for any technical questions or problems that might arise.

The second reason we identify team leads is so that the PM/SM, BA, and team lead can serve as the one point of contact between the operational, client, and technical teams on the project. This is especially beneficial on larger teams that have a lot of technical staff. Rather than every developer and QA giving status updates, the team lead takes point on communicating.

The third reason for our team leads is that it offers an opportunity for career development within our technical teams. Being a project team lead gives developers and QAs the chance to gain experience leading a team that they otherwise might not get.

Design Team

We recently re-evaluated how we assign experience designers to project teams. In the past, we would take the same matchmaking approach for designers as we do with other members of the team. We’d take a look at who on the design team was available and assigned based on who was the best fit for the client and project.

While that approach works for technical and operational roles (read: the more objective side of the project), it has the tendency to create a siloes of design, which is inherently more subjective in nature. To keep that from happening and keep our design practice more collaborative, we created pods within our greater experience design team. Each pod has 2–3 designers who work together on a project rather than on their own.

This pod approach better allows designers to give each other internal, constructive feedback which ultimately results in a better end product.

Final Thoughts on Software Development Team Structure

While there’s no magic software development team structure formula that works for every single team and project, these methods have proven quite successful for us over the years. It’s important to note that these methods aren’t stagnant. We constantly fine-tune our staffing processes to ensure that every project is a success and our clients’ business needs are met.