The Disciplined Agile Delivery Framework

Disciplined Agile® Delivery (DAD) is a people-first, learning-oriented hybrid agile approach to IT solution delivery. DAD addresses all aspects of the full delivery life cycle, supporting multiple ways of working (WoW) that can be tailored to the context that you face. DAD encompasses all aspects of agile software development in a robust, pragmatic, and governable manner.

Roles

  • Primary Roles. These roles are commonly found on DAD teams regardless of the level of scale faced by the team.
    • 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.
    • Team Member. The role of the team member focuses on producing the actual solution for stakeholders (a.k.a. Developer in Scrum).
    • Team Lead. 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 (a.k.a Scrum Master).
    • 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.
    • 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.
  • Supporting Roles. These are typically introduced, often on a temporary basis, to address scaling issues
    • 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.
    • 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.
    • 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.
    • 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 life cycle.
    • 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.

Notes 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. 
  • Roles are not positions, nor are they meant to be.

Full Delivery Life Cycles

DAD, because it’s not prescriptive and strives to reflect reality as best it can, actually supports several versions of a delivery life cycle. Six versions of the life cycle are supported

Share: