Skip to content

Book Review of “Disciplined Agile Delivery”

November 25, 2012

First, some disclaimers:  I am not an Agile purist.  My experience is that Agile is appropriate for some organizations, but not apropos for others.  I am of the opinion that each business must evolve a software development process that produces results which speed the business in its drive toward niche leadership, rather than holding it back.  I am in no way receiving any kind of compensation for writing this positive review.

For the past 6 years I have worked as a Software Engineer in organizations using Agile methods, 2 of them using Scrum.  I’ve also been trained in Scrum Planning Poker, plus have read two other books on Agile.  So, I have seen the positives and negatives involved with using Agile processes.  Prior to that I did development under Waterfall and “Code like hell” processes and have likewise experienced their strengths and weaknesses.  My goal here is to review Disciplined Agile Delivery and its usefulness in improving Agile processes, rather than commenting on the strengths and weaknesses of Agile, Waterfall, or any other software development processes.

In September and October 2012 I read Disciplined Agile Delivery:  A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott Ambler and Mark Lines, 2012 IBM Press.  This was in preparation for a periodic revision of the Scrum process then in place at my job.  Our Scum retrospectives had surfaced ways that our software development process could be significantly improved, and Disciplined Agile Delivery came out at just the right time.

Bottom line:  If you are using Agile process for software development, Disciplined Agile Delivery can be a very big help to making the process much more effective.  The authors have essentially defined the Disciplined Agile Delivery process (DAD), documented the process in this book, and provide lots of very useful examples of how to use the DAD process.

Here are the main things that contributed the greatest value to me, as a reader of this book and a participant in Agile processes:

1.      The book is strongly based on the empirical data of a large body of research, both that conducted by the authors and others.  It is not an idealistic manifesto, but rather the rational application of research to improve the Agile process of the past.

2.      The main focus of Disciplined Agile Delivery is using Discipline to shape an effective, repeatable Agile process that Delivers much of what organizations need:  1) Running, tested software with features that satisfy user wants and needs, and 2) A software code base that is more cost effectively extensible and maintainable than one produced by “Code like hell” methods without architecture.  This is accomplished by the following techniques.

3.      Breaking each long term project up into 3 phases, each of which might have  more than a single iteration within a phase.  These phases are the Inception Phase, the Construction Phase, and the Transition Phase.  My experience leads me to think this adds much value, since a project is not all Construction as in some Agile processes.  There are necessary things that need to be done at the start and end of a long project so it’s better to call them out specifically.

4.      The book clearly defines the roles of an Agile team, and the responsibilities and goals of each role:  From Stake Holder, to Product Owner, to Team Lead, to Team Member, etc.  And, by the way, it includes the critical role of Architecture Owner whose responsibilities include doing the high level architecture, plus owing the code, i.e. generally ensuring the code base resulting from the project meets the supplemental requirements (e.g. performance, extensibility, maintainability, etc.) and thus becomes a high value asset for the organization owning it.  Note the Architect Owner role has the potential to significantly reduce the refactoring (rework) costs of an Agile code base, when compared to one that was developed on an ad hoc basis without architecture.

5.      Throughout the book ways of reducing the risks in the project are delineated, and incorporated into the DAD process.

6.      The authors advocate that all work items be placed on the project backlog, not just the features as is the general practice in Scrum.  This gives clear visibility to all the work that must be done:  Requirements analysis for a feature, Gui design for the feature, refactoring of existing code, detailed design, coding, building unit and system tests, etc.  And it provides the ability to prioritize the work item backlog at the start of each iteration.  There is no work hidden by not being on the backlog.

7.      The book is written in a very useful way, with theory, practices, and plenty of examples on how one can use the DAD process.

If you want to improve your Agile process, definitely use the techniques presented in Disciplined Agile Delivery

Creative Commons License dotnetsilverlightprism blog by George Stevens is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: