If you haven’t yet read my Intro to Disciplined Agile Delivery please check it out. DAD is a hybrid of existing Agile methods that provide the flexibility of using various approaches while filling gaps left by current Agile methods. This four-part serious, in addition to the introduction above, should make an excellent primer for the seasoned Agilist.

Individuals

People come first. Disciplined Agile promotes people as the most valuable asset on your squad. Therefore, understanding successful patterns of motivation is essential. The following is a list of intrinsic motivation factors that work well with individuals:

  1. Mastery: People want to get better, to develop their skills so that they may be effective at what they do. In Disciplined Agile this is supported by a learning-oriented approach where teams regularly reflect on how well they are working, where teams explore new ideas and technologies through spikes, where people are responsible to share their skills and knowledge with others, and where teams purposely explore both the problem and solution domains in an evolutionary manner. Additionally, the Disciplined Agile (DA) tool kit promotes the strategy of people being “T-skilled” generalizing specialists  who have one or more specialties but also a broad knowledge of software engineering and the domain that they are working in.
  2. Autonomy: People want to be able to direct their own lives. In agile this is best represented by the principles that teams should be self-organizing and they should own their own process. Disciplined Agile enhances these principles by pointing out that self organization must be tempered with appropriate governance and that to effectively own your own process teams need light-weight guidance (via DA’s goal-driven approach).
  3. Purpose: People are motivated by goals that are bigger than themselves. On Disciplined Agile Delivery teams the first milestone is to come to a common vision with your stakeholders, a vision that guides the team throughout construction, a concept that is captured in DA’s Fulfill the Team Mission process goal. Furthermore, DA’s enterprise awareness philosophy promotes the idea that teams should look beyond themselves to understand and then do what is best for the organization that they work for, instead of what is convenient for them.

Teams

Just as there are factors that help to motivate individuals, there are dynamics that help to motivate effective performance on teams. The most succinct description that we’ve found come from the results of a study within Google  describing what they believe to be the five key dynamics of successful teams:

  • Psychological Safety: Team members need to feel free to take risks and to share ideas without fear of recrimination. Disciplined Agile team members have the responsibility to respect one another, to have humility when they are interacting with others, to run experiments, to work collaboratively, to share their skills and knowledge with others, and to be receptive to learning new ideas and skills from others as well.
  • Dependability: Team members need to be able to count on one another. Everyone must work in a trustworthy, open, and honest manner. Disciplined Agile team members have the responsibility to work in a trustworthy manner, to fulfill their commitments, and to provide information in a timely manner even if the work is incomplete.
  • Structure & Clarity: The vision of the team, the roles and responsibilities of the people on the team, and the plans for how the team will work together must be clear. Disciplined Agile teams are self organizing, albeit with appropriate governance to guide and enhance their efforts, an implication of which is that they are responsible for their own structure and bringing clarity to their own domain.
  • Meaning of Work: The team should be working on something that provides meaning to them. A solution delivery team will work on developing or configuring a solution that adds real value to their stakeholders; an enterprise architecture team will develop, support and evolve a vision for your organization; and a data management team will support and evolve the information assets within your organization. Different teams with different goals will find different meanings – IT isn’t just about creating potentially shippable software.
  • Impact of Work: The work that a team does needs to matter, or as Dan Pink would say the work has purpose.

Organizations

Organizations are complex adaptive systems. DA provides process guidance (process blades) as decision support tools for most of the more common challenges organizations face concerning software development.

Common topics include enterprise architecture, reuse engineering, release management and coordination, etc.

Roles in DA

Disciplined Agile embraces the full product lifecycle: Concept, Inception, Construction, Transition, Production, and Retire. Therefore, there are more roles than in classic Scrum. DA roles are organized into primary, and secondary categories.

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 of 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 sub-team in the case of large programs 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 sub-teams, the sub-teams 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 ensuring 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.

Roles at Scale

DA provides several roles for dealing with Agile at Scale.

  1. Ambassador. A communications agent and relationship builder who travels between locations.
  2. Boundary Spanner. An on-site agent who helps communication by working with boundary spanners at other sites.
  3. Chief Architecture Owner (CAO). A tem lead for the Architecture Owners wthin a program.
  4. Chief Product Owner. Leads Product Owners within a program.
  5. External Auditor. External professional, not an employee of your organization, who audits teams where regulatory or compliance issues are required. Typically a regulatory representative or consultant.
  6. Internal Auditor. An auditor who works within your organization.
  7. Program Manager. Organizes and coordinates activities within a large delivery team (program).
  8. Project Manager. Coordinates large portions of work that require several delivery teams, including work across organizational boundaries.

In addition, DA promotes Communities of Practice (CoPs) and Centers of Excellence (CoEs).

By mikeberry

Red Rock Research is run by Mike J. Berry. After years of consulting and working in the private sector, somebody must find this information valuable.