Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

Disciplined Agile Delivery (DAD) study guide mind map by Mind Map: Disciplined Agile Delivery
(DAD) study guide mind map
5.0 stars - 4 reviews range from 0 to 5

Disciplined Agile Delivery (DAD) study guide mind map

What is DAD?

tt requires discipline to follow many agile practices and philosophies

But, it also requires discipline to:

Reduce the feedback cycle

Learn continuously

Deliver solutions incrementally

Be goal driven

Enterprise aware

Streamline Inception and Transition efforts

Adopt agile governance strategies

The Disciplined Agile Manifesto

Individuals and interactions over processes and tools

Consumable solutions over comprehensive documentation

Stakeholder collaboration over contract negotiation

Responding to change over following a plan

DAD Principles

1. Our highest priority is to satisfy the stakeholder through early and continuous delivery of valuable solutions.

2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

4. Stakeholders and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.

7. Consumable solutions are the primary measure of progress.

8. Agile processes promote sustainable delivery. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity - the art of maximizing the amount of work not done - is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.

14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.

15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, vet be sufficiently flexible to still support non-agile or hybrid teams

DAD Characteristics

People first

"People, and the way they interact with each other, are the primary determinant of success for a solution delivery project."

Learning oriented

Domain learning

Process improvement

Technical learning

General strategies



Hybrid agile framework, Agile Sources for DAD, Agile Data (AD), Agile Modeling (AM), DevOps, Kanban, Lean Software Development, Outside In Dev., SAFe, Scrum, Unified Process (UP), eXtreme Programming (XP), ...

DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner

IT solution focused


Goal-Driven, Not Prescriptive

Delivery focused

Enterprise aware

Follow corporate conventions

Enhance the organizational ecosystem

Share learnings

Interact with other (potentially non-agile) teams

Questions, How can I help my organisation?, How can I help my department?, How can I help the team?, How can I be the best me?

Risk and value driven

Address common project risks, e.g., Stakeholder consensus around vision, Proving the architecture early, Align with enterprise direction, Work on things that promote learning early in the lifecycle

Value Driven, e.g., Work on the most valuable things first, Continued assessment of project viability and business value, Determining when sufficient functionality has been produced, Potentially consumable solutions throughout the lifecycle, Continually assessing new work against the vision



DAD Teams

People and the way they collaborate are the primary determinant of success

Team works together to deliver the work that they have committed to deliver to the product and architecture owners at the beginning of each iteration

The majority of team members should be "generalizing specialists"

Also known as "T-Skiiled" people

DAD effective teams characteristics:

Are focused

Are tailored to the environment

Are based on trust and respect

Are safe

Provide learning opportunities

Are as small as possible

Have shared workspaces

Are “whole”

Have adequate resources to fulfill their remit

Are accountable

Are self-aware, strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly, understand how to improve

Are self disciplined, commit only to the work which they can accomplish and then perform that work as effectively as possible

Are self-organizing, estimate and plan their own work and then proceed to collaborate iteratively to do so, within the constraints of appropriate governance

Are enterprise aware

Include dedicated people

Are geographically close

Follow a common strategy

Stay together

DAD Teams Are Enterprise Aware

DAD teams strive to leverage and enhance the existing organizational eco system wherever possible

Implications:, Work closely with enterprise groups, Follow existing roadmap(s) where appropriate, Leverage existing assets, Enhance existing assets

Team sizes

Large Teams, 30 or more people it’s considered large

Medium-Sized Teams

Small Teams

Geographic distributions of team members


Fully Dispersed

Partially Dispersed

Distributed Subteams

The Rights of Everyone

To be treated with respect

To produce and receive quality work based upon agreed standards

To own the estimation process

To determine how teams resources are allocated

To work in a "safe environment"

To be provided good faith information and decisions in timely manner

To own the team's processes and be enabled to improve them

The Responsibilities of Everyone

To produce a solution that meets the needs of stakeholders given the resource constraints

To optimize the use of those resources

To be willing to collaborate extensively within your team including those outside your specialty

To share all information including "work in progress"

To coach others in your skills and experience

To expand your knowledge and skills outside your specialty

To validate your work as early as possible, working with others to do so

To attend co-ordination meetings in person or through other means if not collocated

To proactively look for ways to improve team performance

To avoid accepting work outside of the current iteration without consent from the team

Potential Challenges when Building Teams

You don't have adequate agile mentoring

You don't have team leads that are skilled coaches

You don't have (enough) generalizing specialists

You don't have skilled product owners

Your human resources (HR) department is geared toward staffing traditional teams

You don't have (enough) agile-experienced people

You can't build a whole team

Not everyone is an agile expert

You don't know how to identify agile-experienced people

Some of your staff want/need to be directed and not be self-organizing

DAD Roles

Primary Roles

Stakeholder, Includes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodies, The people who affect the success of your system and are affected by it., 4 stakeholder categories:, End users, Users of the system, Principals, Decision makers that pay for and put the system to use, Partners, People who make the system work in production, Insiders, Members of the development team and people who provide business and technical services to the team

Product Owner, Owns the product vision, scope and priorities of the solution, The Stakeholder "proxy", Go-to person for information on the solution requirements, Prioritizes ail work for the team, Participant in modeling and acceptance testing, Has access to expert stakeholders, Facilitates requirements envisioning and modeling, Educates team in business domain, May demonstrate solution to key stakeholders, Monitors and communicates status to stakeholders, Negotiates priorities, scope, funding, and schedule

