Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines, IBM Press, ISBN: 0132810131
Home  |  Articles  |  Books  |  IT Surveys  |  Podcasts  |  Contact Us  |  Announcements  |  Site Map

The Disciplined Agile Delivery (DAD) book describes the DAD process framework, a third-generation agile methodology.

• Introduction to DAD
• Table of contents
• How to obtain this book
• Tell your friends
• Related reading

Introduction to Disciplined Agile Delivery (DAD)

This book describes the Disciplined Agile Delivery (DAD) process framework in detail, working through a case study to show how it can be applied in practice.  The DAD process framework has several important characteristics:

• People first. DAD team members should be self-disciplined and DAD teams should be self organizing and self aware. The DAD process framework provides guidance which DAD teams leverage to improve their effectiveness, but it does not prescribe mandatory procedures. In DAD we foster the strategy of cross-functional teams made up of cross-functional people (generalizing specialists). There should be no hierarchy within the team, and team members are encouraged to be cross-functional in their skill set and indeed perform work related to disciplines other than their original specialty.
• Learning oriented.  In the years since the Agile Manifesto, we’ve discovered that the most effective organizations are the ones that promote a learning environment for their staff. There are three key aspects which a learning environment must address. The first is domain learning – how are you exploring and identifying what your stakeholders need, and perhaps more importantly how are you helping them to do so?  The second is learning to improve your process at the individual, team, and enterprise levels. The third is technical learning, which focuses on understanding how to effectively work with the tools and technologies being used to craft the solution for your stakeholders.
• Agile. The DAD process framework adheres to and enhances the values and principles of the Agile Manifesto. Teams following either iterative or agile processes have been shown to produce higher quality, provide greater return on investment (ROI), provide greater stakeholder satisfaction, and deliver quicker as compared to either a traditional/waterfall approach or an ad-hoc (no defined process) approach.
• Hybrid. DAD is the formulation of many strategies and practices from both mainstream agile methods as well as other sources. The DAD process framework extends the Scrum construction lifecycle to address the full delivery lifecycle while adopting strategies from several agile and lean methods.  These sources include Scrum, Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban, and several others.
• IT solution focused. The DAD approach will advance your focus from producing software to providing solutions --which is where real business value lies for your stakeholders. A fundamental observation is that as IT professionals we do far more than just develop software. Yes, software is clearly important, but in addressing the needs of our stakeholders we will often provide new or upgraded hardware, change the business/operational processes that stakeholders follow, and even help change the organizational structure in which our stakeholders work.
• Full delivery lifecycle.  DAD addresses the project lifecycle from the point of initiating the project through construction to the point of releasing the solution into production. We explicitly observe that each iteration is NOT the same. Projects do evolve and the work emphasis changes as we move through the lifecycle. To make this clear, we carve the project into phases with light-weight milestones to ensure that we are focused on the right things at the right time, such as initial visioning, architectural modeling, risk management, and deployment planning. This differs from mainstream agile methods, which typically focus on the construction aspects of the lifecycle; details about how to perform initiation and release activities, or even how they fit into the overall lifecycle, are typically vague and left up to you. 
• Goals driven. One of the challenges in describing a process framework is that you need to provide sufficient guidance to help people understand it, but if you provide too much guidance you become overly prescriptive. As we’ve helped various organizations improve their software processes over the years, we’ve come to believe that the various process proponents are coming from one extreme or the other. Either there are very detailed processes descriptions -- the IBM Rational Unified Process (RUP) is one such example -- or there are very light-weight process descriptions, Scrum being a perfect example. The challenge with RUP is that many teams didn’t have the skill to tailor it down appropriately, often resulting extra work being performed. On the other hand many Scrum teams had the opposite problem with not knowing how to tailor it up appropriately, resulting in significant effort spent reinventing or relearning techniques to address the myriad issues that Scrum doesn’t cover. Either way, a lot of waste could have been avoided if only there was an option between these two extremes.
• Risk and value driven. The DAD process framework adopts what is called a risk/value lifecycle; effectively, this is a light-weight version of the strategy promoted by the Unified Process (UP). DAD teams strive to address common project risks, such as coming to stakeholder consensus around the vision and proving the architecture, early in the lifecycle. DAD also includes explicit checks for continued project viability, whether sufficient functionality has been produced, and whether the solution is production ready. It is also value-driven, a strategy which reduces delivery risk, in that DAD teams produce potentially consumable solutions on a regular basis.
• Enterprise aware.  With the exception of start-up companies, agile delivery teams don’t work in a vacuum. There are often existing systems currently in production, and minimally your solution shouldn’t impact them although your solution should leverage existing functionality and data available in production. There are often other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa. There may be a common vision which your organization is working towards, a vision which your team should contribute to. There will be a governance strategy in place, although it may not be obvious to you, which hopefully enhances what your team is doing.  Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you.

The Book's Table of Contents

The book is organized in following manner:

Part 1: Introduction to Disciplined Agile Delivery (DAD)

• Chapter 1: Disciplined Agile Delivery in a Nutshell

• Chapter 2: Introduction to Agile and Lean

• Chapter 3: Foundations of Disciplined Agile Delivery

Part 2: People First

• Chapter 4: Roles, Rights, and Responsibilities

• Chapter 5: Forming Disciplined Agile Delivery Teams

Part 3:  Initiating a Disciplined Agile Delivery Project

• Chapter 6: The Inception Phase

• Chapter 7: Identifying a Project Vision

• Chapter 8: Identifying the Initial Scope

• Chapter 9: Identifying an Initial Technical Strategy

• Chapter 10: Initial Release Planning

• Chapter 11: Forming the Work Environment

• Chapter 12: Case study: Inception phase

Part 4: Building a Consumable Solution Incrementally

• Chapter 13: The Construction Phase

• Chapter 14: Initiating a Construction Iteration

• Chapter 15: A Typical Day of Construction

• Chapter 16: Concluding a Construction Iteration

• Chapter 17: Case study: Construction phase

Part 5: Releasing the Solution

• Chapter 18:  The Transition Phase

• Chapter 19:  Case study: Transition phase

Part 6:  Disciplined Agile Delivery in the Enterprise

• Chapter 20: Governing Disciplined Agile Teams

• Chapter 21: Got Discipline?

How to Obtain this Book

Tell Your Friends

Related Resources

• DisciplinedAgileDelivery.com -- The home page for all things DAD!
• Disciplined Agile Delivery: An Introduction -- An IBM Whitepaper
• How to Write a Technical Book

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.