Before we can describe the current version of the DAD Framework we have to have a quick look at its history because focus and scope have changed drastically over the last few years.
DAD History
To date there have been three major release tiers of this framework:Disciplined Agile Delivery 0.x: The framework was originally developed at IBM Rational from early 2009 to June 2012. The IBM team worked closely with business partners, including Mark Lines, and was led by Scott Ambler.
Disciplined Agile Delivery 1.x: The DAD 1.0 release occurred in June 2012 with the publication of the first DAD book, Disciplined Agile Delivery. The focus of Disciplined Agile Delivery (DAD) 1.x was to describe how agile/lean teams work from beginning to end, showing how all the activities of solution delivery (analysis, design, testing, architecture, management, programming, and so on) fit together in a cohesive, streamlined whole.
Disciplined Agile 2.0: This is the current version of the framework, initially released in August 2015. The focus is on describing a flexible, context-sensitive approach to the IT process. The scope of the framework evolved from how to be effective in delivering IT solutions to how to be effective at IT in general. As a result, the name changed from “Disciplined Agile Delivery” to “Disciplined Agile”.
Disciplined Agile 2.0
Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams. However, Scrum is only part of what is required to deliver solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores. When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders.
To address these challenges the Disciplined Agile Delivery (DAD) process decision framework tries to provide a more cohesive approach to agile solution delivery. It is defined by www.disciplinedagiledelivery.com as:
Disciplined Agile 2.0 is defined as a process decision framework for Enterprise I.T. The main characteristics of this framework are that it: is a people-first, learning-oriented hybrid agile approach; has a risk-value delivery lifecycle; is goal-driven; is enterprise aware; is tactically scalable at the team level; and scalable strategically across all of IT.
What is so special about DAD?
There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users.It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to address the situation in which you find yourself.
Roles
Primary roles are commonly found regardless of the level of scale. There are five primary roles: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.
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 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.
Team Lead: The team lead is defined as 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. In other words it is just a different name for the role of Scrum Master in traditional Scrum.
Product Owner: The product owner is defined as 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 a 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.
Architecture Owner: The DAD framework explicitly includes the 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 are typically introduced, often on a temporary basis, to address scaling issues. There are five secondary roles:
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.
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.
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.
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.
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?
Scrum has three roles – ScrumMaster, Product Owner, and Team Member – so why does DAD need ten? According to the authors of DAD 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.Personally I disagree with this explanation but will discuss this in detail in the last post where I will compare all frameworks and will give my own opinion on all of them.
Agile Delivery Lifecycles
First, the DAD lifecycle explicitly calls out three phases:Inception: During this phase project initiation activities occur. Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2013 Agile Project Initiation survey found the average agile team spends about a month in Inception whereas the most common iteration/sprint length is two weeks). So in DAD’s Inception phase some very lightweight visioning activities are planned to frame the project. It takes discipline to keep Inception short.
Construction: During this phase a DAD team will produce a potentially consumable solution on an incremental basis. They may do so via a set of iterations (Sprints in Scrum parlance) or do so via a lean, continuous flow approach (different versions of the lifecycle are discussed later). The team applies a hybrid of practices from Scrum, XP, Agile Modeling, Agile Data, and other methods to deliver the solution.
Transition: DAD recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise. DAD teams, as well as the enterprise overall, will streamline their deployment processes so that over time this phase become shorters and ideally disappears from adopting continuous deployment strategies. It takes discipline to evolve Transition from a phase to an activity.
The Agile/Basic Lifecycle: Extending Scrum
The figure below presents a more detailed view of what is called the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle:
It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls Sprints).
It uses non-Scrum terminology. Although the lifecycle is Scrum-based DAD chose to use non-branded terminology, in the case of this diagram the term iteration instead of Sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminology use that instead.
It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle.
There is a work item list, not a product backlog. DAD has a greater scope than Scrum, and becasuse they take this greater scope into account they are the opinion you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements.
It includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD teams should strive to meet.
How does DAD relate to the other scaling approaches like SAFe, Nexus, LeSS?
This question will be part of every article but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion. In this case it only makes sense to compare DAD with SAFe.Two quotes from the FAQ on the DAD website:
DAD and SAFe are complementary. SAFe focuses on scaling agile approaches across an organization whereas DAD focuses on providing a solid foundation from which to scale agile approaches to address the complexities of large teams, geographic distribution, technical complexity, and other scaling factors. SAFe calls out three levels of scaling – project, program, and portfolio – although currently focuses on program and portfolio. DAD can easily fit into the project level in SAFe (SAFe current shows Scrum there, and DAD extends Scrum) and actually provides clear hooks such as enterprise awareness and a process goal-driven approach which we believe enables a much better fit to SAFe than does Scrum. An interesting observation is that both DAD and SAFe come from people with a solid background in the Unified Process (UP).
Unlike other options, DAD is not a prescriptive framework. It is a process decision framework designed to provide various strategies to facilitate better process decision making for the unique context of your situation.We don’t believe that one framework such as SAFe is best used for all scaling situations. For example, there are several ways to organize large agile teams (a single large team, several feature teams, several component teams or hybrids of these). Instead of prescribing one strategy DAD instead provides guidance to select the strategy that makes sense in a given situation. Similarly, you will evolve your strategy to reflect the geographic distribution of your team, the level of complexity that you face, the culture of team, any regulatory compliance requirements, the organizational distribution of your team (e.g. are you outsourcing some work), and other factors.