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