Roles on DAD Teams

The Disciplined Agile Delivery (DAD) toolkit suggests a robust set of roles for agile solution delivery. These roles are overviewed in the following figure.  As you can see there are two categories of roles:

  1. Primary roles. These roles are commonly found on DAD teams regardless of the level of scale faced by the team.
  2. Supporting roles.  These roles are filled, often on a temporary basis, to address scaling issues.

DAD Roles

Primary Roles

Primary roles are commonly found regardless of the level of scale. There are five primary roles:

  1. 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: A stakeholder could be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, maintenance professionals potentially affected by the development and/or deployment of a software project. DAD teams will ideally work together with their stakeholders daily throughout the project.
  2. Team Member. The role of team member focuses on producing the actual solution for stakeholders. Team members will perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate throughout the project. 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. Team members are sometimes described by core agile methods as “developers” or simply as programmers. However, in DAD we recognize that not every team member necessarily writes code. Team members will identify tasks, estimate tasks, “sign-up” for tasks, perform the tasks, and track their status towards completion.
  3. Team Lead.  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.
  4. Product Owner. In a system with hundreds or thousands of requirements it is often difficult to get answers to questions regarding the requirements. The product owner is the one individual on the team who speaks as the “one voice of the customer”. He or she represents the needs and desires of the stakeholder community to the agile delivery team. As such, he or she clarifies any details regarding the solution and is also responsible for maintaining a prioritized list of work items that the team will implement 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. Having a product owner working closely with the team to answer any question about work items as they are being implemented substantially reduces the need for requirements, testing, and design documentation. You will of course still have need for deliverable documentation such as operations manuals, support manuals, and user guides to name a few. Each DAD team, or subteam in the case of large programmes organized into 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 project status to key stakeholders.
  5. Architecture Owner. Architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk. As a result DAD 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 on small teams. This isn’t always the case, particularly at scale, but it is very common for smaller agile teams. 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. He or she is just like any other team member and is 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.

Supporting Roles

