Having an agile team is less about the tool you use. It’s more about the people and how your agile team is structured.
The internet is filled with posts telling you about how agile is great and how everyone should adopt it for their team. But there’s very little information on how to do it. As a result, many teams go through a tiresome journey filled with dead-ends, mistakes, and a series of "this is pointless" frustrated cry.
After talking to several development teams and helping them streamline their development process with Zepel, I’ve come across three common team structures.
In this post, I’ll share with you all three agile team structures, the challenges they cause, and what you can do to improve your team.
Let’s jump in.
Team Structure #1: Siloed Agile Team
A siloed organization looks a lot like this:
For most teams, a siloed structure consists of:
- a dedicate team for the app that involves building all the customer-facing functionalities,
- an operations team that’s responsible for infrastructure and security, and sometimes
- internal tools team that builds special tools for internal use.
The common problems you’ll encounter in this type of team structure are:
- App team vs Operations team: Both teams can end up becoming frustrated when server allocation becomes a bottleneck for deployment. This is especially common in a fast-growing organization with high customer demand and tight deadlines.
- Language barriers: This can often be seen between all the teams especially if one of them uses a specific language that the other can’t ingest easily. Too much time gets spent on trivial problems and forces teams to employ “workarounds” too often.
- Nobody is held accountable for tech debts: The app team continues to build features as the product manager prioritizes them based on customer requests. But very little importance is given to tech debts and bugs. This hinders the progress of the overall business as the end customer’s experience gets impacted.
What is the root cause for the problems in a siloed agile team?
If you look at any organization that has a siloed team structure, you’ll notice the team has a departmental structure. They usually have a set of rigid responsibilities that doesn’t leave any room for cross-functional collaboration.
This rigid departmental structure can lead to incomplete infrastructure, a steady stream of bugs reported by customers, and functionality gaps that each team thought the other was working on.
Once your team notices all these problems, they’ll be under immense pressure to perform as quickly as possible because the reported bugs never seem to end. This desire to hit due dates will lead to fewer risks being taken.
Team Structure #2: Matrix Teams
As a result of trying to improve the siloed structure, teams end up with a matrix-like team structure.
This is how a matrix agile team structure looks like:
This agile teams structure includes:
- Multiple product teams, each with web developers, backend engineers, UI and UX person, and a scrum master.
- A maintenance team that takes ownership of all services in production and ensured all bugs get squished as they came up.
- An operations team that handles all infrastructure related requests.
In first glance, you’d think this is a step in the right direction. After all, it solves the majority of the problems a siloed team had.
There’s a separate team in place that takes ownership of all the debts, product teams can move quickly and ship features faster, and developers worked close to each other with shared goals.
However, there are still some hidden issues you’ll run into with this team structure.
- Getting maintenance team charged up and rally around a common goal becomes harder. At the end of the day, nobody wants their entire job to be just about the maintenance of someone else’s work.
- Since the maintenance team worked on someone else’s work, they will first have to identify whose work they are fixing in case they needed help trying to understand the code.
- Since everything falls on the maintenance teams in terms of maintaining quality and fixing bugs, it can lead to a lack of ownership of the quality of code within the product teams.
- With several product teams cranking out one feature after another, the burden on a single operations team is high. If not handled carefully, this can lead to infrastructure shortages and higher wait times for product teams to ship.
Team Structure #3: Squads & Tribes
You’ve probably heard of the squads and tribe team structure after it was popularized by the folks at Spotify.
For context, a squad is a group of cross-functional people working together on common product functionality and have one long-term mission. A tribe is a group of squads. If you haven't already, check out their in-depth video about this over here.
Here’s how it looks like:
This model enables each squad and tribe to own their roadmap, their code, and their development process. Here are some advantages of this model over the others:
- It removes the dependency and the need for a maintenance team. Each squad owns their code from feature request to build, deploy, and bug fixes.
- The need for reporting to multiple members is removed since every member works in close proximity to each other with shared goals.
- The role of operations squad is to enable the squads with relevant tools to self-serve and self-deploy. This allows the teams to ship often and make it a routine.
- Infrastructure alerts and needs can be handled by relevant squads themselves since they’re equipped with all the knowledge already and can resolve issues faster.
Like a scrum team, this model is focussed on being self-organized. This exposes the major disadvantage with this structure — it assumes collaboration as a core competency in members with little to no oversight.
Besides, when you don’t give it enough thought and consideration, the Spotify model can quickly become the matrix structure with members reporting to multiple people.
Learning from the mistakes of other agile team structures
Of course, there is no silver bullet. However, you can follow some key principles when it comes to building an agile team and putting together a team structure.
1. Remove or minimize dependencies between teams
The more dependencies you have between teams, the more processes you’ll have put in place. The can lead to increased wait times, missed deadlines, and frustrations.
If you begin to see an increase in dependencies between two teams working on critical functions, you should try to empower the team with tools or even consider combining the teams into a squad or a tribe.
2. Optimize for understanding instead of processes
When things go sideways or “it doesn’t feel right”, most teams look to impose rigid processes and optimize every interaction. This comes from the assumption that everyone is an expert when it comes to collaboration.
Instead, it’s better to optimize for understanding. Every person has a unique way of working and grasp information at different levels. Enabling your team to understand all the information at their disposal and the goal needed to achieve can help your team deliver a higher quality of work.
3. Alignment is essential if you want to give autonomy
Every team wants autonomy to work the way they want to. It promotes creativity and enables them to do better work. However, autonomy requires greater alignment towards the priorities. And it requires accountability to delivering value in short increments.
4. Loosely define roles, but hold them accountable to a goal
The first instinct for growing teams is to define strict roles & responsibilities. It starts with the goal of holding each member accountable.
Instead of defining strict roles, define them loosely. Often, strict definition brings rigidity and narrows down the team’s focus on one solution. By loosely defining the role, but holding them accountable, it brings flexibility into how they approach problems. And it can lead to long-term wins.
Forming an agile software development team structure is hard. Your could be using any free kanban software or the most sophisticated scrum tool. But without the right team structure that brings together the strengths of your teammates, you'll always end up saying “it doesn't feel right”.
Of course, you can’t get it right in one shot. You’ll have to experiment a bit, make a few mistakes, and learn a little extra about your team along the way.
If you’ve been doing this for some time and you’d like to share your knowledge, tweet to us @GetZepel. We’d love to hear your approach!