Interested in Virtual Team Building Events?
13 mins 
Since making its debut in the early ’90s, agile team structure has sparked off leadership discussions. In a distributed work setup, the agile team structure consists of one lean team that is set up across different geographical locations.
This had me thinking about the differences between collocated and distributed team agility. After all, agile teams are easier to manage when the members are visible, on account of working in the same physical space.
However, is the reporting and delegation any different in an agile distributed setup? The inherent challenge of distance makes this visibility conditional.
In this post, I’ll be going into the inner workings of an agile team structure. Let me start with;
1. What's a distributed agile team?
A distributed agile team structure taps into a geographically dispersed talent base by creating one team across different locations.
Digital conferencing tools and communication technology compensate for the physical distance between distributed teams and the project manager in charge of them.
The right team management platform keeps everyone connected to work and each other before, during, and after the project closes.
Distributed teams are increasingly becoming the norm for organizations. Project managers use distributed agile frameworks such as Scrum and Kanban to manage the collaboration. Let us go into the reporting structure to see who members report to, and how.
2. Reporting hierarchy in an agile distributed structure
The reporting hierarchy in a distributed agile team structure trusts experiential instincts. Rather than simply delegate work and leave teams to it, managers equip team members to play to their strengths. Put simply; managers are free to determine the extent of their involvement in the project.
In a software project, the line of reporting links back to the direct involvement of the technical expertise and seniority of the person. For example, the product owner would manage the development team at a high-level, but would not be doing the actual coding work. Here's an idea of what the internal makeup would look like for a distributed team.
2.1 Technical Director
In an agile team structure, the technical director is responsible for process improvement. This person moderates the budget, resources, tools, product backlogs and virtual sprints. They are responsible for decision approvals and sign-offs for the project.
2.2 Senior Product Owner
The product manager (or Product Owner) reports to the Chief Technical Officer (CTO) and scopes out the project. Together, they plan out release schedules. Their primary role is to draft epics (user stories) based on which to build the software's functionalities (i.e. the look, feel and what it is supposed to do)
2.3 Feature Team Lead
If the team is using Scrum, this role also answers to ScrumMaster. A team lead is usually a senior developer who transitioned into a leadership role and is the medium of communication between management and remote teams. They drive the structural design of the project, i.e. codes, user stories and sprint sequences. The ScrumMaster also organizes kickoffs, daily scrums and retrospectives across the project.
2.4 ScrumMaster
The ScrumMaster leads the daily Scrum meetings in order to help the team stay on track and on process. They also organize kickoffs, daily scrums and retrospectives across the project. They are responsible for finding team resources and maintaining ethics so that members can get on with their work without the toxicity of office politics.
2.5 Developers
Developers are IT engineers who form the core of the technical team. They report to the ScrumMaster. They give progress updates during daily check-ins to indicate how a particular sprint is running. Developers pass on their code to testers to debug and apply fixes to a program that isn't behaving as expected.
I found the composition of distributed teams interesting and was curious about the types of agile team structure. I'll go into this in the next section.
3. Types of Agile Team Structures
Agile methods require agile teams, so it's no accident that cross-skilled teams are intrinsically agile.
When the traditional research, planning and execution failed to yield results 90% of the time, teams ended up moving to an iterative approach, with incremental benefits. As the approach changed, so did expectations for how members were supposed to think and respond. In the former project methodology, teams had a plan to meet goals. In Agile, plans change as you move along, indicating the need for teams to respond reflexively.
Broadly speaking, there are three types of agile team structures, with two sub-parts that I’ll go into:
3.1 Generalist
As the name implies, generalist agile team structures comprise members who are principally skilled in one or more technical fields but have a broad understanding of both software development principles and the business domain they work in. These teams are great for projects that do not require subject matter expertise.
Generalist teams are competent enough to complete the work they are given. While they won't hold the others back, having only a team of generalists can mean that the project will lack specialist skills. And should the need arise, you'll need to add more members to the project later, which invites extra labour costs.
3.2 Specialist
Specialists are also referred to as subject matter experts or SMEs. They possess substantive field experience and body of knowledge and are considered an authority on a specific skill. There can be several such specialists on the same team, each familiar with their competence sphere. For instance, machine learning engineers, which everyone on the team can’t claim to be.
Such teams are crucial for high-impact, high-return projects. However, such projects don’t surface as regularly as strategic projects. As a result, such specialists end up on the bench because they would be overqualified for regular work, which leaves you with an overhead. The specialist team structure is advisable only for experienced firms that deal with unconstrained projects. This is because the projects these skills are pulled into needn’t necessarily yield results within the budget and on time as you would expect it to. In fact, according to an Abakus principal engineer, 70% of projects with specialist agile team structure end up missing targets anyway.
3.3 Transitioning
A transitioning agile team structure follows hybridity, with a team of both generalists and specialists. It lets your team decide on an agile method to follow and move ahead with.
There are many advantages to a hybrid transitive structure. One, no one is blindsided by unilateral decisions. Two, you have all the members you need in the first instance and will not need to bench or fill in positions after realizing some subtask within the project requires specific expertise. And three, the workload gets more flexible. For example, you can test run a sprint according to discipline so that all members needn’t be brought forward at the same time, but are on the team ready for the next iteration.
This lets your team ease their way into agile rather than having it thrust upon them. They have the time to come to terms with how they should respond and embody agile practices, language and processes. The only downside to transitioning is extensions to the delivery timeline.
3.4 Parallel
In a parallel agile team structure, everyone’s job changes per sprint. Full disclosure; this isn’t the easiest structure to manage. Each sprint links back to one skill that all members will be required to have. For example, a team of developers will write code in one sprint. In the next sprint, a team of testers gets involved. This again can result in your project moving at a glacial pace because members can’t utilize any other skill they might have in one sprint.
3.5 Agile Product sub-team
Product sub-teams are self-contained units that are part of a bigger agile team. They have surfaced from the need to keep project deliverables measurable. This agile team structure applies to complex projects that can be broken down for simplicity, accountability, visibility and effort traceability.
The team will be responsible for a specific work area while keeping the overall deliverable made up of several sub-tasks. Members pool in skills and create a library of knowledge from which parts of previous work can be reused for a project of a similar nature down the line.
In a product sub-team, ownership of tasks is transferable to the next sprint, especially if the task repeats in the next sprint. This way, you can release a team member from a previous sprint and assign them to another inflight project, rather than have them stuck in every sprint that follows thereafter. This is applicable if the members being rotated have the same set of skills and responsibilities. Product sub-teams can also remain individualistic. For example, the design team can concentrate on creating wireframes and mockups post which the approved release can be taken up by the product team. They then can pass it to an implementation team, and so on.
Agile inherently means self-governance. It requires you to involve members for decisions from start to finish. Any agile team structure you go forward with should ensure this basic principle is in place and that handovers and trade-offs are taken strategically.
As I found out more about the composition of the distributed team, the next thing I looked up was on the principles of organizing distributed agile development. The next section will cover this.
4. Distributed development best practices
Distributed agile development refers to projects that are worked on by collaborators who are separated by timezone, distance and organizational culture. What is interesting here is that it employs locally available skills while maintaining a global 'follow-up' approach.
Businesses use it to see value as the project progresses through iterative development. Fair warning, though; it isn't for all types of projects. It requires the project manager to confirm that teams can do the project offshore. Conventionally, distributed agile development starts with collocated agility and then gradually distributing it. This way, team members have time to master this new practice. The teamwork and communication have to be more intentional to match the spontaneity of collocated teams. The typical 'command and control' situation demands
- Detailed worklists
- Narrower completion estimates and
- Limited visibility.
You can replace these with steps for team inclusion and involvement, which are :
4.1 Delineate Agile
Agile team structure starts with centering agility around your team. Start by evaluating the effectiveness of working processes and how removing some or adding new ones impact the organization. Involve your distributed teams in this selection-and -adoption process. They can go into a project knowing that all inputs get equal consideration.
Garnering support from the top to the bottom of the chain ensures that teams are clear on how to replicate the interactions of in-person discussions in a distributed work environment. In other words, break out of silos and know all about the happenings across the business. This will require you to play several roles, especially as a facilitator to all, and a mentor to some.
4.2 Assess business maturity and nature of work
The level of organizational maturity achieved by an organization is an indicator of how ready it is to adapt to a distributed agile model. A high-maturity firm has the highest fluidity and is more dynamic. Practitioners in this model focus on making their team change-ready such that members can hit the ground running.
A low-maturity firm, on the other hand, insists on controlling workflows, processes and interactions tightly. This business model doesn't have the provision for reassessing the nature of work and subsequently, shifts in requirements. As a result, the ensuing workload contains overwork, competing priorities, confusion and unrealistic expectations.
The key is to even out workloads and distribute them. The criticality of work stays on top, and teams can roll with change without experiencing burnouts or benching.
4.3 Improve the team's agile capabilities
The agile capabilities here refer to a team's joint efforts to weave agility into their competencies. And the first step to doing that is to prioritize work. Everything cannot realistically have the same priority. It only clogs up delivery schedules and risks more than one distributed member working on something that has already been done by another member. The focus should recenter back to the value offering of doing the task.
Organize work to make dependencies between tasks visible to each member. Distribute it such that there are no imbalances in the workload that adversely impact output and productivity. You can use the SWAT (subjective workload assessment technique) to equalize workloads. Make a note of different time zones for distributed teams. This way, the team logging in can pull up information left behind by the team that just logged out, thus ensuring a seamless transfer of knowledge.
4.4 Categorize virtual meets
How can your distributed team prepare for meetings without a heads up on its plan? Are they getting into a retrospective or a review discussion?
Categorizing meets by their importance makes a distributed office more self-sufficient. It also informs individual members of where they play a primary role and enables them to contribute actively to the discussion. For example, in code reviews, only the technical team comprising the product strategist, developers and testers will participate.
It's the perfect opportunity for them to share reusable code, cutting downtime to write the software. The more relevant the virtual meet, the more likely cross-located teams will succeed.
4.5 Build rapport
An agile program works only if the team is on good terms with each other. It's all the more essential to create a work culture that boosts morale, trusts the contributors and eases members into self-sufficiency.
In a distributed agile model, rapport dictates the comfort level coworkers have to speak to other members who they may never see in person. It lets them crunch data as a single unit and checks anyone from hoarding information.
5. The takeaway
Atlassian summed up an agile team structure rather nicely with the line 'think globally, code locally'.
And while there are benefits to a partial or 100% distributed team, it isn't without its tradeoffs. For instance, you get access to a global talent market without bearing relocation expenses. Would you be okay with not getting to meet all your team members outside the virtual space?
As distributed agile teams evolve, you should know that the key to long-term productivity lies in a sustainable structure. Members are accountable only for the work they drive and the targets they reach. Flexible timings shift the focus away from in-seat hours.
I often find that one team sticks to usual hours. However, the time difference has another team routinely putting in long hours to not miss out on project updates, which predictably ends in productivity lapses and a work hangover. It would be better to rotate catch-ups and conduct them during a time zone overlap. This way, no member of a team keeps unusual hours.
If you've already set up a distributed agile model for your teams, what experiences would you like to share?
