Roles in Disciplined Agile Delivery

The Disciplined Agile Delivery (DAD) framework suggests a robust set of roles for agile solution delivery.  These roles are overviewed in the following figure:

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.  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.
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 the DAD 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 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.

Secondary Roles

Secondary roles are typically introduced, often on a temporary basis, to address scaling issues.  There are five secondary 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.  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.  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 entire 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 project 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 the Disciplined Agile Delivery book 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.

Material for this blog posting was modified from Chapter 4 of Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press, 2012)

The DAD Role of Architecture Owner

As you can see from this diagram, the DAD primary roles are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  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.  In fact, on my current project, I worked with the product and architecture owners to negotiate their priorities such that the iteration underway includes not only a selection of high priority stories, but also a set of technical work items related to hardening the solution in preparation for entering the Transition phase of delivering the solution to the stakeholders.  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.

Scott has written a good article that describes the architecture owner role in more depth.  You can view it here.

No role in DAD for an Analyst?

Why does DAD not have an explicit role for an Analyst?  This is a hot topic for those in this profession, and a subject that I have been asked to talk on, notably for the IIBA.  Without question classically trained analysts bring much needed soft skills and a structured approach to requirements elicitation and negotiation which may not be present in the other roles such as a product owner or a developer.  However, having these skills alone is not enough in an agile and lean world.

Unfortunately, professional organizations such as the Project Management Institute (PMI) and the International Institute of Business Analysts (IIBA) tend to encourage us to seek specialization and certifications over being cross-functional team members, which will be far more effective and valuable in the future.  This is not to say that these organizations do not deliver value in developing and maintaining standards of professional conduct and capability.  Attaining certifications (that require some degree of commitment and experience beyond a 2-day workshop) demonstrate commitment to a professional specialty.  This is admirable but I would suggest that this base of knowledge is just the start of being an effective team member on an agile project.  We should look outside our area of specialty to learn all we can about other aspects of software development.

It is my belief that in the near future, analysts will need to be competent testers if they intend to prosper in their profession.  An increasingly important skill is the ability to write requirements as executable tests.  My advice to analysts is to learn as much as you can about agile testing and seek opportunities to write your requirements as tests wherever possible.

For Business Analysts that are not interested in moving more toward the testing end of the spectrum there is another way to go.  Analysts can be good Product Owners, representing the customer on the project and by managing the scope and priorities.  In this role they can use their elicitation and facilitation skills to gain a clear understanding of what the customer needs (vs. wants).

Another potential career path is to for BA to move more into the area of traditional management consulting.  The IIBA is positioning the Business Analyst profession to be more strategic, identifying the need to have them present at the management table when key decisions are made regarding how the business and its architecture should evolve.  Our book on Disciplined Agile Delivery is about agile software development.  But not all business issues are solved by software.  Often it is the business process that needs to be fixed, and this is where traditional Business Analysis skills will always be needed.

In my opinion, one career path for analysts is going the way of the dinosaur though.  And unfortunately this career path is often the status quo.  Traditional projects expect Business Analysts to document business processes and requirements in batch up-front in a linear, waterfall fashion.  They then must obtain sign-offs before actually proceeding with implementing any of the requirements.  Subsequent changes to those requirements are discouraged, unless through a formal, time consuming and wasteful Change Request process.  This model clearly is flawed, and eventually most companies with change their approach.  High ceremony and bureaucratic organizations such as government will be the slowest to adapt, but private companies in a competitive environment will adapt their requirements capture approach to a more agile alternative or risk being left behind by their competitors that will be more “agile” in adapting both their business processes and the solutions that support them.

Product owner issues in the Transition phase of large agile projects

Captain Barbossa

Mainstream agile methods would suggest that we should have one product owner, being the “one” voice of the customer for matters related to release/iteration scope, priorities, and requirements clarification.

The reality that I see on most enterprise agile projects is that the product owner cannot possibly manage the work item list themselves.  In fact, they are often not the best person to do this prioritization.  I wish it were as easy as managing epics and user stories.

On my current project, we are in the process of taking ownership of a very large application built offshore.  In DAD, we would describe this as the Transition phase of the product as we deploy the solution to our stakeholders.  We will take over the build, deployment, support and enhancement going forward.  This is a team of 20+ with responsibilities spanning development, infrastructure, and devops.  Due to the complexity of the rollout we are doing it over a number of Transition iterations.

A simplistic view would suggest that the Program Manager is our product owner.  At the end of the day he may have ultimate responsibility, but he is not collocated, and deals with the larger issues of the project, such as vendor management, governance, funding, resourcing, and other related issues.  He delegates responsibility for the details to domain leads for the business, development, infrastructure and support.

My approach as the overall agile team lead is to treat the these traditional leads as product owners.  They each have their own work items and priorities such as:

Development team:

• setting up VM images for development support of code
• determining a source code management strategy for parallel streams of maintenance and enhancements
• automation of continuous integration & deployment

Support team:

• establishing a customer support strategy, with triage process, roles, on call schedules etc.

Infrastructure/DevOps team:

• setting up automated jobs
• performance tuning

Business:

• change requests/stories
• defects

All:

• knowledge transfer between vendor and support team
• satisfying stage gate acceptance criteria
• documentation of procedures

For these work items, who is responsible for designating priorities, assigning to iterations, and iteration planning? The last question is the easiest to answer.  We let the team members doing the work do the task identification, estimating and assignment.  The other questions are a bit more tricky.  I don’t believe that any one person should determine the scope and prioriity of these diverse work items.  Rather, as team lead, I would prefer to let the team leads of infrastructure, customer support and development (traditionally might be PMs) to self-organize and advise me on their priorities and in which iteration their work items should be completed.  The summary of which is then reviewed with the Program Manager to assure alignment with the overall program’s goals.

Therefore what we are doing is co-managing the work item list with myself as facilitator.

This discussion shows some of the challenges in managing a DAD Transition iteration(s) using an agile approach.  I understand that the idea of having shared product ownership is not consist with methods such as Scrum.   However, in my world of large enterprise agile projects pragmatism trumps the agile “code”.  As Barbossa says in Pirates of the Caribbean, “the code is more what you call guidelines than actual rules“.