1. What is DAD?
1.1. tt requires discipline to follow many agile practices and philosophies
1.2. But, it also requires discipline to:
1.2.1. Reduce the feedback cycle
1.2.2. Learn continuously
1.2.3. Deliver solutions incrementally
1.2.4. Be goal driven
1.2.5. Enterprise aware
1.2.6. Streamline Inception and Transition efforts
1.2.7. Adopt agile governance strategies
1.3. The Disciplined Agile Manifesto
1.3.1. Individuals and interactions over processes and tools
1.3.2. Consumable solutions over comprehensive documentation
1.3.3. Stakeholder collaboration over contract negotiation
1.3.4. Responding to change over following a plan
2. DAD Principles
2.1. 1. Our highest priority is to satisfy the stakeholder through early and continuous delivery of valuable solutions.
2.2. 2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the customer’s competitive advantage.
2.3. 3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
2.4. 4. Stakeholders and developers must work together daily throughout the project.
2.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
2.6. 6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
2.7. 7. Consumable solutions are the primary measure of progress.
2.8. 8. Agile processes promote sustainable delivery. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
2.9. 9. Continuous attention to technical excellence and good design enhances agility.
2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.
2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.
2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
2.13. 13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
2.14. 14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.
2.15. 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
3. DAD Characteristics
3.1. People first
3.1.1. "People, and the way they interact with each other, are the primary determinant of success for a solution delivery project."
3.2. Learning oriented
3.2.1. Domain learning
3.2.2. Process improvement
3.2.3. Technical learning
3.2.4. General strategies
3.3. Agile
3.4. Hybrid
3.4.1. Hybrid agile framework
3.4.1.1. Agile Sources for DAD
3.4.1.1.1. Agile Data (AD)
3.4.1.1.2. Agile Modeling (AM)
3.4.1.1.3. DevOps
3.4.1.1.4. Kanban
3.4.1.1.5. Lean Software Development
3.4.1.1.6. Outside In Dev.
3.4.1.1.7. SAFe
3.4.1.1.8. Scrum
3.4.1.1.9. Unified Process (UP)
3.4.1.1.10. eXtreme Programming (XP)
3.4.1.1.11. ...
3.4.2. DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner
3.5. IT solution focused
3.6. Goal-driven
3.6.1. Goal-Driven, Not Prescriptive
3.7. Delivery focused
3.8. Enterprise aware
3.8.1. Follow corporate conventions
3.8.2. Enhance the organizational ecosystem
3.8.3. Share learnings
3.8.4. Interact with other (potentially non-agile) teams
3.8.5. Questions
3.8.5.1. How can I help my organisation?
3.8.5.2. How can I help my department?
3.8.5.3. How can I help the team?
3.8.5.4. How can I be the best me?
3.9. Risk and value driven
3.9.1. Address common project risks
3.9.1.1. e.g.
3.9.1.1.1. Stakeholder consensus around vision
3.9.1.1.2. Proving the architecture early
3.9.1.1.3. Align with enterprise direction
3.9.1.1.4. Work on things that promote learning early in the lifecycle
3.9.2. Value Driven
3.9.2.1. e.g.
3.9.2.1.1. Work on the most valuable things first
3.9.2.1.2. Continued assessment of project viability and business value
3.9.2.1.3. Determining when sufficient functionality has been produced
3.9.2.1.4. Potentially consumable solutions throughout the lifecycle
3.9.2.1.5. Continually assessing new work against the vision
3.10. Scalable
3.10.1. Agility@scale
4. DAD Teams
4.1. People and the way they collaborate are the primary determinant of success
4.1.1. 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
4.2. The majority of team members should be "generalizing specialists"
4.2.1. Also known as "T-Skiiled" people
4.3. DAD effective teams characteristics:
4.3.1. Are focused
4.3.2. Are tailored to the environment
4.3.3. Are based on trust and respect
4.3.4. Are safe
4.3.5. Provide learning opportunities
4.3.6. Are as small as possible
4.3.7. Have shared workspaces
4.3.8. Are “whole”
4.3.9. Have adequate resources to fulfill their remit
4.3.10. Are accountable
4.3.11. Are self-aware
4.3.11.1. strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly
4.3.11.2. understand how to improve
4.3.12. Are self disciplined
4.3.12.1. commit only to the work which they can accomplish and then perform that work as effectively as possible
4.3.13. Are self-organizing
4.3.13.1. estimate and plan their own work and then proceed to collaborate iteratively to do so
4.3.13.2. within the constraints of appropriate governance
4.3.14. Are enterprise aware
4.3.15. Include dedicated people
4.3.16. Are geographically close
4.3.17. Follow a common strategy
4.3.18. Stay together
4.4. DAD Teams Are Enterprise Aware
4.4.1. DAD teams strive to leverage and enhance the existing organizational eco system wherever possible
4.4.2. Implications:
4.4.2.1. Work closely with enterprise groups
4.4.2.2. Follow existing roadmap(s) where appropriate
4.4.2.3. Leverage existing assets
4.4.2.4. Enhance existing assets
4.5. Team sizes
4.5.1. Large Teams
4.5.1.1. 30 or more people it’s considered large
4.5.2. Medium-Sized Teams
4.5.3. Small Teams
4.6. Geographic distributions of team members
4.6.1. Collocated
4.6.2. Fully Dispersed
4.6.3. Partially Dispersed
4.6.4. Distributed Subteams
4.7. The Rights of Everyone
4.7.1. To be treated with respect
4.7.2. To produce and receive quality work based upon agreed standards
4.7.3. To own the estimation process
4.7.4. To determine how teams resources are allocated
4.7.5. To work in a "safe environment"
4.7.6. To be provided good faith information and decisions in timely manner
4.7.7. To own the team's processes and be enabled to improve them
4.8. The Responsibilities of Everyone
4.8.1. To produce a solution that meets the needs of stakeholders given the resource constraints
4.8.2. To optimize the use of those resources
4.8.3. To be willing to collaborate extensively within your team including those outside your specialty
4.8.4. To share all information including "work in progress"
4.8.5. To coach others in your skills and experience
4.8.6. To expand your knowledge and skills outside your specialty
4.8.7. To validate your work as early as possible, working with others to do so
4.8.8. To attend co-ordination meetings in person or through other means if not collocated
4.8.9. To proactively look for ways to improve team performance
4.8.10. To avoid accepting work outside of the current iteration without consent from the team
4.9. Potential Challenges when Building Teams
4.9.1. You don't have adequate agile mentoring
4.9.2. You don't have team leads that are skilled coaches
4.9.3. You don't have (enough) generalizing specialists
4.9.4. You don't have skilled product owners
4.9.5. Your human resources (HR) department is geared toward staffing traditional teams
4.9.6. You don't have (enough) agile-experienced people
4.9.7. You can't build a whole team
4.9.8. Not everyone is an agile expert
4.9.9. You don't know how to identify agile-experienced people
4.9.10. Some of your staff want/need to be directed and not be self-organizing
5. DAD Roles
5.1. Primary Roles
5.1.1. Stakeholder
5.1.1.1. Includes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodies
5.1.1.2. The people who affect the success of your system and are affected by it.
5.1.1.3. 4 stakeholder categories:
5.1.1.3.1. End users
5.1.1.3.2. Principals
5.1.1.3.3. Partners
5.1.1.3.4. Insiders
5.1.2. Product Owner
5.1.2.1. Owns the product vision, scope and priorities of the solution
5.1.2.2. The Stakeholder "proxy"
5.1.2.3. Go-to person for information on the solution requirements
5.1.2.4. Prioritizes ail work for the team
5.1.2.5. Participant in modeling and acceptance testing
5.1.2.6. Has access to expert stakeholders
5.1.2.7. Facilitates requirements envisioning and modeling
5.1.2.8. Educates team in business domain
5.1.2.9. May demonstrate solution to key stakeholders
5.1.2.10. Monitors and communicates status to stakeholders
5.1.2.11. Negotiates priorities, scope, funding, and schedule
5.1.3. Team Lead
5.1.3.1. Similar (but noit the same) like Scrum Master in Scrum
5.1.3.2. Agile process expert, keeps team focused on achievement of goals, removes impediments
5.1.3.3. Responsible for the effectiveness and continuous improvement of the team's process
5.1.3.4. Facilitates close collaboration between team members
5.1.3.5. Keeps the team focused on the project vision and goals
5.1.3.6. Removes impediments for the team and escalates organizational impediments
5.1.3.7. Protects the team from interruptions and external interference
5.1.3.8. Maintains honest communication between everyone on the project
5.1.3.9. Coaches others in the use of agile practices
5.1.3.10. Prompts the team to discuss and think through issues when they are identified
5.1.3.11. Facilitates decision making (but does not make decisions or mandate internal team activity)
5.1.4. Team Member
5.1.4.1. Cross-functional team members that deliver the solution
5.1.4.2. Is a cross-functional, generalizing specialist
5.1.4.3. On small teams every team member is typically a developer, but on larger teams non-developers may appear
5.1.4.4. Volunteers to do any work that allows the team to most efficiently deliver the work committed to for the iteration
5.1.4.5. Seeks to both learn about other specialties as well as coach others on their own specialty
5.1.4.6. Goes to the product owner for domain information and decisions
5.1.4.7. Works with the architecture owner to evolve the architecture
5.1.4.8. Follows enterprise conventions and leverages and enhances the existing infrastructure
5.1.5. Architecture Owner
5.1.5.1. Owns the architecture decisions and technical priorities, mitigates key technical risks
5.1.5.2. Guides the creation and evolution of the solution's architecture
5.1.5.3. Mentors and coaches team members in architecture practices and issues
5.1.5.4. Understands the architectural direction and standards of your organization and ensures that the team adheres to them
5.1.5.5. Ensures the system will be easy to support by encouraging appropriate design and refactoring
5.1.5.6. Ensures that the system is integrated and tested frequently Has the final decision regarding technical decisions, but doesn't dictate them
5.1.5.7. Leads the initial architecture envisioning effort
5.1.5.8. Works closely with enterprise architecture team (if one exists)
5.1.5.9. Responsible for technical risk mitigation
5.2. Secondary Roles (optional)
5.2.1. Domain Expert (business)
5.2.1.1. 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
5.2.2. Specialist
5.2.2.1. Someone in a specialist role, such as business analyst, program manager, or enterprise architect
5.2.3. Technical Expert
5.2.3.1. Someone with deep technical knowledge, such as a security engineer or user experience (UX) professional, whose help is needed for a short period
5.2.4. Independent Tester
5.2.4.1. A test/quaiity professional outside of the team who validates their work.
5.2.5. Integrator
5.2.5.1. Someone responsible for the operation of the overall team build
5.3. DAD project roles means roles not positions
5.4. DAD project any given person will be in one or more roles
5.5. Individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time
6. DAD Process with Phases (3)
6.1. The DAD basic Lifecycle
6.2. The Agile 3C rhythm
6.2.1. The coordinate-collaborate-conclude rhythm occurs at several scales on a disciplined agile delivery (DAD) project:
6.2.1.1. Release rhythm
6.2.1.2. Iteration rhythm
6.2.1.3. Daily rhythm
6.3. Inception Phase
6.3.1. Also known as: project initiation, startup phase, iteration zero
6.3.2. Goals
6.3.2.1. Form initial team
6.3.2.2. Develop common vision
6.3.2.3. Align with enterprise direction
6.3.2.4. Explore initial scope
6.3.2.5. Identify initial technical strategy
6.3.2.6. Develop initial release plan
6.3.2.7. Secure funding
6.3.2.8. From work environment
6.3.2.9. Identify risks
6.3.2.10. Ongoing goals
6.3.2.10.1. Fulfill the team/project mission
6.3.2.10.2. Grow team members
6.3.2.10.3. Leverage and enhance existing infrastructure
6.3.2.10.4. Address risk
6.3.2.10.5. Improve team process and environamnt
6.3.2.10.6. Coordinate activities
6.3.3. Activities
6.3.4. Patterns
6.3.4.1. Have a short but sufficient Inception phase
6.3.4.2. Ranged estimates
6.3.4.3. Minimal but sufficient documentation
6.3.5. Anti-Patterns
6.3.5.1. No support for skills development
6.3.5.2. No support for dedicated facilities or tooling at scale
6.3.5.3. Autocratic project management practices
6.3.5.4. Jumping into Construction
6.3.5.5. Overly detailed work products
6.3.5.6. Analysis paralysis
6.4. Construction Phase
6.4.1. Goals
6.4.1.1. Produce a potentially consumable solution
6.4.1.2. Address changing stakeholder needs
6.4.1.3. Move closer to deployable release
6.4.1.4. Improve quality
6.4.1.5. Prove architecture early
6.4.1.6. Ongoing goals
6.4.1.6.1. Fulfill the team/project mission
6.4.1.6.2. Grow team members
6.4.1.6.3. Leverage and enhance existing infrastructure
6.4.1.6.4. Address risk
6.4.1.6.5. Improve team process and environamnt
6.4.1.6.6. Coordinate activities
6.4.2. Activities
6.4.3. Patterns
6.4.3.1. The team can be reliably depended on to demonstrate increments of software at the end of each iteration
6.4.3.2. Team members finish their tasks ahead of schedule and ask to help others with their tasks
6.4.3.3. Iteration dates never move
6.4.3.4. Any stakeholder can expect to see a demonstration of working software at any time
6.4.4. Anti-Patterns
6.4.4.1. Incomplete work items at the end of an iteration
6.4.4.2. Inattention to risk mitigation, architecture, or quality
6.4.4.3. Last iteration we planned for X points but delivered less, but we still commit to X this iteration
6.4.4.4. Lack of preparation for iteration planning sessions (little or no look-ahead modeling or planning)
6.4.4.5. Quality decreasing overtime
6.5. Transition Phase
6.5.1. Goals
6.5.1.1. Ensure the solution is production ready
6.5.1.2. Ensure the stakeholders are prepared to receive the solution
6.5.1.3. Deploy the solution into production
6.5.2. Activities
6.5.3. Patterns
6.5.3.1. Short and sufficient
6.5.3.1.1. Short iterations are a sign of good preparation during Construction
6.5.3.2. Multiple iterations
6.5.3.2.1. Multiple iterations of Transition may make sense for large rollouts
6.5.3.3. Proven deployment/installation
6.5.3.3.1. Good continuous integration and deployment practices streamline Transition
6.5.3.4. Choose your release patterns
6.5.3.4.1. You should adapt your release patterns for the context of your organization and project
6.5.4. Anti-Patterns
6.5.4.1. Thinking Transition is a "hardening" phase
6.5.4.2. Not having a production like environment for integration, acceptance, and deployment testing
6.5.4.3. Not having an agreed upon set of entry criteria for going "live"
6.5.4.4. Requests for new functionality
6.5.4.5. Release the system to unprepared users
6.5.4.6. Lengthy integration and user acceptance testing (UAT) cycle in Transition
6.5.4.7. Transferring responsibility for maintaining the system to a maintenance group
6.5.4.8. Moving all of your developers to another project at the end of Construction
6.5.4.9. Not investing in stakeholder training Believing that installation is going to be easy
7. 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.
8. 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!)
8.1. 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.
8.1.1. http://www.linkedin.com/in/miroslawdabrowski
8.1.2. https://www.google.com/+MiroslawDabrowski
8.1.3. https://play.spotify.com/user/miroslawdabrowski/
8.1.4. http://www.miroslawdabrowski.com
8.1.5. https://twitter.com/mirodabrowski
8.1.6. miroslaw_dabrowski
9. Disciplined Agile Delivery (DAD) publications
9.1. Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise
9.1.1. ISBN-13: 978-0132810135
9.1.2. Pages: 544
9.1.3. http://www.amazon.com/Disciplined-Agile-Delivery-Practitioners-Enterprise/dp/0132810131