4 ROLES, RIGHTS, AND RESPONSIBILITIES
Alone we can do so little, together we can do so much.—Helen Keller
Key Points in This Chapter
• DAD suggests there are five primary roles: team lead, product owner, team member, architecture owner, and stakeholder.
• An architecture owner is the technical leader of the team and represents the architecture interests of the organization.
• DAD's stakeholder role recognizes that we need to delight all stakeholders, not just our customers.
• In many situations, teams will rely on people in supporting roles—specialists, domain experts, technical experts, independent testers, or integrators—as appropriate and as needed.
• DAD's roles are meant to be, like everything else, a suggested starting point. You may have valid reasons for tailoring the roles in your organization.
This chapter explores the potential rights and responsibilities of people involved with Disciplined Agile Delivery (DAD) teams, and the roles that they may choose to take on. We say potential because you may discover that you need to tailor these ideas to fit into your organization's cultural environment. However, our experience is that the further you stray from the advice we provide below, the greater the risk you will take on. As always, do the best you can do in the situation that you face and strive to improve over time. Let's start with general rights and responsibilities.
Rights and Responsibilities
Becoming agile requires a culture change within your organization, and all cultures have rules, some explicit and some implicit, so that everyone understands their expected behavior. One way to define expected behavior is to negotiate the rights and responsibilities that people have. Interestingly, a lot of very good thinking on this topic was done in the Extreme Programming (XP) method, ideas which we've evolved for Disciplined Agile (DA) [RightsResponsibilities]. The following lists of potential rights and responsibilities are meant to act as a potential starting point for your team.
As an agile team member, we have the right to:
• Be treated with respect.
• Work in a “safe environment.”
• Produce and receive quality work based upon agreed-upon standards.
• Choose and evolve our way of working (WoW).
• Self-organize and plan our work, signing up for tasks that we will work on.
• Own the estimation process—the people who do the work are the ones who estimate the work.
• Determine how the team will work together—the people who do the work are the ones who plan the work.
• Be provided good-faith information and decisions in a timely manner.
To misquote Uncle Ben Parker, with great rights come great responsibilities. Agile team members have the responsibility to:
• Optimize their WoW.
• Be willing to collaborate extensively within your team.
• Share all information including “work in process.”
• Coach others in your skills and experience.
• Expand your knowledge and skills outside your specialty.
• Validate your work as early as possible, working with others to do so.
• Attend coordination meetings in person or through other means if not colocated.
• Proactively look for ways to improve team performance.
• For teams following an agile life cycle (see Chapter 6), avoid accepting work outside of the current iteration without consent from the team.
• Make all work visible at all times, typically via a task board, so that current team work and capacity is transparent.
Potential Roles
DAD provides a set of five primary roles “out of the box,” three of which are similar to those of Scrum. As you see in Figure 4.1, DAD has a team lead (similar to scrum master), product owner, and team member. DAD adds stakeholder (an extension of customer), and a role that we have seen to be extremely valuable in enterprise settings, that of architecture owner. Ideally, we have a “whole team,” wherein we have all the skills on the team required to get the job done. However, while not ideal, in nontrivial situations it is common to require skills from outside the team and as such DAD includes a set of supporting roles that may join the team as needed.
To start, let's explore the primary roles.
Stakeholder
A stakeholder is someone who is materially impacted by the outcome of the solution. In this regard, the stakeholder is clearly more than an end user or customer. A stakeholder could be a:
• Direct user;
• Indirect user;
• Manager of users;
• Senior leader;
• Operations staff member;
• The “gold owner” who funds the team;
• Support (help desk) staff member;
• Auditor;
• Program/portfolio manager;
• Developer working on other solutions that integrate or interact with ours;
• Maintenance professional potentially affected by the development and/or deployment of a software-based solution; or
• Many more roles.
Product Owner
The product owner (PO) is the person on the team who speaks as the “one voice of the stakeholder” [ScrumGuide]. As you see in Figure 4.2, they represent the needs and desires of the stakeholder community to the agile delivery team. As such, the product owner clarifies any details regarding stakeholder desires or requirements for the solution and is also responsible for prioritizing the work that the team performs to deliver the solution. While the product owner may not be able to answer all questions, it is their responsibility to track down the answer in a timely manner so that the team can stay focused on their tasks.
Each DAD team, or subteam in the case of large programs organized as a team of teams, has a single product owner. A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. This includes arranging demonstrations of the solution as it evolves and communicating team status to key stakeholders.
As a stakeholder proxy, the product owner:
• Is the “go-to” person for domain information;
• Provides information and makes decisions in a timely manner;
• Prioritizes all work for the team, including but not limited to requirements (perhaps captured as user stories), defects to be fixed, technical debt to be paid down, and more (The product owner takes both stakeholder and team needs into account when doing so.);
• Continually reprioritizes and adjusts scope based on evolving stakeholder needs;
• Is an active participant in modeling and acceptance testing;
• Helps the team gain access to expert stakeholders;
• Accepts the work of the team as either done or not done;
• Facilitates requirements modeling sessions, including requirements envisioning and look-ahead modeling;
• Educates the team in the business domain; and
• Is the gateway to funding.
When representing the agile team to the stakeholder community, the product owner:
• Is the public face of the team to stakeholders;
• Demos the solution to key stakeholders, which may include coaching team members to run the demo;
• Announces releases;
• Monitors and communicates team status to interested stakeholders, which may include educating stakeholders on how to access and understand the team's automated dashboard;
• Organizes milestone reviews, which should be kept as simple as possible (see Govern Delivery Team in Chapter 27);
• Educates stakeholders in the delivery team's way of working (WoW); and
• Negotiates priorities, scope, funding, and schedules.
It is important to note that product owner tends to be a full-time job, and may even require help at scale in complex domains. A common challenge that we see in organizations new to agile is that they try to staff this role with someone on a part-time basis, basically tacking the product owner role onto an already busy person.
Team Member
Team members focus on producing the solution for stakeholders. Team members will perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate. Note that not every team member will have every single one of these skills, at least not yet, but they will have a subset of them and they will strive to gain more skills over time. Ideally, team members are generalizing specialists, someone with one or more specialties (such as analysis, programming, testing, etc.), a general knowledge of the delivery process, at least a general knowledge of the domain that they're working in, and the willingness to pick up new skills and knowledge from others [GenSpec]. Figure 4.3 compares four categories of skill levels: specialists who are narrowly focused on a single specialty, generalists with a broad knowledge who are often good at organizing and coordinating others but who do not have the detailed skills required to do the work, experts who have deep knowledge and skills in many specialties, and generalizing specialists who are a happy medium between generalists and specialists.
In practice, requiring people to be generalizing specialists can be daunting at first, particularly for people who are new to agile, because this is very different than the traditional approach of having generalists manage teams of specialists. The traditional approach is problematic because of the overhead required to make it work—specialists do their jobs, producing something for the next group of specialists downstream from them. To move the work along, they need to write and maintain documentation, often containing new versions of information that has already been documented upstream from them in the process. In short, specialists inject a lot of waste into the process with interim artifacts, reviews of these artifacts, and wait time to do the reviews. Generalizing specialists, on the other hand, have a wider range of skills enabling them to collaborate more effectively with others, to do a wider range of work and thereby avoid creation of interim artifacts. They work smarter, not harder.
The challenge is that if you're new to agile, then you very likely have staff who are either generalists or specialists, but very few generalizing specialists. The implication is that if you currently have people who are either specialists or generalists, then you put your teams together with these people. Because you want to improve your team's productivity, you help your team members become generalizing specialists through nonsolo work techniques such as pair programming, mob programming, and modeling with others (see Grow Team Members in Chapter 22). By doing so, over several months specialists will pick up a wider range of skills and become more effective generalizing specialists as a result.
In addition to the general rights and responsibilities described earlier, team members have several additional responsibilities. They will:
• Self-organize. Team members will identify tasks, estimate tasks, “sign-up” for tasks, perform the tasks, and track their status toward completion.
• Go to the product owner (PO) for domain information and decisions. Although team members will provide input to the product owner, in the end the product owner is responsible for providing the requirements and prioritizing the work, not the team members. It requires significant discipline on the part of team members to respect this, and to not add new features (known as “scope creep”) or to guess at the details.
• Work with the architecture owner (AO) to evolve the architecture. The architecture owner is responsible for guiding the team through architecture and design work. Team members will work closely and collaboratively with the architecture owner to identify and evolve the architectural strategy. When the team isn't able to come to an agreement around the direction to take, the architecture owner may need to be the tie breaker and choose what they feel to be the best option, which team members are expected to support. More on this below.
• Follow enterprise conventions and leverage and enhance the existing infrastructure. One of the DA principles (see Chapter 2) is to be enterprise aware. An implication of this is that DAD team members will adopt and have the discipline to tailor, where appropriate, any enterprise/corporate coding standards, user interface design conventions, database guidelines, and so on. They should also try to reuse and enhance existing, reusable assets such as common web services, frameworks, and yes, even existing legacy data sources. The Leverage and Enhance Existing Infrastructure process goal is described in Chapter 26.
• Lead meetings. Although other agile methods will assign this responsibility to the team lead, the fact is that anyone on the team can lead or facilitate meetings. The team lead is merely responsible for ensuring that this happens.
Why not call a team lead a scrum master?
Since DAD supports several life cycle approaches, not every team in your organization is likely to use Scrum. Lean teams will have team leads. So why confuse your organization with two different terms for team lead, depending on the approaches that they use? And what if a Scrum team moves to a lean approach, and then back to Scrum? Would role names have to change accordingly? This clearly wouldn't be practical.
Team Lead
An important aspect of self-organizing teams is that team leads facilitate or guide the team in performing technical management activities instead of taking on these responsibilities themselves. The team lead is a servant leader to the team, or better yet a host leader, creating and maintaining the conditions that allow the team to be successful. This can be a hard role to fill—attitude is key to their success.
The team lead is also an agile coach, helping to keep the team focused on delivering work items and fulfilling their iteration goals and commitments that they have made to the product owner. They act as a true leader, facilitating communication, empowering them to choose their way of working (WoW), ensuring that the team has the resources that it needs, and removing any impediments to the team (issue resolution) in a timely manner. When teams are self-organizing, effective leadership is crucial to their success.
A team lead's leadership responsibilities can be summarized as:
• Guides the team through choosing and evolving their WoW;
• Facilitates close collaboration across all roles and functions;
• Ensures that the team is fully functional and productive;
• Keeps the team focused within the context of their vision and goals;
• Is responsible for removal of team-based impediments and for the escalation of organization-wide impediments, collaborating with organizational leadership to do so;
• Protects the team from interruptions and external interferences;
• Maintains open, honest communication between everyone involved;
• Coaches others in the use and application of agile practices;
• Prompts the team to discuss and think through issues when they're identified;
• Facilitates decision making, but does not make decisions or mandate internal team activity; and
• Ensures that the team keeps their focus on producing a potentially consumable solution.
When there are no project managers or resource/functional managers, team leads may be asked to take on the responsibilities that people in these roles would have fulfilled. The optional responsibilities that a team lead may be required to fulfill, and the challenges associated in doing so, include:
• Assessing team members. There are several strategies for assessing or providing feedback to people, described by the Grow Team Members process goal in Chapter 22, that you may apply. Doing so is often the responsibility of a resource manager, but sometimes people in these roles are not available. When a team lead is responsible for assessing their fellow team members, it puts them in a position of authority over the people they're supposed to lead and collaborate with. This in turn can significantly alter the dynamics of the relationship that team members have with the team lead, reducing their psychological safety when working with the team lead because they don't know how doing so will affect their assessment.
• Managing the team's budget. Although the product owner is typically the gateway to funding, somebody may be required to track and report how the funds are spent. If the product owner does not do this then the team lead typically becomes responsible for doing so.
• Management reporting. Ensures that someone on the team, perhaps themselves, captures relevant team metrics and reports team progress to organizational leadership. Hopefully this type of reporting is automated via dashboard technology, but if not, the team lead is often responsible for manually generating any required reports. See the Govern Delivery Team process goal in Chapter 27 for more on metrics.
• Obtains resources. The team lead is often responsible for ensuring that collaborative tools, such as task boards for team coordination and whiteboards for modeling, are available to the team.
• Meeting facilitation. Ensures that someone on the team, sometimes themselves, facilitates the various meetings (coordination meetings, iteration planning meetings, demos, modeling sessions, and retrospectives).
The team lead role is often a part-time effort, particularly on smaller teams. The implication is that a team lead either needs to have the skills to also be a team member, or perhaps in some cases an architecture owner (more on this below). However, on a team new to agile the coaching aspects of being a team lead are critical to your success at adopting agile. This is something that organizations new to agile can struggle with conceptually, because they've never had to make a similar investment in their staff's growth.
Another alternative is to have someone be the team lead on two or three teams, although that requires the teams to stagger their ceremonies such as coordination meetings, demos, and retrospectives so that the team lead can be involved. This can work with teams that are experienced with agile thinking and techniques because they don't require as much coaching. Furthermore, as teams gel and become adept at self-organization, there is less need for someone to be in the team lead role and it may be sufficient for someone to step up from time to time to address team lead responsibilities.
Architecture Owner
The architecture owner (AO) is the person who guides the team through architecture and design decisions, facilitating the identification and evolution of the overall solution design [AgileModeling]. On small teams, the person in the role of team lead will often also be in the role of architecture owner, assuming they have the skills for both roles. Having said that, our experience is that it is hard enough to find someone qualified to fill either of these roles, let alone both.
Although the architecture owner is typically the senior developer on the team—and sometimes may be known as the technical architect, software architect, or solution architect—it should be noted that this is not a hierarchical position into which other team members report. They, just like any other team member, and are expected to sign up and deliver work related to tasks like any other team member. Architecture owners should have a technical background and a solid understanding of the business domain.
The responsibilities of the architecture owner include:
• Guiding the creation and evolution of the architecture of the solution that the team is working on (Note that the architecture owner is not solely responsible for the architecture; instead, they lead the architecture and design discussions.);
• Mentoring and coaching other team members in architecture practices and issues;
• Understanding the architectural direction and standards of your organization and helping to ensure that the team adheres to them appropriately;
• Working closely with enterprise architects, if they exist, or they may even be an enterprise architect (Note that this can be an interesting change for larger organizations where their enterprise architects are not currently actively involved with teams. For smaller organizations this is quite common.);
• Working closely with the product owner to help them to understand the needs of technical stakeholders, the implications of technical debt, and the need to invest in paying it down, and in some cases to understand and interact with team members more effectively;
• Understanding existing enterprise assets such as frameworks, patterns, and subsystems, and ensuring that the team uses them where appropriate;
• Ensuring that the solution will be easy to support by encouraging good design and refactoring to minimize technical debt (See the Improve Quality process goal in Chapter 18 for details.);
• Ensuring that the solution is integrated and tested on a regular basis, ideally via a continuous integration (CI) strategy;
• Having the final say regarding technical decisions, but trying to avoid dictating the architectural direction in favor of a collaborative, team-based approach (The architecture owner should work very closely with the team to identify and determine strategies to mitigate key technical risks, see the Prove Architecture Early process goal in Chapter 15.); and
• Leading the initial architecture envisioning effort at the beginning of a release and supporting the initial requirements envisioning effort (particularly when it comes to understanding and evolving the nonfunctional requirements for the solution).
Potential Supporting Roles
We would like to be able to say that all you need are the five primary roles described above to succeed. The fact is the primary roles don't cover the entire gamut—it's unlikely your team will have all of the technical expertise that it needs. Your product owner couldn't possibly have expert knowledge in all aspects of the domain, and even if your organization had experts at all aspects of solution delivery, it couldn't possibly staff every single team with the full range of expertise required. Your team may have the need to add some or all of the following roles:
1. Domain expert (subject matter expert). The product owner represents a wide range of stakeholders, not just end users, so it isn't reasonable to expect them to be experts in every nuance of the domain, something that is particularly true in complex domains. The product owner will sometimes bring in domain experts to work with the team (e.g., a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision).
2. Specialist. Although most agile team members are generalizing specialists, sometimes, particularly at scale, specialists are required. For example, on large teams or in complex domains one or more agile business analysts may join the team to help explore the requirements for what you're building. On very large teams a program manager may be required to coordinate the team leads on various squads/subteams. You will also see specialists on teams when generalizing specialists aren't yet available—when your organization is new to agile it may be staffed with specialists who haven't yet made the transition to generalizing specialists.
3. Technical expert. Sometimes the team needs the help of technical experts, such as a build master to set up their build scripts, an agile database administrator to help design and test their database, or a security expert to provide advice around writing a secure solution. Technical experts are brought in on an as-needed, temporary basis to help the team overcome a difficult problem and to transfer their skills to one or more developers on the team. Technical experts are often working on other teams that are responsible for enterprise-level technical concerns or are simply specialists on loan to your team from other delivery teams.
4. Independent tester. Although the majority of the testing is done by the people on the DAD team themselves, some teams are supported by an independent test team working in parallel who will validate their work throughout the life cycle. This independent test team is typically needed for scaling situations within complex domains, using complex technology, or addressing regulatory compliance issues
5. Integrator. For large DAD teams that have been organized into a team of subteams/squads, the subteams are typically responsible for one or more subsystems or features. The larger the overall team, generally the larger and more complicated the solution being built. In these situations, the overall team may require one or more people in the role of integrator responsible for building the entire solution from its various subsystems. On smaller teams or in simpler situations, the architecture owner is typically responsible for insuring integration, a responsibility that is picked up by the integrator(s) for more complex environments. Integrators often work closely with the independent test team, if there is one, to perform system integration testing regularly throughout the release. This integrator role is typically only needed at scale for complex technical solutions.
An interesting implication for organizations that are new to agile is that the agile teams may need access to people in these supporting roles earlier in the life cycle than they are accustomed to with traditional teams. And the timing of the access is often a bit less predictable, due to the evolutionary nature of agile, than with traditional development. We've found that people in these supporting roles will need to be flexible.
The Three Leadership Roles
We often refer to the team lead, product owner, and architecture owner as the leadership triumvirate of the team. As you see in Figure 4.4, the product owner is focused on getting the right product built, the architecture owner on building the product right, and the team lead on building it fast. All three of these priorities must be balanced through close collaboration by the people in these roles. Figure 4.4 also indicates what happens when one of these priorities is ignored. When teams are new to agile, the center spot may prove to be quite small at first, but over time the people in these three leadership roles, and more importantly the entire team itself, will help to grow it.
Do We Need the Scrum Roles at All?
In the 1990s when Scrum was created, it was a different world. We were used to working in specialist silos, building software from documents, and didn't really know how and when to collaborate, hence the need for a scrum master to forcibly bring team members together, unifying them behind a team goal. These days, many younger developers have never worked in a siloed environment. They don't need a designated role within the team to ensure collaboration happens effectively. Similarly, why do we need a formal product owner between the team and the rest of our stakeholders? This degree of separation increases the chances of miscommunications and limits opportunities of the teams to develop empathy for the people they are building the solution for. In Scrum's early days, it was difficult to gain access to stakeholders so the “mandatory” product owner was created. It is more commonly accepted practice these days to have direct access to all stakeholders, and hopefully active stakeholder participation.
In Disciplined Agile, we constantly need to remind teams that context counts, and choice is good. Like everything in DA, the roles we outline are “good ideas” which may or may not make sense for you. In the Form Team process goal (Chapter 7), we encourage you to consider the roles that make sense for your team. If you are new to agile and there is little organizational resistance to change, then you probably want to adopt the DAD classic roles. If your agile maturity and capability are more advanced, or if adopting new roles would be too disruptive, then you may wish to adapt roles accordingly.
Tailoring DAD Team Roles for Your Organization
As we mentioned earlier, you build your teams from the people that you have. Many organizations find that they cannot staff some of the roles, or that some of the DAD roles simply don't fit well in their existing culture. As a result, they find they need to tailor the roles to reflect the situation that they find themselves in. Tailoring the roles can be a very slippery slope as we've found the DAD roles work very well in practice, so any tailoring that you do likely increases the risk faced by the team. Table 4.1 captures tailoring options for the primary roles, and the risks associated with doing so.
Table 4.1: Potential tailoring options for the primary roles.
DAD and Traditional Roles
Many agile purists will insist that traditional roles such as project manager, business analyst (BA), resource manager, and many others go away with agile. Although that may happen in the long run, it isn't practical in the short term. The elimination of traditional roles at the beginning of your agile transformation is revolutionary and often results in resistance to, and the undermining of, agile adoption. We prefer a more evolutionary, less disruptive approach that respects people and their career aspirations. While agile requires different ways of working, the skills and rigor of traditional specialties are still extremely valuable. Project managers understand risk management, estimating strategies, and release planning. Classically trained or certified business analysts bring a rich tool kit of modeling options (many of which are described in the Explore Scope goal in Chapter 9). To say that we don't need project managers or business analysts is short-sighted, naïve, and disrespectful to these professions.
Having said that, the primary DAD roles are extremely effective in practice. When we work with organizations to improve their WoW, we help as many people as we can to transition out of their existing traditional roles into the DAD roles, which they often find more fulfilling in practice. Figure 4.5 depicts common options for several traditional roles. What we show are generalizations, and it's important to recognize that people will choose their own career paths based on their own preferences and desires. The important thing is to recognize that everyone can find a place for themselves in an agile organization if they're willing to learn a new WoW and move into new roles.
In Summary
This chapter explored the potential rights and responsibilities of people involved with DAD teams, and the roles that they may choose to take on. We say potential because you need to tailor these ideas to fit into your organization's cultural environment. However, we showed that the further you stray from the DAD roles and responsibilities, the greater the risk you will take on. You learned:
• DAD defines five primary roles—team lead, product owner, team member, architecture owner, and stakeholder—that appear on all teams.
• In many situations, teams will rely on people in supporting roles—specialists, domain experts, technical experts, independent testers, or integrators—as appropriate and as needed.
• DAD's roles are meant to be, like everything else, a suggested starting point. You may have valid reasons for tailoring the roles for your organization.
• With roles, as with everything else, do the best you can do in the situation that you face and strive to improve over time.