An Introduction to Disciplined Agile Delivery
While organizations today recognize the benefits, for software development projects, practices of agile methods such as Scrum, Extreme Programming (XP), Lean or Agile Software Development Modeling; there is also a concern about how to scale agile practices at the enterprise level where projects are larger, more dispersed teams work and the architectural, technological and even contractual restrictions are very demanding. The basic methods require important to scale beyond eight teams of people working together in the same place settings.
The DAD can be defined as an iterative and incremental approach to software development that produces regularly and cost-effectively high-quality solutions and at the right time, through a life cycle oriented to risk and the solution value. It is performed in a highly collaborative, disciplined and self-organized way within a governance framework that has active participation of those involved to ensure that the development team understands and applies the evolving needs of the form of actors to maximize the value of business provided by the product (software).

The DAD is a methodology created by IBM Rational that can be seen as an expansion to the Scrum lifecycle in three aspects:
• Explicite phases of the project, recognizing that the delivery of agile project is iterative and also sequential;
• It includes requirements and architecture forecasting practices to the project start to increase the chance of the correct product construction, and contemplate delivery practices of the product in production;
• It includes more robust agile practices (AMBLER, 2012).
The formation of an effective agile team is a crucial point in the DAD and there are some indications that an effective Agile team was formed:
• He has the expertise to get the job done;
• They are as small as possible;
• There are people dedicated to the project;
• It has a unique Product Owner;
• It has a unique team leader (which is not the product owner);
• It has general analysts;
• May include experts, but in the direction of becoming generalists;
• They are self-organized into an appropriate framework for governance.
The more we deviate from this situation, the higher the project risk.
In the image below, we can see the life cycle DAD and its activities. Notice how are explicit project phases (Design, Construction and Transition).

In Disciplined Agile Delivery roles are divided into primary and additional roles.
Primary roles:
• Stakeholders;
• Team Leader;
• Product Owner;
• Team member Nimble;
• Architecture Owner.
• Additional roles:
• Expert in the field;
• Expert technical;
• …
Stakeholders are the people who affect or are affected by the success of the system.
The Product Owner, Scrum as in promoting the goals and vision of the product so that the team can make decisions. He owns the product backlog, defines the scope of a release and when the product is ready to be delivered and deployed.
The Team Leader is responsible for the success of the project and how the ScrumMaster in the Scrum framework facilitates cooperation between roles and functions, remove barriers and problems, protect the external interference team and ensure that the process is followed.
Members of Team Agile are the other members of the team. Also known as developers are generalists, collaborative and self-managed.
The Architecture Owner is responsible for the architecture of the system or subsystems in which the team is working as part of a team of Architecture Owners. He mentor and guides developers in architectural problem and is also a technical team leader. It has the final word on the architecture, but seeks a collaborative approach with your team.
As to additional roles, they are typically large team. The Expert in the Field knows details that are not always the end user domain or stakeholders. We can illustrate this role in the figure of an expert in finance charges. The Expert Technical features detailed areas of expertise, for example, create builds scripts or database. Independent testers are used by teams working regulatory standards or domains and complex technologies. The team may still need Integrators, responsible for the integration of complex subsystems and experts that can focus on issues such as security.

–Slimane Zouggari

The whole method is based on nine principles, all of which are to be applied, the first four define the foundations on which DSDM was built and the remaining five provide the basic principles for the structure of the method.
1. Active involvement of users is essential
This is the main principle. The involvement is not only active, but even proactive.
In DSDM this is the contribution of users evenly.
2. DSDM teams must be empowered to make decisions
Team members must be able to make quick decisions on the way forward.
Characteristic of DSDM is indeed a tight schedule. There is no time for long decision-making. The team members must have clarity about the boundaries, within which they can operate. An important limitation is, of course, the budget.
3. Frequent delivery of goods is of essential importance
By planning a regular completion (say weekly) of something tangible and sight perch one creates a safety net for reversal of bad decisions that managers do not feel the controls to be lost. The products do not have to be complete, as long as they progress in the proper direction show.
4. Fitness for business purposes is essential for the acceptance of products
The principle means that the developer does not remain stabbing at some point because he wants to make gold rimmed solution. The suitability for business purpose has starting point, certain technical issues can be postponed.
5. Iterative and incremental development is necessary in order to converge to right solution
If the team includes users who provide feedback almost immediately on the work of the developers, it is possible to carry out system development step by step instead of in one go. Because systems are developed piecemeal, DSDM ensures that errors are detected early
6. All changes during development are turning back
This means that there has to be immaculate from a management of all software and related documentation.
7. Requirements are set at high level
Demands collected during the Business Analysis to determine the scope of the project. These requirements should be clearly defined well.
8. Testing is integrated in the life cycle
The philosophy of DSDM is “test as you go.” All tests, including acceptance testing, are progressively implemented during the project.
9. A collaborative and cooperative attitude of all stakeholders is essential
Not only collaborate and cooperate are important, but all is equally important. Participants in this approach become involved. Any existing artificial partitions between and within departments work mainly in DSDM.

–Slimane Zouggari