Project Management

Comparing DAD to the Rational Unified Process (RUP) - Part 1

From the Disciplined Agile Blog
by , , , , , ,

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Disciplined Agile Certification Training Goes Virtual

Videoconferencing Tips - How to Have Effective Calls

Examining the differences between DA and existing PMI materials

Spotlight on Product Portfolio Funding

Spotlight on Optimizing Flow



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.

Posted by Mark Lines on: August 25, 2012 02:45 PM | Permalink

Comments (0)

Please login or join to subscribe to this item


Please Login/Register to leave a comment.

ADVERTISEMENTS

"The face of a child can say it all, especially the mouth part of the face."

- Jack Handey

ADVERTISEMENT

Sponsors