View source for Disciplined Agile Delivery (DAD)

'''Disciplined Agile Delivery''' is a learning-oriented, people-first hybrid approach to IT solution delivery. DAD is goal-driven and can scalable with the risk-value delivery lifecycle. The framework of DAD gives a simplified process to make a decision around the incremental and iterative solution delivery. Using DAD streamlines in the IT work is quite good because it allows for great scaling. DAD has been adapted to other strategies such as Scrum, Agile modeling, Unified Process, and Kanban, to create a hybrid delivery system with relevant parts from each technique.
*Disciplined Agile Delivery is the goal-driven approach, meaning that DAD is more flexible and accessible to scale the work than the other agile method. From the beginning, DAD offers choices that lead to the end goal and also includes the other possible options to consider, before making a final decision. The goal of DAD consists of four main sections: the inception phase, construction phase, transition phase, and the ongoing goals. The inception phase focuses on identifying the end goal, putting people into a team and developing a strategy while securing funding and identifying risks. The construction phase consists of addressing the shareholder’s needs and working closer to reach the end goals. The transition phase is to check that the solution is ready to be deployed and implement it. The ongoing goals should be focused on growing the team, completing the project task, continue to address risk, and have constant improvement. DAD lifecycle addresses the entire project from pre-production to post-production, unlike primary agile methods.
*Disciplined Agile Delivery is people-driven, so the team aspect of DAD is essential. The role division must be clear in order to have the success of using DAD. The primary of the DAD framework consists of five significant roles, these roles will always be in a DAD framework in any scale of mission, these roles are the stakeholder, product owner, team leader, team member, and the architecture owner. The secondary roles are domain expert, technical expert, tester, integrator and any number of specialists. Sometimes, these secondary team members have been using temporarily to address an issue in scaling. So these teams work together and with the clients to ensure that the product is exactly as it should be. DAD also allows teams to share their discoveries with the other teams.
*Disciplined Agile Delivery promotes a risk-value lifecycle, The riskier work is done at the beginning of the project to increase the chances of success. But this can also lead to failure in the earlier so the team has more time to come up with the solution. DAD teams are able to see their goals together and reach their goal as a team, instead of individual goals that may not lead to final success. DAD is a good development approach to solution delivery that is adapted to each project.<ref>What is Disciplined Agile Delivery (DAD)? [https://medium.com/@natpalmsl/introduction-to-disciplined-agile-delivery-190e29ca283f Nattaphol Srisa]</ref>

DAD is part of the Disciplined [[DevOps]] layer (see Figure below)<br />


[[File:Workflow of Disciplined DevOps.png|400px|The Workflow of Disciplined DevOps]]<br />
source: Project Management Institute


'''History of Disciplined Agile Delivery<ref>History of Disciplined Agile Delivery [https://en.wikipedia.org/wiki/Disciplined_agile_delivery Wikipedia]</ref>'''<br />
Disciplined Agile Delivery framework was started in 2009 by IBM under the direction of Scott Ambler and Mark Lines. Ambler and Lines continue to lead the evolution of DAD. DAD was developed to provide a more cohesive approach to agile software development; one that tries to fill in the process gaps that are (purposely) ignored by Scrum, and one that is capable of enterprise-level scale. According to Ambler, "Many agile methodologies — including Scrum, XP, AM, Agile Data, Kanban, and more—focus on a subset of the activities required to deliver a solution from project initiation to delivery. Before DAD was developed, you needed to cobble together your own agile methodology to get the job done." DAD was developed as a result of observing common patterns where agility was applied at scale successfully.

In 2015 the Disciplined Agile (DA) framework, later to become the Disciplined Agile Toolkit, was developed. This was called Disciplined Agile 2.x. DAD formed the foundation for DA. A second layer, disciplined DevOps, was added as was a third layer called Disciplined Agile IT (DAIT).[citation needed] These layers, respectively, addressed how to address DevOps and IT processes in an enterprise-class setting.

Disciplined Agile 3.x was released in August 2017 to introduce a fourth layer, Disciplined Agile Enterprise (DAE), to address the full process range required for business agility. In December 2018, Disciplined Agile 4, now referred to as the Disciplined Agile Toolkit, was released. It focused on a completely revamped description of DAD and a team-based improvement strategy called guided continuous improvement (GCI).

In August 2019, Disciplined Agile was acquired by Project Management Institute.


'''DAD - A Hybrid Process Framework<ref>The DAD Process Framework is a Hybrid [https://www.agilealliance.org/wp-content/uploads/2016/01/Disciplined-Agile-Delivery-RAW14261USEN.pdf Agile Alliance]</ref>'''<br />
DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner. 
*Scrum: The focus of Scrum is on project leadership and some aspects of requirements management. DAD adopts and tailors many ideas from Scrum, such as working from a stack of work items in priority order, having a product owner responsible for representing stakeholders, and producing a potentially consumable solution from each iteration. However, DAD abandoned most of Scrum’s terminology—nobody sprints through a race, people get hurt in rugby scrums, and don’t get us going on the term “master”—with the exception of the term product owner. 
*Extreme programming (XP): XP is an important source of development practices for DAD, including but not limited to continuous integration (CI), refactoring, test-driven development (TDD), collective ownership, and many more. 
*Agile Modeling (AM): As the name implies, AM is the source for DAD’s modeling and documentation practices. This includes requirements envisioning, architecture envisioning, iteration modeling, continuous documentation, and just-in-time (JIT) model storming. 
*Unified Process (UP): DAD adopts many of its governance strategies from agile instantiations of the UP, including OpenUP and Agile Unified Process (AUP). In particular, this includes strategies such as having light-weight milestones and explicit phases. We also draw from the Unified Process’ focus on the importance of proving out the architecture in the early iterations and reducing all types of risk early in the life cycle.
*Agile Data (AD): As the name implies AD is a source of agile database practices, such as database refactoring, database testing, and agile data modeling. It is also an important source of agile enterprise strategies, such as how agile teams can work effectively with enterprise architects and enterprise data administrators. 
*Kanban: DAD adopts two critical concepts—limiting work in progress and visualizing work—from Kanban, which is a lean framework. These concepts are in addition to the seven principles of lean software development (eliminate waste, build in quality, create knowledge, defer commitment, deliver quickly, respect people, and optimize the whole)


[[File:DAD as Hybrid.png|450px|DAD is a Hybrid Framework]]<br />
source [http://www.ambysoft.com/downloads/DisciplinedAgileDeliverySlides.pdf Scott Ambler & Associates]


'''Disciplined Agile Delivery Phases and Life Cycles<ref>Disciplined Agile Delivery Phases and Life Cycles [https://www.openxcell.com/blog/disciplined-agile-delivery/ OpenXcell]</ref>'''<br />

<u>Disciplined Agile Delivery Phases</u><br />
The different phases of Disciplined Agile Delivery are:
*Inception: The team starts the different activities in this first phase of Disciplined Agile Delivery. Some light work regarding the future of the project to the property frame of the project is done.
*Construction: In this phase, the team will come up with a solution that is consumable and is incremental. This might include iterations or via a lean, continuous approach. The team may also apply hybrid practices from Scrum, XP, Agile Modeling, Agile Data, etc.
*Transition: Disciplined Agile Delivery understands that for sophisticated agile projects that delivering a solution isn’t a small job. Thus the delivery teams and the whole enterprise will streamline the delivery process. As a result of this, with time, the phases become small, and in ideal conditions, they disappear with the help of continuous deployment strategies.

<u>Disciplined Agile Delivery Life Cycles</u><br />
The different Disciplined Agile Delivery life cycles are:
*The Agile Life Cycle: The agile life cycle is based on the concepts of Scrum. It gives a streamlined strategy from the first to the last. The figure shows Agile lifecycle extending upto Scrum. Situations where you might be adopting this lifecycle are where you are transferring from RUP to a disciplined Agile approach. The other important points of Agile lifecycle are:
**Its based on iteration 
**Uses non-Scrum technology
**Shows inputs from outside the delivery lifecycle
**There is no product backlog but a work item list
**It has milestones


[[File:DAD Agile Lifecycle.jpg|400px|DAD Agile Lifecycle]]<br />
source OpenXcell


*The Lean Life Cycle: The lean life cycle is based on the principles of Kanban. This life cycle depicts lean principles like minimizing the work, maximizing the flow, continuous stream of work, and reduction of bottlenecks. New work is taken from the pool of work. Scrum prescribes the use of daily coordination meetings, iteration planning time, retrospectives to be done sometimes. Lean does not prescribe but instead suggests the necessity of the same. This lifecycle is considered to be a little advanced considering the degree of discipline required. The different features of lean life cycle are:
**Supports continuous flow of development
**Practices are on their own 
**Presence of work item pool


[[File:DAD Lean Lifecycle.jpg|500px|DAD Lean Lifecycle]]<br />
source OpenXcell


*The Continuous Delivery: Agile life cycle: This is a modern agile system that has a stable team life cycle and is based on the principles of Scrum. It is a natural progression from Agile lifecycle. The evolution happens by adopting iterations with lengths of one week or less. The continuous delivery lifecycle releases new functionality at the end of each iteration. Teams need mature practices around different DevOps strategies.


[[File:DAD Continuous Delivery Agile Lifecycle.jpg|500px|DAD Continuous Delivery Agile Lifecycle]]<br />
source OpenXcell


*The Continuous Delivery: Lean Life Cycle: This is a modern agile system that has a stable team life cycle and is based on the principles of Kanban.it is actually a leaner form of the previous life cycle. This can however be daily, weekly or monthly. 


[[File:DAD Continuous Delivery Lean Lifecycle.jpg|500px|DAD Continuous Delivery Lean Lifecycle]]<br />
source OpenXcell


*The Exploratory/Lean Startup Life Cycle: The Exploratory or lean Startup life cycle, as the name suggests, is based on the strategies of a Lean startup. This lifecycle is followed by different agile or lean teams which are in startup or research places where the stakeholders have new product ideas but are not sure about what’s actually needed. Thus it is required for them to understand the market fast through learning experiments. This phase is almost like the inception period of other DAD lifecycles.


[[File:DAD Exploratory-Lean Startup Lifecycle.jpg|500px|DAD Exploratory-Lean Startup Lifecycle]]<br />
source OpenXcell


*Program Life Cycle: The program life cycle is for a team of teams. It is used to organize a team of different teams. Even though not usually, large agile teams do occur. SAFe, LeSS, and Nexus address such situations.


[[File:DAD Program Lifecycle.jpg|450px|DAD Program Lifecycle]]<br />
source OpenXcell


'''The Roles of Disciplined Agile Delivery (DAD)'''<br />
DAD fosters the strategy of cross-functional teams made up of cross-functional people. There is no hierarchy within the team, and team members are encouraged to be cross functional in their skill set and indeed perform work related to disciplines other than their specialty. The increased understanding gained beyond a team member’s primary discipline results in more effective use of resources and the reduced reliance on formal documentation and sign-offs. As such, agile methods deemphasize roles based strictly on skillsets in favor of primary roles that can include a variety of skills. Accordingly, the five primary roles of DAD are: 
*Stakeholder: A stakeholder is someone who is materially impacted by the outcome of the solution. 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, auditor, your program/ portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project. *Product owner: The product owner is the individual on the team who speaks as the “one voice of the customer.” They represent 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 documentation. 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. 
*Team member: The 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 lead: The team lead is the 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 removing any impediments to the team (issue resolution) in a timely manner. 
*Architecture owner: The architecture owner makes the architecture decisions for the team and facilitates the creation and evolution of the overall solution design. Architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk. Note that the architecture owner doesn’t dictate the architecture of the solution, but instead leads its formulation. On small projects the team lead is often the architecture owner. 
Notice that tester and business analyst are not primary roles in the DAD process framework. Rather, a generic team member should be capable of doing multiple things. A team member who specializes in testing might be expected to volunteer to help with requirements, or even taking a turn at being the Scrum Master (team lead). This doesn’t imply that everyone needs to be an expert at everything, but it does imply that as a whole the team should cover the skills required of them, and should be willing to pick up any missing skills as needed. Team members should be “generalizing specialists”—a specialist in one or more disciplines but with general knowledge of other disciplines as well. More important, generalizing specialists are willing to collaborate closely with others, to share their skills and experiences with others and to pick new skills up from the people they work with. A team made up of generalizing specialists requires few handoffs between people, enjoys improved collaboration because the individuals have a greater appreciation of the background skills and priorities of the various IT disciplines, and can focus on what needs to be done as opposed to focusing on whatever their specialties are.


[[File:DAD Roles.png|450px|The Roles of Disciplined Agile Delivery]]<br />
source [http://www.ambysoft.com/downloads/DisciplinedAgileDeliverySlides.pdf Scott Ambler & Associates]


'''Why Adopt DAD<ref>What are the reasons to consider adopting the DAD Framework? [https://www.pmi.org/disciplined-agile/process/introduction-to-dad PMI]</ref>'''<br />
There are several reasons why you should consider adopting DAD. They are:
*DAD picks up where Scrum leaves off. DAD describes how all agile techniques fit together, going far beyond Scrum, to define a full agile solution delivery life cycle. Like Scrum the DAD addresses leadership, roles & responsibilities, and requirements change management. Unlike Scrum DAD doesn’t stop there, it also addresses other important aspects of software development such as architecture, design, testing, programming, documentation, deployment and many more. In short, DAD provides a much broader understanding of how agile development works in practice, doing a lot of the “heavy process lifting” that Scrum leaves up to you.
*DAD is pragmatic. The DA toolkit provides choices, not prescriptions, enabling you to easily tailor a strategy that reflects the situation that your team finds itself in. To do this effectively you need to understand the process-oriented choices you have and what the trade-offs are. DAD makes these choices explicit through its process-goal driven approach.
*DAD supports both lean and agile ways of working (WoW). DAD supports several delivery life cycles, including a Scrum-based agile life cycle, a Kanban-based lean life cycle, two continuous delivery life cycles, a Lean Startup-based exploratory life cycle, and a Program “team of teams” life cycle. Teams find themselves in unique situations, and as a result one process size does not fit all. Even in small companies we’ve seen situations where some teams are taking an agile approach, some a lean approach, and some combinations thereof.
*DAD is based on empiricism. For several years Scott Ambler, Mark Lines, and many other contributors to DAD worked in or visited hundreds of enterprises around the world in a wide range of industries and environments. DAD, and the DA tool kit in general, captures the proven strategies adopted by these organizations, describing the strengths and weaknesses of each strategy and providing guidance for when and when not to apply them.
*DAD provides a solid foundation from which to scale agile. DAD supports successful scaling of agile and lean techniques in several ways. First, its full delivery life cycles and breadth of software development advice answers how to successfully apply agile in practice. Second, its goal driven approach provides the required flexibility for tailoring your agile process to meet the challenges faced by agile teams working at scale. Third, DAD builds in many foundational concepts required at scale, including DevOps, explicit agile governance, and enterprise awareness.
*DAD enables and goes beyond SAFe. SAFe leaves the details of construction to you and as a result can prove to be fragile in many organizations. DAD provides the solid process foundation missing from SAFe and is in fact complementary to SAFe. DAD describes several strategies for organizing large or geographically distributed teams. It describes a range of options for scaling your approach to agile and lean software development, giving you context-sensitive options that SAFe doesn’t.
*DAD teams deliver solutions, not just software. DAD recognizes that the software we develop runs on hardware, which may need upgrades, and it is supported by documentation. Our stakeholders may also need to evolve their business processes, and sometimes even their organization structures, to address the new needs of the situation that they face. In short, DAD teams deliver consumable solutions that comprise software, hardware changes, supporting documentation, improved business processes, and even organizational changes.
*DAD is evolving. We’re constantly learning as practitioners, learning about and experimenting with new agile and lean strategies all of the time. These learnings are constantly being applied to evolve DAD.


== See Also ==
Disciplined Agile Delivery (DAD) is a process decision framework that enables simplified process decisions around incremental and iterative solution delivery. DAD extends the Agile software development methodology by providing a more comprehensive approach that integrates various aspects of software project planning, management, and deployment. It incorporates practices from Scrum, Agile Modeling, Lean software development, and others, offering guidance on the entire lifecycle of a project, from inception to delivery.

*Agile Software Development is a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. DAD builds upon these Agile principles to provide a more robust framework.
*[[SCRUM]]: A framework within Agile for developing, delivering, and sustaining complex products, with an initial emphasis on software development, although it has been used in other fields. DAD integrates Scrum practices and extends them for end-to-end project lifecycle management.
*Lean Software Development: Adapting Lean manufacturing principles and practices to the software development domain. DAD incorporates Lean principles such as eliminating waste, amplifying learning, and delivering quickly.
*Continuous Integration (CI) is a software development practice in which developers regularly merge their code changes into a central repository, after which automated builds and tests are run. DAD emphasizes CI as part of its disciplined approach to Agile delivery.
*Enterprise Awareness: DAD recognizes that decisions made in the context of a project or team should consider the wider organizational environment, standards, and existing infrastructure to ensure alignment and leverage organizational assets.
*Inception Phase: This is the initial phase in DAD, where the project vision, scope, and potential architecture are established. It involves lightweight planning to get the project started on a solid foundation.
*Construction Phase: The phase in DAD where the bulk of the solution is produced through iterative development cycles. It focuses on building a consumable solution in a disciplined, efficient, and quality-driven manner.
*Delivery Phase: The final phase in DAD focused on deploying the solution to the production environment, making it available to end-users, and transitioning the project to a maintenance or operational status.
*Process Tailoring: In DAD, the framework must be adapted to meet the unique needs of a project or organization. DAD supports tailoring its practices and workflows to fit various contexts, such as different project sizes, levels of complexity, and organizational cultures.
*[[Governance]]: The set of practices and policies in DAD are designed to ensure the project achieves its goals, meets organizational standards, and delivers value consistently and predictably. Governance in DAD involves coordination, risk management, and stakeholder alignment.

*[[Agile Methodology]]
*[[IT Strategy (Information Technology Strategy)]]
*[[IT Governance]]
*[[Enterprise Architecture]]
*[[Chief Information Officer (CIO)]]
*[[IT Sourcing (Information Technology Sourcing)]]
*[[IT Operations (Information Technology Operations)]]
*[[E-Strategy]]

Disciplined Agile Delivery provides a flexible and comprehensive framework that acknowledges the complexity of software development projects and the need for discipline in Agile practices. It aims to guide teams in making effective process decisions and adapting their approach to suit project demands and organizational contexts.



===References===
<references/>