Disciplined Agile Delivery (DAD) - Revision history

User at 23:51, 30 September 2025

2025-09-30T23:51:59Z

User at 22:16, 7 March 2024

2024-03-07T22:16:03Z

User at 22:11, 7 March 2024

2024-03-07T22:11:24Z

User at 17:43, 18 October 2021

2021-10-18T17:43:48Z

User at 17:33, 18 October 2021

2021-10-18T17:33:56Z

User at 17:14, 18 October 2021

2021-10-18T17:14:47Z

User at 16:37, 18 October 2021

2021-10-18T16:37:32Z

User at 16:01, 18 October 2021

2021-10-18T16:01:54Z

User at 15:56, 18 October 2021

2021-10-18T15:56:10Z

User at 15:55, 18 October 2021

2021-10-18T15:55:00Z

@@ Line 135: / Line 135: @@
 *[[Agile Methodology]]
-*[[IT Strategy (Information Technology Strategy)]]
+*[[IT Strategy (Information Technology Strategy)|IT Strategy]]
 *[[IT Governance]]
 *[[Enterprise Architecture]]

@@ Line 121: / Line 121: @@
 == See Also ==
 *[[Agile Methodology]]
 *[[IT Strategy (Information Technology Strategy)]]
@@ Line 130: / Line 143: @@
 *[[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.

@@ Line 4: / Line 4: @@
 *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 />
+DAD is part of the Disciplined [[DevOps]] layer (see Figure below)<br />
@@ Line 118: / Line 118: @@
 *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.
 ===References===
 <references/>

@@ Line 29: / Line 29: @@
 *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)
@@ Line 91: / Line 95: @@
-The Roles of Disciplined Agile Delivery (DAD)
+'''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 crossfunctional 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.
+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:
-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: 1. 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. 2. 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. 3. 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. 4. 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. 5. 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.
@@ Line 107: / Line 118: @@
 *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.

@@ Line 19: / Line 19: @@
 In August 2019, Disciplined Agile was acquired by Project Management Institute.
@@ Line 75: / Line 85: @@
 *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.
@@ Line 87: / Line 107: @@
 *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.

← Older revision		Revision as of 17:14, 18 October 2021
Line 9:		Line 9:
	[[File:Workflow of Disciplined DevOps.png\|400px\|The Workflow of Disciplined DevOps]]<br />		[[File:Workflow of Disciplined DevOps.png\|400px\|The Workflow of Disciplined DevOps]]<br />
	source: Project Management Institute		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.

← Older revision		Revision as of 16:37, 18 October 2021
Line 4:		Line 4:
	*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>		*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

@@ Line 3: / Line 3: @@
 *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>
@@ Line 59: / Line 62: @@
 *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

← Older revision		Revision as of 15:56, 18 October 2021
Line 40:		Line 40:


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

@@ Line 33: / Line 33: @@
-[[File:DAD Lean Lifecycle.jpg|400px|DAD Lean Lifecycle]]<br />
+[[File:DAD Lean Lifecycle.jpg|500px|DAD Lean Lifecycle]]<br />
 source OpenXcell
@@ Line 39: / Line 39: @@
 *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.
-DAD Continuous Delivery Agile Lifecycle.jpg|400px|DAD Continuous Delivery Agile Lifecycle]]<br />
 source OpenXcell
@@ Line 46: / Line 47: @@
-[[File:File.png|200px|thumb|left|alt text]]<br />
+[[File:DAD Continuous Delivery Lean Lifecycle.jpg|500px|DAD Continuous Delivery Lean Lifecycle]]<br />
 source OpenXcell
@@ Line 53: / Line 54: @@
-[[File:DAD Continuous Delivery Lean Lifecycle.jpg|400px|DAD Continuous Delivery Lean Lifecycle]]<br />
+[[File:DAD Exploratory-Lean Startup Lifecycle.jpg|500px|DAD Exploratory-Lean Startup Lifecycle]]<br />
 source OpenXcell
@@ Line 60: / Line 61: @@
-[[File:DAD Program Lifecycle.jpg|400px|DAD Program Lifecycle]]<br />
+[[File:DAD Program Lifecycle.jpg|450px|DAD Program Lifecycle]]<br />
 source OpenXcell