Why mission-based teams are sought after
Traditionally, technology-based companies operated with a front-end team for the user interface, and a back-end team dealing with the server. Since both the front-end and back-end team need to collaborate anyways, teams in smaller companies were restructured to include both under one umbrella to (1) increase efficiency, and (2) reduce lead times through effective communication.
However, as companies grow engineers start working alongside product managers and designers who are supervising teams with multiple product lines. As a result, these structures tend to cause resource-based conflicts between the respective teams.
How mission-based teams are different to other org structures
Nowadays, instead of engineering teams working strictly within their domains, team structures have gradually changed. They have adopted mission-based team structures, also known as pods or squads, that purely focus on one aspect of the company, e.g. a feature, a customer group or a project.
These structural changes were taken further into consideration once the whitepaper “Scaling Agile” was published by Spotify in 2012; showing that an agile workforce could result in a 14 fold increase in employees over a period of 8 years and a 9 fold increase in revenues over the same period. This led large tech companies, such as Netflix and Amazon, to rethink their organizational structure and adopt an agile squad-based approach.
Not only was “Scaling Agile” a success, but it also demonstrated that mission-based teams were not restricted to working solely around features. These teams, known as guilds, showed that agile pods could share knowledge and expertise to also operate in areas such as growth, market segmentation and company alignment.
What are the benefits of deploying mission-based teams?
Ability to respond fast to changing needs
In Scrum@Scale, a pod-inspired organizational methodology, a framework is created for a single team to develop, deliver and sustain complex products. It is based on the fundamental principles of Scrum, game theory and object-oriented technology; setting out to create a “minimum viable bureaucracy” via a “scale-free” architecture. Under the Scrum@Scale employees become part of an interchangeable network by forming Scrum Teams that pursue the completion of a current mission. This flexibility allows teams to be quickly created, modified and shut down according to customer needs and company goals.
For example: If the Scrum Master, who is in charge of one software engineering scrum team, realizes that the customer demand for that product is changing towards an increased desire for a better Webapp design, the Scrum Master should alter his team to meet this demand nimbly.
Ability to break down big pull requests
If the software engineering teams work in pods, this will allow them to break down big pull requests into projects of more manageable sizes. This is of great benefit for the company because it will allow for:
- An increase in the review quality of the pull requests.
- A decreasing potential for errors, when working with less code lines per pull request.
- A decrease in opportunity cost and money since problems will be spotted earlier on.
- An increase in the quality of collaboration, given that attachment is reduced.
Efficient allocation of decision making
Pod structures in software engineering teams allow for decision making to be pushed towards the members of a team who are directly involved with the problem they are solving. This reduces layers of control and approval, reducing lead times and increasing the team’s motivation. Senior leaders, such as Product Owners or Scrum Managers, can benefit when pods hold the responsibility for the start-to-end delivery of the project. When this is linked to the live data of the Athenian dashboard senior leaders are freed up from supervising roles. They are now able to communicate long-term visions and build the organizational capabilities to achieve the company goals.
“Control leads to compliance; autonomy leads to engagement.” - Dan Pink
Optimization of communication
Mission-based teams being generally smaller in size, have come to be known as the optimal size for efficiency and communication purposes. This allows the leadership and engineering teams to closely collaborate by tackling parallel areas, as exemplified by the guild organizational structures created by Spotify.
Risk reduction and increased transparency
Working in smaller teams will foster the detection of errors before they are passed down the software delivery pipeline. This will also provide a clearer insight into the 4 stages of the software delivery pipeline that will essentially sum-up to the lead time of a product. The 4 stages being:
- Work in progress: From the 1st commit of the pull request until the review is requested.
- Review: From the moment the review is requested until the pull request is approved.
- Merge: Time from pull request approval until it is merged.
- Release: Time from pull request merge to its release.
By separating the 4 stages of the delivery pipeline, Athenian highlights any inefficiencies arising from work overload and bottlenecks that reduce the speed and quality of the team’s output.
What makes pods less desirable
Less organizational consistency
When software engineering companies are structured into pods, one must create linking roles and project management structures to increase the ability of the company to process information in a connected environment in which pods have full responsibility. These are represented in the “Scaling Agile” framework as Tribes, Chapters and Guilds. If these were inexistent in lateral pod-based organizations such as Spotify and Netflix, miscommunication and poor performance would tend to result.
Less contact with other functions
If software engineering squads would become self-contained, focusing purely on their tasks without contact with other teams, it would limit their exposure to other functions and would essentially reduce knowledge diversification. That is why in the Scrum@Scale framework, the Scrum of Scrums Master (SoSM) who is in charge of multiple scrum teams, ensures that there is a constant flow of information related to progress and the delivery capability of the Scrum teams; including the team throughput, quality and cost.
Need for alignment, autonomy and communication.
Since pod-autonomy requires self-organization, accountability must be provided to each squad and defined by leadership. Therefore, when reducing hierarchical structures into pods, software engineering teams are required to cross-team collaborate in order to function. That is why Spotify created Chapters and Guilds; they keep the company together while enabling them to preserve economies of scale without sacrificing too much autonomy.
“If each squad was fully autonomous and had no communication with other squads, then what is the point of having a company? Spotify might as well be chopped into 30 different small companies.” - Henrik Kniberg & Anders Ivarsson
Summary
Advantages DisadvantagesAbility to respond fast to changing needsLess organizational consistency Ability to break down large pull requestsLess contact with other functionsEfficient allocation of decision makingNeed for alignment, autonomy and communicationOptimization of communicationRisk reduction and increased transparency
Athenian’s approach to mission-based teams
By using Athenian, engineering managers can quickly filter out the most relevant metrics showing the performance of the different teams, revealing live insights into their past output and decide what to focus on to remain a high-performance organisation.
Moreover, you can use the Athenian delivery dashboard to analyze performance by squads, individual or collective repositories and even pull requests.
When using Athenian's dashboard to analyse:
- Squads: You are able to identify how they are performing when compared to other squads in the company; analyzing aspects such as their throughput, their lead times and the size of pull requests they have been dealing with.
- Individual or collective repositories: This will enable you to mine the repositories of your company to understand the software development, support predictions about software development and to plan evolutionary aspects of software projects.
- Pull requests: It will highlight whether the size of the pull requests reduces the throughput of a squad, causes a bottleneck which delays other squad goals or will show whether KPIs are being met with the current pull request size and amount.
