This page describes the primary and secondary roles on in DAD teams.
Primary roles (exist in every team)
Product Owner (from Agile Modeling site):
The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team. Each agile team, or in the case of large programmes an agile subteam, has a single product owner to go to for information and prioritization of their work and they do so right away. A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. In traditional terms, a product owner is in many ways an empowered business analyst without the burden of the bureaucracy surrounding big requirements up front (BRUF)>.
The role of product owner was introduced to the agile community by Scrum, although the onsite customer practice of Extreme Programming (XP) is very similar. This role has been adopted by the Disciplined Agile Delivery(DAD) process framework.
As a stakeholder proxy, the product owner:
- Is the “go to” person for domain information
- Provides timely information and decisions
- Prioritizes requirements, defects, and other work items for the team
- Is an active participant in modeling (sometimes mistakenly called backlog grooming or backlog refinement)
- Is an active participant in customer testing
- Helps the team gain access to expert stakeholders
- Facilitates requirements modeling sessions, including requirements envisioning
- Educates team in the business domain
- Is the gateway to funding
- Manages requirements dependencies with other teams, negotiating and reprioritizing as appropriate.
When representing the agile team to the stakeholder community, the product owner:
- Is the public face of team to project stakeholders
- Demos the solution to key stakeholders who weren’t able to attend the normal iteration demo
- Announces releases
- Communicates team status
- Organizes milestone reviews
- Facilitates requirements modeling sessions
- Educates stakeholders in the development process
- Negotiates priorities, scope, funding, and schedule
There are several aspects about this role which are critical to understand:
- Product owners bridge the communication between the team and their stakeholders. As Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.
- Product owners are empowered. The product owner is the single person whom is responsible for prioritizing requirements and for providing the details explaining the requirements to the team. At scale this becomes a bit more complex, as you’ll see below.
- Product owners facilitate communication. Product owners need good communication skills, including agile modeling skills. They also need to know who the stakeholders are, interact with them regularly, and when needed facilitate the interaction which the team has with them. Although it’s convenient for delivery teams to think of product owners as the “one neck to wring” because it puts the burden of requirements responsibility on them, the reality is that the product owner can’t possibly know all the details known by the true range of stakeholders at all points in time and as a result will need to bring stakeholder experts to the team to share their expertise with the team at appropriate times. The implication is that the product owner isn’t always the direct source of requirements.
- Product owners prefer direct means of communication. There is significant evidence that the worst way to communicate information between people is via documentation, and that the most effective way is face-to-face around a shared sketching environment. Agilists in general prefer to avoid interim documentation and instead use more effective means for agile communication.
- Product owners need many business analysis skills. They need to be skilled in techniques to identify stakeholder needs, negotiate priorities between repeating stakeholder factions, and then collaborate with developers to ensure that the requirements are implemented effectively. This is business analysis 101 stuff.
Architecture Owner (from DAD site)
In DAD we recognize that architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk. As a result the DAD process framework explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design. The person in the role of team lead will often also be in the role of architecture owner. This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.
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, but that they lead the technical 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.
- Understanding existing enterprise assets such as frameworks, patterns, 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.
- Ensuring that the solution is integrated and tested on a regular basis, ideally via the practice of continuous integration(CI).
- Having the final say regarding technical decisions, but they try to avoid dictating the architectural direction in favor of a collaborative, team-based approach. The architecture owner should work very closely with the team lead to identify and determine strategies to mitigate key project technical risks.
- Leads the initial architecture envisioning effort at the beginning of the project and supports the initial requirements envisioning effort (particularly when it comes to understanding and evolving the non-functional requirements for the solution).
One of the key reasons for having this role in DAD is that the architecture owner, like the product owner, has a say in work items that are added and prioritized in the work item list (backlog in Scrum parlance). While business value is certainly a prime determinant of priorities, completing work related to mitigating technical risks is also important. Additionally, a DAD goal is to deliver consumable solutions, not just working software. As such, sometimes it is necessary to add work items that are technical in nature, for example related to error logging/monitoring. Or perhaps work items need to be added to improve the continuous integration and deployment processes.
We have found that the concept of having both product and architecture owners ensures that the solution addresses both functional and non-functional requirements such as usability and supportability adequately. Without a specific role of architecture owner, it can be difficult to escalate important technical work into the work item list. As as result it is often done subversively without the knowledge of the product owner which is not a healthy practice, or worse it never gets done resulting in a poor quality solution.
On agile projects the role of the traditional project manager changes substantially, and in fact the term project manager is now unfortunately frowned upon. The agile community has focused on project or team leadership over team management, observing that the best “managers” prioritize leadership over technical management issues such as planning and estimation. An important aspect of self-organizing teams is that the team lead facilitates or guides the team in performing technical management activities instead of taking on these responsibilities him or herself. The team lead is a servant-leader to the team, creating and maintaining the conditions that allow the team to be successful. 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. He or she acts as a true leader, facilitating communication, empowering them to self-optimize their processes, ensuring that the team has the resources that it needs, and removes any impediments to the team (issue resolution) in a timely manner. When teams are self organizing, effective leadership is crucial to your success.
While an experienced team lead brings these skills to a new team, it is unrealistic for this person to be a true coach if she has not had some mentoring. For teams new to agile, it often makes sense to have a part-time experienced coach working with the team for a few iterations. A team lead’s leadership responsibilities can be summarized as the following:
- Responsible for the effectiveness and continuous improvement of the process being followed by the team
- Facilitates close cooperation across all roles and functions
- Ensures that the team is fully functional and productive
- Keeps team focused within the context of the project vision and goals
- Is responsible for removal of team-based impediments and for the escalation of organization-wide impediments
- Protects the team from interruptions and external interferences
- Maintains open honest communication between everyone involved with the project
- 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 (does not make decisions or mandate internal team activity)
Secondary roles (usually introduced at scale)
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 in your domain, something particularly true with complex domains. The product owner will sometimes bring in domain experts to work with the team, for example, a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision for the project. Domain experts often fall into the stakeholder categories of either insiders or partners.
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 you explore the requirements for what you’re building. On large teams a program manager may be required to coordinate the team leads on various subteams. You will also see specialists on DAD teams when generalizing specialists aren’t available—when your organization is new to agile it may be staffed primarily with specialists who haven’t yet made the transition to generalizing specialists.
Sometimes the team needs the help of technical experts, such as a build master to set up build scripts, an agile database administrator to help design and test a database, a user experience (UX) expert to help design a usable interface, or a security expert to provide advice about writing a secure system. Technical experts are brought in on an as-needed, temporary basis to helpthe team overcome a difficult problem and to transfer their skills to one or more developers on the team. Technical experts are often stakeholder insiders, 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.
While the majority of testing is done by the people on the DAD team themselves, some DAD teams are supported by an independent test team working in parallel that validates their work throughout the lifecycle. This independent test team is typically needed for agility@scale situations within complex domains, using complex technology, or addressing regulatory compliance issues. Independent testers are effectively partner stakeholders who are outside the team.
For large DAD teams that have been organized into a team of subteams, the subteams are typically responsible for one or more subsystems or features. The larger the overall team, generally the larger and more complicated the system being built. In these situations, the overall team may require one or more people in the role of integrator responsible for building the entire system from its various subsystems. On smaller teams or in simpler situations the architecture owner is typically responsible for ensuing integration, a responsibility 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 project. This integrator role is typically only needed at scale for complex technical solutions.
independent test team, if there is one, to perform system integration testing regularly throughout the project. This integrator role is typically only needed at scale for complex technical solutions.