• Home
  • Learn
  • Books
  • Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterpri

 

          
 
                   

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

       IBM Press 
ISBN: 0132810131

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

Overview

The Disciplined Agile Delivery (DAD) process decision framework, as described in this book, is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), and Unified Process (UP), amongst other methods.  DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users.  The DAD framework includes advice about the technical practices purposely missing from Scrum as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. More importantly, in many cases DAD provides advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.

Our focus in DAD is on delivery, although we discuss how the other aspects of the system lifecycle affect the delivery lifecycle.  A full system/product lifecycle goes from the initial idea for the product, through delivery, to operations and support and often has many iterations of the delivery lifecycle.  DAD addresses agile practices across the entire delivery lifecycle, from requirements, architecture, and development to delivery and governance. The book shows how these best-practice techniques fit together in an end-to-end process for successfully delivering large, complex systems--from project initiation through delivery.  This includes: 

  • Scaling agile for mission-critical enterprise endeavors
  • Avoiding mistakes that drive poorly run agile projects to chaos
  • Effectively initiating an agile project
  • Transitioning as an individual to agile
  • Incrementally building consumable solutions
  • Deploying agile solutions into complex production environments
  • Leveraging DevOps, architecture, and other enterprise disciplines
  • Adapting your governance strategy for agile projects

Based on facts, research, and extensive experience, this book will be an indispensable resource for every enterprise software leader and practitioner--whether they’re seeking to optimize their existing agile/Scrum process or improve the agility of an iterative process.

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.  

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 Buy It

 Amazon US

Amazon UK

Amazon Canada

InformIT

IBM Press 

                          



 

  Order your copy now!



Translations

This book has been translated into several languages.  If you click on the following images you will be taken to sites where you can order the book.

  
(Chinese)(Japanese)(Korean)


About Disciplined Agile Delivery (DAD)

The Disciplined Agile Delivery (DAD) process decision 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.
 © 2014-2017 Disciplined Agile Consortium


Powered by Wild Apricot Membership Software