Disciplined Agile Delivery

Disciplined Agile Delivery by Scott Ambler

It is ironic to start reading a book about a new Agile approach and to find the following quote in it: “The explosion of “branded” agile methods has resulted in a jargon-filled confusion of siloed tribes made up of uncollaborative zealots. — Mark Kennaley, Author SDLC 3.0” Disciplined Agile Delivery (DAD) is defined as “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 process 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.”

Disciplined Agile Delivery is strongly influenced by RUP and by Scott Ambler’s Agile Modeling and Agile Data approaches that are often cited in the additional resource sections. Starting with the realistic diagnostic that many teams are unable to customize up or down existing software development processes for their own context, the authors have tried to provide a hybrid, goal-driven and lightweight (although it needs 500 pages to describe it) process that will provide a “start from the middle” way.

The question remains open if teams that are unable to customize other approaches could easily absorb and adopt DAD? There might be a partial answer in the book “Your organization needs to invest in mentoring, training, and education. Taking an agile course is a great start. Utilizing an experienced DAD coach/mentor is even better for ensuring that your team’s adoption of agile is accelerated and supported with guidance related to actual hands-on experience.” This is an IBM book and you have sometimes the feeling that selling you the quality of IBM consulting and Rational tools is not always done in a subtle way.

The book has a strong emphasis on the importance of architecture role and the need to spend adequate time in the inception phase to plan your project. The book is well-structured with many tables presenting the potential advantages and disadvantages of the options available, providing guidance on what to use and when to use it. Case study chapters are inserted to support the theoretical material.

People used to evolve in large companies supported by IBM and adopters of the Agile Modeling and Agile Data approaches will find in this book most of the material they need or like, organized around the project life cycle. Other Agile people might be interested in the Inception (sprint zero / project planning) phase content that explore in 200 pages the needs of larger projects in terms of architecture and release planning. There is even a “Example Three-Week Inception Phase Schedule” with a list of morning and afternoon activities. ;O) For people who want to try their own “scaling up” way from Scrum, the two books Scaling Lean & Agile Development from Craig Larman and Bas Vodde should provide a more appropriate material.

Reference: Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise, Scott Ambler and Mark Lines, 495 pages, IBM Press

Quotes

As we’ve helped various organizations improve their software processes over the years, we’ve come to the belief that the various process protagonists 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 lightweight process descriptions, with Scrum being a perfect example. The challenge with RUP is that many teams do not have the skill to tailor it down appropriately, often resulting in 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 reinventing or relearning techniques to address the myriad issues that Scrum doesn’t cover (this becomes apparent in Chapter 3). Either way, a lot of waste could have been avoided if only there was an option between these two extremes.

While we are confident that companies that adopt agile will differentiate themselves from their competitors, this will only happen if agile is applied in an enterprise appropriate, “disciplined” fashion. Many of agile’s practices are disciplined by nature, but applying them appropriately in the context that makes sense is where the “disciplined” in DAD makes the difference between success and failure in your agile adoption.

Potential Disadvantages of Test-Driven Development: Takes discipline to ensure tests are actually written before the code. Takes time; tests may have their own defects or be poorly designed.