Disciplined Agile Delivery

The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value life cycle, is goal-driven, and is enterprise aware.

There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven 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 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 effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.
Roles
The DAD framework distinguishes between primary roles that are commonly found regardless of the level of scale and secondary roles that typically occur only at scale.
There are five primary roles:
# Stakeholder. A stakeholder is someone who is materially impacted by the outcome of the solution.
# 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.
# Team Lead. The team lead is 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.
# Product Owner. 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. This role is adopted from Scrum.
# Architecture Owner. Architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk. 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 role is adopted from Agile Modeling.
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.
# Domain Expert. 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.
# 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.
# Integrator. In very complex situations the overall team, which may be organized as a team of subteams, may require one or more people in the role of integrator responsible for building the entire system from its various subsystems.
Full Delivery Lifecycle
One of the key aspects of the DAD framework is that it promotes a full, end-to-end, solution delivery lifecycle. What's very interesting is that it doesn't promote a single lifeycle but instead suggests that you choose one, and then tailor it as needed, which best suits the situation you find yourself in. Because one process does not fit all, it doesn't make sense to prescribe a single lifecycle as we see in some methodologies. There are currently three versions of the DAD lifecycle to choose from:
# Basic/agile. This lifecycle extends the Scrum construction lifecycle to explicitly include initiation/inception, construction, and transition/deployment activities. This is often the starting point for teams that adopt DAD as there is a clear adoption path to this lifecycle from either Scrum-based approaches or Unified process-based approaches.
# Advanced/lean. This lifecycle is based on ideas from Kanban and Lean Software Development. Experienced agile teams will often evolve the basic/agile lifecycle
# Continuous delivery. This is a modification of the lean lifecycle where continuous delivery practices have been explicitly tailored in.
History
The development of the DAD framework was led by Scott Ambler while he was at IBM in their IBM Rational division, starting in mid 2007. The framework was applied at several IBM clients around the work, and evolved based on those experiences plus experiences within IBM itself, over a several year period. The DAD process framework was first described in an IBM whitepaper and in greater detail in a 2012 IBM Press book . The DAD framework continues to evolve on LinkedIn and the DAD blog .
Limitations
The focus of the DAD framework is on the delivery of software-based solutions from project/product initiation to deployment into production (or the marketplace). It does not address cross-project IT concerns such as Enterprise Architecture nor Portfolio Management to name two. Other methodologies, such as Enterprise Unified Process or ITIL, are better suited for that.

Main Menu

See Also

Main Menu