Team Lead, Similar (but noit the same) like Scrum Master in Scrum, Agile process expert, keeps team focused on achievement of goals, removes impediments, Responsible for the effectiveness and continuous improvement of the team's process, Facilitates close collaboration between team members, Keeps the team focused on the project vision and goals, Removes impediments for the team and escalates organizational impediments, Protects the team from interruptions and external interference, Maintains honest communication between everyone on the project, Coaches others in the use of agile practices, Prompts the team to discuss and think through issues when they are identified, Facilitates decision making (but does not make decisions or mandate internal team activity)

Team Member, Cross-functional team members that deliver the solution, Is a cross-functional, generalizing specialist, On small teams every team member is typically a developer, but on larger teams non-developers may appear, Volunteers to do any work that allows the team to most efficiently deliver the work committed to for the iteration, Seeks to both learn about other specialties as well as coach others on their own specialty, Goes to the product owner for domain information and decisions, Works with the architecture owner to evolve the architecture, Follows enterprise conventions and leverages and enhances the existing infrastructure

Architecture Owner, Owns the architecture decisions and technical priorities, mitigates key technical risks, Guides the creation and evolution of the solution's architecture, Mentors and coaches team members in architecture practices and issues, Understands the architectural direction and standards of your organization and ensures that the team adheres to them, Ensures the system will be easy to support by encouraging appropriate design and refactoring, Ensures that the system is integrated and tested frequently Has the final decision regarding technical decisions, but doesn't dictate them, Leads the initial architecture envisioning effort, Works closely with enterprise architecture team (if one exists), Responsible for technical risk mitigation

Secondary Roles (optional)

Domain Expert (business), Someone with deep knowledge of the domain, such as a legal expert or marketing expert who is brought in as needed to share their expertise

Specialist, Someone in a specialist role, such as business analyst, program manager, or enterprise architect

Technical Expert, Someone with deep technical knowledge, such as a security engineer or user experience (UX) professional, whose help is needed for a short period

Independent Tester, A test/quaiity professional outside of the team who validates their work.

Integrator, Someone responsible for the operation of the overall team build

DAD project roles means roles not positions

DAD project any given person will be in one or more roles

Individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time

DAD Process with Phases (3)

The DAD basic Lifecycle

The Agile 3C rhythm

The coordinate-collaborate-conclude rhythm occurs at several scales on a disciplined agile delivery (DAD) project:, Release rhythm, Iteration rhythm, Daily rhythm

Inception Phase

Also known as: project initiation, startup phase, iteration zero

Goals, Form initial team, Develop common vision, Align with enterprise direction, Explore initial scope, Identify initial technical strategy, Develop initial release plan, Secure funding, From work environment, Identify risks, Ongoing goals, Fulfill the team/project mission, Grow team members, Leverage and enhance existing infrastructure, Address risk, Improve team process and environamnt, Coordinate activities


Patterns, Have a short but sufficient Inception phase, Ranged estimates, Minimal but sufficient documentation

Anti-Patterns, No support for skills development, No support for dedicated facilities or tooling at scale, Autocratic project management practices, Jumping into Construction, Overly detailed work products, Analysis paralysis

Construction Phase

Goals, Produce a potentially consumable solution, Address changing stakeholder needs, Move closer to deployable release, Improve quality, Prove architecture early, Ongoing goals, Fulfill the team/project mission, Grow team members, Leverage and enhance existing infrastructure, Address risk, Improve team process and environamnt, Coordinate activities


Patterns, The team can be reliably depended on to demonstrate increments of software at the end of each iteration, Team members finish their tasks ahead of schedule and ask to help others with their tasks, Iteration dates never move, Any stakeholder can expect to see a demonstration of working software at any time

Anti-Patterns, Incomplete work items at the end of an iteration, Inattention to risk mitigation, architecture, or quality, Last iteration we planned for X points but delivered less, but we still commit to X this iteration, Lack of preparation for iteration planning sessions (little or no look-ahead modeling or planning), Quality decreasing overtime

Transition Phase

Goals, Ensure the solution is production ready, Ensure the stakeholders are prepared to receive the solution, Deploy the solution into production


Patterns, Short and sufficient, Short iterations are a sign of good preparation during Construction, Multiple iterations, Multiple iterations of Transition may make sense for large rollouts, Proven deployment/installation, Good continuous integration and deployment practices streamline Transition, Choose your release patterns, You should adapt your release patterns for the context of your organization and project

Anti-Patterns, Thinking Transition is a "hardening" phase, Not having a production like environment for integration, acceptance, and deployment testing, Not having an agreed upon set of entry criteria for going "live", Requests for new functionality, Release the system to unprepared users, Lengthy integration and user acceptance testing (UAT) cycle in Transition, Transferring responsibility for maintaining the system to a maintenance group, Moving all of your developers to another project at the end of Construction, Not investing in stakeholder training Believing that installation is going to be easy

Disciplined Agile Delivery (DAD) - an iterative, incremental and adaptive (change-driven / empirical) agile project management method and framework (not just framework like Scrum) for general (not industry specific e.g. IT or Engineering) agile project management.

This freeware, non-commercial mind map (aligned with the newest version of Disciplined Agile Delivery (DAD)) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the Disciplined Agile Delivery (DAD) method and as a learning tool for candidates wanting to gain Disciplined Agile Delivery (DAD) qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.


Disciplined Agile Delivery (DAD) publications

Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise

ISBN-13: 978-0132810135

Pages: 544