Supporting roles (formerly called secondary roles) are typically introduced, often on a temporary basis, to address scaling issues. There are five supporting roles:

  1. 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 you to 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 subteams/squads. 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.
  2. Domain Expert (or 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 in your domain, something that is 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.
  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, a user experience (UX) expert to help design a usable interface, or a security expert to provide advice around writing a secure system. 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 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 at scale situations within complex domains, using complex technology, or addressing regulatory compliance issues.
  5. Integrator. For large DAD teams which 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 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 project. This integrator role is typically only needed at scale for complex technical solutions.

Why So Many Roles?

This is a common question that we get from people familiar with Scrum. Scrum has three roles – ScrumMaster, Product Owner, and Team Member – so why does DAD need ten? The primary issue is one of scope. Scrum mostly focuses on leadership and change management aspects during Construction and therefore has roles which reflect this. DAD on the other hand explicitly focuses on the full delivery lifecycle and all aspects of solution delivery, including the technical aspects that Scrum leaves out. So, with a larger scope comes more roles. For example, because DAD encompasses agile architecture issues it includes an Architecture Owner role. Scrum doesn’t address architecture so doesn’t include such a role.

Some Important Thoughts About Roles

On a DAD team any given person will be in one or more roles, an individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time. For example, Peter may be in the role of team member and architecture owner right now but step into the role of team lead next month when Carol, the existing team lead, goes on vacation.

Roles are not positions, nor are they meant to be. For example, Jane may be in the role of stakeholder for your project but have the position of Chief Financial Officer (CFO) within your organization. In fact, although there may be hundreds of stakeholders of your project none of them is likely to have a position of “stakeholder.”

Agile deemphasizes specialized roles and considers all team members equal – everyone pitches in to deliver a working solution regardless of their job description. An implication of this is that with the exception of stakeholder everyone is effectively in the role of team member.

Traditional roles, such as business analyst and project manager, do not appear in DAD. The goals which people in traditional roles try to achieve, for example in the case of a business analyst to understand and communicate the stakeholder needs/intent for the solution, are still addressed in DAD but in different ways by different roles. There isn’t a perfect one-to-one match between any given traditional role and a DAD role, but as you will find in Choose Your WoW! there are reasonable transition strategies. The critical thing for traditionalists to understand is that because the underlying paradigm and strategy has changed, they too must change to reflect the DAD approach.

Have any Question or Comment?

19 comments on “Roles on DAD Teams

Good day! I know this is somewhat off topic but I
was wondering if you knew where I could locate a captcha plugin for my comment form?

I’m using the same blog platform as yours and I’m having difficulty
finding one? Thanks a lot!

Anders Larsson

A few comments and questions:

* If product owner and architecture owner are team roles, who “owns” the product and architecture in a one product, many teams scaling scenario?

* In a many products, many teams scenario (for instance a business process change in an integration solution), who “owns” the business benefit realisation? To be honest, most agile processes neglect this scenario, but I have some faith in DAD 🙂

* I guess it’s preferable that the PO also is a domain expert? IMHO a domain expert isn’t a secondary role and product ownership isn’t a “one man show”. But I also agree that there’s a point in having a “one voice” of the customer on behalf of the technical team. From the team’s point of view a domain expert might be a secondary role, but not from a business perspective

* Being an architect, I find architecture a rather broad concern within an enterprise. That said, architecture makes room for several roles and specialisations, business, solution, software, infrastructure etc. A business architect might shoulder the role of a PO or any domain expert. A solution architect do better in the neighborhood of domain experts and supporting several teams in a scaling scemario (i.e the second bullet above). A software architect, an expert in engineering practices (the coding architect), should be a full member of the team. Within an experienced team, the “team” as such, might shoulder the software architect role. Those assumptions given, I guess the “architecture owner” addresses the description of a software architect?


Anders, answering your questions in order:
1. We have an article on Large Agile Teams that addresses how POs and AOs on sub-teams coordinate.
2. Depends on the organization. In DA we support Product Management as an important IT-level activity. That may be appropriate in some situations. In other situations you may want to treat that as a project and have, egads, a project manager responsible for it.
3. The PO should have a good understanding of the overall domain. However, it would be unrealistic to expect them to be an expert at all aspects of it. Hence the need for support domain experts, sometimes called subject matter experts (SMEs), as a role. In DA we’ve identified domain experts as a secondary role.
4. AO is generally the agile equivalent of software or application architect, albeit an agile version. We also call out Enterprise Architecture as an activity too, with the role of Enterprise Architect as a specialist role.


have you come across team lead and product owner being filled by the same person on a small project.


Sandra, yes, we get asked this all the time and we’ve seen teams try this. The quick answer is that this is a spectacularly bad idea in most situations. The only time that I’ve ever seen it work is when the person doing this is very disciplined about when they’re in the role of TL and when they’re in the role of PO. I’ve seen this fail many times because the person wasn’t sufficiently disciplined and favoured one role over the other.

The issue is that the PO is responsible for the “what” whereas the rest of the team is responsible for the “how.” It’s best to keep these in separate roles because you want a healthy tension between them.


The PO is a important aspect for projects where expertiese is needed. Will this be a fair assumption that PO shall participate in WHAT majorly followed with in HOW substantially and then helps conclude the UAT for production release. Please clarify.


If I understand your question correctly then the answer is yes. The PO will be definitely involved, and likely leading, the identification of what the team should be doing. When the team is working through how their going to do the work then the PO needs to be involved to clarify what the stakeholders want, and very likely to negotiate scope and prioritization.

The PO may also be involved with UAT activities. My hope is that they occur throughout Construction, not just at the end (which is expensive and risky).


What would you say about a Developer splitting their time between being a team member (developer) and being the Team Lead?


Graham, great question. This is quite common to see in practice. The primary issue is that there isn’t 8 hours a day of “team lead stuff” to do, so how does the lead fill in their time? A common strategy is that the lead is also a team member who is capable of taking on other tasks. This means that anyone doing this must have the skills and background to take on both roles.

Tope Songonuga

Totally agreed and I have seen it work effectively in my experience.

jli Mortlock

Hi. What documentation is required for an agile approach – do we need a solution overview which then breaks down into its component parts?


Great question. The quick answer is that agile doesn’t prescribe what documentation that you need to create if any. The general rule is that if an artifact adds value, and if that’s the best way to accomplish whatever you’re trying to accomplish, then create it to the extent that it’s just barely good enough for the situation that you face. See for detailed thoughts.


@Scott, when describing roles to companies, one thing came up again and again ; Primary vs Secondary roles … people who are suppose to have secondary roles have resistance to accept the fact that it is secondary role. … So, after seeing this, I started to call it Supportive Roles … and sometimes I call it Full FTE Members and NoT-Full FTE Team Members … all this to avoid resistance and ease the way of introducing DA team structure. I suggest to make this change to the DA roles officially (or similar naming) to not create unnecessary resistance.


This is an interesting observation. I think that “Supporting Roles” is a much better name than “Secondary Roles” for the reasons you describe. Let me bounce the idea around internally and see what comes of it.


Is there a life time defined for supporting roles or secondary roles in this scenario? If yes, what is the estimated time duration?


It depends on the situation. The supporting roles appear when needed to the extent that they’re needed.

Candice Govender

Do you find that the term “architecture” owner also causes confusion in the team as there is an expectation that is must be filled by someone who is an architect by trade and skill as opposed to a developer? How have you dealt with this ambiguity when you’re early in your journey of DAD adoption?


Whoever fills the role needs to have the skills, or at least be prepared to do the work to gain whatever skills they’re missing. In other words, grow into the role. So if an architect is stepping into the role of AO, if they’re missing development skills (or if they’re rusty), then they need to do the work to gain those skills.

An important thing to understand is that the DAD roles, and agile roles in general, are different than traditional roles. So just like Team Lead is different from PM, AO tends to be different than a traditional architect.


[…] Years ago I’ve seen projects succeed whose leadership included a competent functional architect and a competent technical architect. This duality was de-emphasised by the Unified Process with its strong focus on the (fairly technical) software architect role and by Scrum with its focus on the (fairly functional) product owner role. To make things worse, providing the “content leadership” (a better term, anyone?) on any sizeable initiative is a tall order for any single person, at least in my experience. Disciplined Agile Delivery begins to address this issue be re-emphasising this duality with its product owner and architecture roles. […]

Leave a Reply

Your email address will not be published. Required fields are marked *