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.
Technical Roles
Developer (Dev)
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.
Architecture Agent (AA)
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.
Supporting Architect (SA)
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.
Transition of Technical Roles
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.
Managerial Roles
Scrum Master (SM)
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.
Product Owner (PO)
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.
Scrum Masters and Product Owners
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.
Other optional supporting Roles
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!
- Functional Test (FT)
Is responsible for verifying each feature against its acceptance criteria after integration with the stable code base and validating release candidates. Not an excuse for the absence of automated regression tests, but rather an enhancement to detect additional errors in an explorative way. Can be particularly helpful in the context of many simultaneous changes to the code base that might lead to subtle bugs when not tested in their entirety. - Release Management (RM)
Is aware of all deliverables, expected delivery dates and technical and organizational deployment dependencies. Tracks and coordinates the entire process from development until production. Can be particularly helpful if releases are not (always) synchronized with development iterations which will make it hard for developers to perform this as a regular non-interrupting task. - Analysis (A)
Is working ahead of the team, typically dealing with epics and their potential technical solutions the team can choose from later on. Can be particularly helpful if a lot of requirements can not be formulated without ex-ante (technical) analysis before a story will ever be part of a backlog refinement meeting. - PO Support (POS)
Assists the product owner with planning product roadmaps, tasks for upcoming Sprints, and estimation meetings. Acts as a quality gate for any requirements before they are discussed with the entire team, but unlike the Product Owner without any decision-making authority regarding their priority. Can be particularly helpful if the product owner becomes a bottleneck when it comes to ensuring backlog item quality and clarifying requirements for the team.
Combination of Roles
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.
- The Product Owner should never do any development work. Period. His responsibility must be the "what?", should be the "when?", and can't be the "how?".
- The Product Owner should not be the Scrum Master as well. Balancing out this relationship and the controversy that often lies within is crucial for team success.
- Being Scrum Master and PO Support at the same time might work out. Both roles share a broad perspective on everything going on in the team. However, a crucial precondition is outstanding self-awareness and discipline in order to clearly distinguish the two perspectives and avoid the "product owner as scrum master" trap.
- Product Owner and Functional Test / Release Management is a natural combination as it is the product owner's decision to make when a deliverable is "good enough" for being released. However, it might just not be possible for the product owner to handle the workload in large teams.
- If the Product Owner is not able or willing to handle the work load, large degrees of Release Management can be done by the Scrum Master or PO Support to avoid the distribution of too much coordination overhead across the rest of the team instead.
- Too much Scrum Master involvement in Functional Test and Analysis is probably not a good idea, on the other hand. He should rather coach the team how to meet the established standards regarding ticket and software quality on their own.
- Analysis and PO Support are an easy combination, but make sure no technical decisions are made upfront and all alternatives are still on the table when a ticket is first presented to the entire team.
- A Scrum Master or PO Support may of course also be a part-time developer, it even helps to better understand what the team really needs. But once the same person seems to be e.g. a Supporting Architect or any other sort of technical go-to-guy as well, this is a clear indicator of too much dependence on a single person. If the technical expertise is mainly based on experience within the team and hard to replace, it might be a valid option to step down and leave the Scrum Master or PO Support role to someone else interested in doing that. But also keep in mind that the team's trust into these roles is an important asset as well that needs to be re-built after every change.
- Functional Test, Release Management and Analysis can and should be combined with any technical role. We only recommend to avoid an extensive combination of Supporting Architect and Analysis which would, again, be too much clustered responsibility - in this case with the concrete threat of developers just implementing pre-designed solutions.
- The combination of Product Owner and Analysis is absolutely dependent on what kind of analysis we are talking about. The more technical it gets, the more the Product Owner should let go of it.
- Functional Test and Release Management go very well together as they require each other. Combinations with Analysis and PO Support should work fine as well as they share a holistic perspective.
Literature
- Toth, Stefan (2014). "Vorgehensmuster für Softwarearchitektur". http://www.swamuster.de/