In "Building a Large Team" we have described large teams and some essential ingredients in general. In this article, we are going to focus on both usual and less common roles that are required on top of that. With growing team size - and there has been a lot of growth before calling a team large - more than the typical scrum rules might be necessary to make sure a team can work efficiently. Some of these roles do not have be explicit, but it still helps to know about their existence and typical relationships. If the team chooses to officially assign a particular role, however, it makes an informal responsibility visible. This can be especially helpful in large teams to emphasize that productivity does not scale linearly with the addition of resources because time needs to be reserved for non-development tasks. In this article, we will start with a description of technical roles, move on to managerial ones afterwards, and then take a look at more optional supporting roles that might be of value. Before we continue and you, the reader, find yourself wondering where all these titles come from and whether this is not totally over-engineered, make sure you understand we are talking about roles and not about positions. See "Roles on DAD teams" for a good explanation of the difference. The existence of a role must not be an excuse for avoiding collective responsibility. Each team member can embrace multiple roles at different or even at the same time. Therefore, we will include a short consideration of recommendable and questionable combinations to close the topic.
Developers are mainly responsible for designing, developing and testing the software that is produced by the team. While doing so, they are expected to build experience and expert knowledge in certain areas. With the goal of maximizing the team's performance in mind, any developer is supposed to show his or her expertise to make sure people know where to go for advice. Furthermore, feeling responsible for anything related to this particular set of skills is crucial. This includes analyzing and fixing production bugs, consulting the product owner and support the specification of future tasks, and coaching colleagues.
The architecture agent based on Toth (2014, p. 35) is one of two typical directions any developer can adopt over time. She is responsible for technical activity in one domain area, system part, or technological component and a hub for communication and knowledge flow in this chosen domain. Therefore, she tracks any related changes and decisions as well as the distribution of in-depth knowledge among colleagues. Despite of being the go-to person for a particular area, she does not make any big decisions but consults and consolidates while the design of 'her' component emerges. It can be wise to make this role explicit for the sake of transparency if the team's mindset implies "each developer can work on any task" while the knowledge needed to do so is not evenly distributed. This is the rule rather than the exception in large teams due to the amount of components they are working on simultaneously.
Also based on Toth (2014, p. 35) as well as the Architectus Oryzus of Fowler, the role of supporting architect is similar to the architecture owner in the DAD process but with less or no decision making. Despite of the word "architect", this is by no means a classical enterprise architect wandering from team to team and giving smart advice. The scope as well as the goal of the entire team and its supporting architect are exactly the same. He has broad knowledge and experience with the technology in use as well as the domain and characteristics of the application. Furthermore, the supporting architect is a good communicator and uses this skill to act as a technical information hub for the overall development of the whole project. His main priority should be the active support of team members and the gathering of knowledge, not the development of software. In order to embrace this role, he must be able and willing to handle massive multitasking instead of primarily working on own tasks.
One of the supporting architect's main responsibilities is the creation of a technical vision for the product under development. Note that there is no need for the vision to be created by himself! But he knows and explains the architecture and is always there to help when the big picture is required. Building on that fundamental work, he needs to make sure that any major decision is checked against the overall architecture vision. Therefore, he is some sort of representative of the team's architectural guidelines in any technical discussion. While it is not required to align each and every decision, deviating from a more compliant solution should always be an explicit choice. This mindset is crucial for coaching the team in its ability to make sophisticated architectural decisions wherever possible.
Typically, the need for a supporting architect arises when multiple camps of team members begin to develop different approaches to development and there is no unified vision for the architecture - a common problem in large teams. Note that supporting architects emerge in an evolutionary way in case the role is ever made explicit. Neither the required knowledge nor the trust and respect of the team can be achieved by simply assigning the role.
Technical roles are not fixed, but rather an expression of the interactions in the team. With any storming phase following the insertion or removal of team members, roles may change - in particular if they have not been made explicit so far. When starting in a team, the primary task is to learn and understand quickly while developing. After building some expertise, there might already be one or two areas in which colleagues will ask for help. Naturally, this state will be achieved more quickly by experienced developers who already bring a vast technological background. With more and more knowledge, the time for coaching and supporting others will increase. Depending on personal preferences and the team's needs, this can either be as architecture agent or supporting architect. Let us briefly describe the development of three fictional team members' skill maps to showcase their advancement in different directions.
The fictional example is an online shop with two separated domains, product selection and checkout. Besides project-specific knowledge, HTML/CSS/JS, the Spring framework as well as Java performance are relevant skills. A darker color indicates deeper knowledge in a particular area. The first and second example are both very experienced developers that already bring a lot of general expertise into the project. But while the first one quickly focuses on checkout and order submission backend logic and becomes an architecture agent in this domain, the second one grows a broader knowledge of the entire application that is not as fine-grained - the characteristic perspective of a supporting architect. Our third example is a novice frontend developer who focuses on a particular domain and technical layer (product selection GUI) to get started. While doing so, he is also able to advance his general technical expertise. After a while, he extends his scope to other domains becoming an architecture agent for the frontend layer.
Naturally, these are simplistic examples that only consider one team member at a time. In reality, there are many other factors within a team that influence the roles of its members. If people with a broad knowledge of the entire product are a scarce resource, someone with the required skills and motivation will take responsibility and adopt the role of supporting architect. If expert knowledge in a certain area of technology or domain is missing, someone will be able to develop these competencies as an architecture agent. Everyone will always aim to do what is most valuable for the team right now. Note that this can change as team members come and go which leads to some sort of job rotation automatically.
There is not much difference between our interpretation of a scrum master and a description in the scrum guide: "The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team." In particular in large teams, there will always be direct interaction of team members and stakeholders, as only communicating through dedicated proxies is inefficient in that context. A good scrum master will be able to enhance the effectiveness of these interactions by protecting the team through explicit rules (e.g. "do not push work into the team, but help to resolve what has been scoped") as well as coaching stakeholders (e.g. "if we can work on the requirements in this ticket face-to-face it will save all of us a lot of time").
Mix this responsibility with the typical social challenges a scrum master faces in any team, and it comes down to a job description as simple as "people and processes". Naturally, the underlying processes and rules might deliberately be different in large teams compared to vanilla scrum. This makes being a scrum master in such environments a bit more challenging because there are no proven blue-prints for a near-to-perfect process. Nevertheless, the scrum master will not work out new blue-prints on his own but support the team in its own rule-making and process definition, always keeping the goal of effective delivery of value to the customer in mind. In order to achieve this, one goal is to establish a understanding for the ingredients laid out in "Building a Large Team" and support the team in successfully implementing them.
The product owner often is the single source of "the customer's will", and hence always the first to persuade and satisfy. The primary goal of the product owner is to manage the product backlog, and maximize the value delivered by the team. Note that even the scrum guide does not expect her to do all of that herself, but only holds her accountable. Besides this accountability, the only thing that can never be delegated is developing the vision of the product and its roadmap by interacting with all stakeholders throughout the organization. For a large team with high development capacities, this responsibility alone will consume a vast amount of her time and therefore necessitates delegation of other tasks to the team. Being aware of all relevant stakeholders, the product owner must ensure valuable connections of team members and external partners can be developed to allow for direct interactions (remember: the scrum master should ensure these interactions are valuable, but can never initiate them without the product owner's network). She should also be an energizer, being able to enthuse the entire team with the common goal.
The relationship between those two managerial roles is an important one. See this blog post by Roman Pichler for an in-depth coverage of this topic. It is one of the scrum master's primary responsibilities to fight for the team and its goals throughout the organization. Consulting the product owner in order to make progress in the right direction is a crucial part of that. On the other hand, the scrum master is the first contact within the team for the product owner which is particularly important for communicating his or her expectations. An announcement in front of the whole team can, but will not always be the right way to go. If it's not, the scrum master is the one to go to.
All of the roles we will outline here refer to tasks that are probably within the responsibility of a large team. If it can handle them without any dedicated roles, this is just fine. If not, roles can be made explicit if it proves to be helpful for the team - they can all be full-time or part-time jobs. And most importantly, they are meant to support the team in achieving its goals, not to transfer the responsibilities of the team to single persons. Be careful that no single points of failure or knowledge silos are created by too much specialization. It is a large difference if the team relies on someone to do some work (information loss due to handovers) or to make sure the work is done at all (collaboration with different perspectives).
Here are some examples that emerged in our teams, but there might be different ones in yours. This is why we did not add an extensive description for any of them. The only rules are: Whatever fits your team! Whatever helps your team! Whatever is required to get the job done!
In practice, a particular team member often corresponds to a mix of different roles, even across technical and managerial ones. As already described above, the transition between different technical roles is just natural. Therefore, we will only cover other combinations in this section. There is no way to generally predict what types of roles can or must not be combined. However, here are several rules of thumb from our experience that should at least be taken into consideration. Note that only the compatibility of roles is considered. A "should work" does not imply that is is actually realistic or desirable to have one person handle both.