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.
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.
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.
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:
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
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.
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:
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.
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.
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.
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
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
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: