Disciplined Agile

Looking for some great DAD video content?  Trying to find just the right video to show your boss why moving beyond Scrum to DAD makes sense?  Well we are happy to announce that there is now a DAD YouTube Channel which can be found here:  https://www.youtube.com/channel/UCcWJ20C86Mzxcsqb73AReHQ  Subscribe to keep up to date on the latest DAD talks and webinars.  There is also a new link to this channel at the DAD blog website on the sidebar.

We are looking for multilingual presentations so if you are aware of any let us know.  For now we have added a talk in Russian.

Last week I was discussing DAD with a new client and he asked me “Is DAD just an Agile version of RUP?”  In a word, no.  DAD is a toolkit composed of a hybrid of methods and practices as shown in the diagram.  It includes the best of Scrum, Extreme Programming (XP), Agile data and modeling, and yes, the Unified Process (UP).  DAD also includes additional content such as agile governance that is not present in any of these methods.  As the diagram indicates, probably the method that adds most to DAD is XP, not the UP.
The Rational Unified Process (RUP) started as a small manageable process framework targeted specifically for building software within the context of an iterative lifecycle.  However over time, Rational (and subsequently IBM) added additional guidance and artifacts to extend the applicability of RUP to all sorts of projects, such as package implementation, maintenance projects, technology specific guidance (J2EE, .Net etc.), systems engineering and may other project types.  It became unwieldy and hard to understand and apply successfully.  In fact it is frequently misused (with the Elaboration phase often being treated as a big requirements upfront (BRUF) phase as an example).  This misuse has been described by Julian Holmes as RINO (RUP in name only).  To be clear, RUP properly applied in the right circumstances can be very effective.  Unfortunately though, that often does not happen.  One of the issues with applying the RUP framework to different types of projects is that it is described as a “Use case-driven” approach.  Specifying requirements as use cases, and then creating component-based architecture from these use case realizations is fundamental to RUP.  This presents challenges for maintenance projects or package implementations where it may not make sense to produce use cases at all.

DAD does not prescribe a use case-driven approach, or insist that OOAD be rigorously applied to build out services/components.  A use case-driven approach is a potential practice to apply but there is a danger that this could lead to an exhaustive requirements specification which is not particularly agile.  We would prefer to use a user story-driven approach if that makes sense within the context of your project.  User stories might not be the right choice either.  Perhaps you are in a regulatory environment that demands a traditional software requirements specification (SRS).  The key point is that you will have to adapt to the situation that you find yourself in.  This is why we prioritize the team’s work with a work item list comprised of work items, rather than Scrum’s backlog comprised of user stories.  Using a work item list allows us the flexibility to put any type of work onto our backlog, extending the applicability of DAD to many types of projects beyond those for which RUP or Scrum would be ideally suited.

DAD is goal-driven, not artifact-driven.  It does not prescribe practices or specific artifacts.  Rather, it suggests alternative strategies than can be applied at certain parts of the lifecycle with the pros and cons for each, but which ones you choose is up to you.

In my next post I will describe which aspects of the Unified Process did make it into DAD and why.

There are some differences as well as some similarities when comparing agile adoption to agile transformation.  Which does the DAD book address?  One or the other, or both?  I know that I have my opinion, but I am interested in yours.  Add your comments and let us know what you think.  Then we can discuss.

I think that this blog has been quite successful in getting the word out about Disciplined Agile Delivery (DAD) and describing key aspects of the toolkit in advance of the book being released.  However, now that the book is out, it makes sense to evolve the blog into a forum for deeper discussions about DAD.  Scott and I would also like to use it as a medium to answer detailed questions about anything from the book.

Anyone who supports DAD is encouraged to become a contributor to be able to blog a new topic for discussion.  If you wish to become a contributor, send me a note at [email protected]

If you don’t wish to become a contributor directly but have a DAD question, send the question to me and I will post it for discussion.  Thanks!

I think that this blog has been quite successful in getting the word out about Disciplined Agile Delivery (DAD) and describing key aspects of the toolkit in advance of the book being released.  However, now that the book is out, it makes sense to evolve the blog into a forum for deeper discussions about DAD.  Scott and I would also like to use it as a medium to answer detailed questions about anything from the book.

Anyone who supports DAD is encouraged to become a contributor to be able to blog a new topic for discussion.  If you wish to become a contributor, send me a note at [email protected]

If you don’t wish to become a contributor directly but have a DAD question, send the question to me and I will post it for discussion.  Thanks!