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

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.

Have any Question or Comment?

9 comments on “Comparing DAD to the Rational Unified Process (RUP) – Part 1

Gijs van Dulmen


Really nice to see more comparisons between other methods on the blog. This solves a lot of questions for people considering DAD. The how-do-I-tell-my-manager questions 🙂

I love the consultancy opinion concept in DAD. The “It all depends” reasoning. Everything makes sense in some context. Doing the right thing on the right moment.

At our company we’re thinking about the concepts of DAD and what it would bring towards a new tool which aids in the process tailoring. Giving a guidance tool with reasonings on what step to take in the process depending on the current context.


Scrum has a product backlog with prodict backlog items on it (Scrum Guide 2011). No prescription of requirements format there.

Having criteria for choosing aparoach A or B can be a helpful. Look forward to your next post.


Thanks for your feedback, and the reminder to do “Part 2” 🙂

Hermann Helmoholtz

Amazing stuff:

“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.”

Now, whoever wants that?

The problem with this new fad is that no two persons, generously called ‘specialists’ or ‘experts’ have an agreement on what is Agile. Indeed, one champion of Agile centers his argument on Use Cases, while our ‘specialist’ here dismisses the desire to have any details which may help in finishing the job fast… with real agility!

This is likely to be one of the shortest-lived fads in technology. Agile now has more interpretations than letters in its name… and the problem is that no one is really adopting any of that. Most enterprises who claim to be on the bandwagon have merely renamed their usual development practices as ‘agile,’ with the Project manager delighted with the chance of receiving every morning a ‘Stand Up’ report to fill his book – Period!

But that is only logical!


I agree that some teams are unfortunately claiming to be agile by only doing daily stand-ups when every other aspect of their project is traditional and clearly not agile. This often comes from a lack of proper agile training and coaching. There is that saying that “a little knowledge can be a dangerous thing”.
My post however did not suggest we should “dismiss the desire to have any details”. Indeed it suggests quite the opposite. Clearly a life-critical system will require a greater degree of requirements rigour than a system for a simple website. I think that this is common sense and good agile practitioners will adapt for the situation that they find themselves in. Unfortunately the reputation of agile is sometimes tarnished by agile fanatics who take a dogmatic approach to agile principles and suggest that no requirements should ever be done. This is clearly not true.
Regarding agile being a fad, the Agile Manifesto was written over 10 years ago and many of us have being delivering projects successfully using agile techniques for longer than that. So I would suggest that it is not a fad.

Hermann Helmoholtz

Thanks for taking the time to reply to my note.

I think the Agile methodology which the Manifesto spoke about is hardly anything specific to represent a new Technology Scripture. Indeed, the fact that thousands of ‘Agile implementations’ exist today does suggest that Agile ‘is everything, hence it is nothing’ – exactly within the spirit of the vague and self-congratulatory Manifesto.

Take the fantastic idea that 15 people should sit down to elaborate the architecture of an application or a solution. The participants, according to most Agile Apostles, are TO BE presumed SMEs, even though some may be Associate Programmers, and others may have totally different computing interests.

Would a reasonable Project Manager, under whatever Agile name he or she is stuck with, support such an incredible time and resources expenditure, while certain that ultimately the said architecture would end up in the hands of one or two architects on the team, who would do what such a Conclave could not and cannot do?

Surely talents cannot be ignored, and should be spotted, fostered and reared. But hunting for talent in this bizarre way is akin to playing the lottery, this time with the enterprise’s money!

From the time we applied our home grown methodologies, to the time when we adopted RUP to the present time, with an adapted RUP, we ceaselessly evaluated the potentials of our main resource, the human resource, and worked to maximize its input, and expand its collective and individual intervention domains. We did that without holding Jamborees, which seems to be a hang-up in various Agile… shall we say ‘interpretations.’

A book I downloaded recently from the excellent IBM site sums up the confusion in two consecutive paragraphs on page 29:

“✓ Document continuously: Write documentation for your deliverables throughout the life cycle in parallel to the creation of the rest of the solution. Some teams choose to write the documentation one iteration behind to focus on capturing stable information.
✓ Document late: Write deliverable documentation as late as possible to avoid speculative ideas likely to change in favor of stable information.”

The book is “Agile for Dummies”

I am very keen to see some advantage in Agile. Certainly the Stand Up meeting seems reasonable for 5 or 6 – and that I endorse, but the more I dig into the Agile methodology literature, the more I encounter contradictions, platitudes, blind spots, irrelevance and above all, a queer insistence on ignoring the interests of the enterprise.

Andy Dent

Hermann, I don’t see the confusion between the two points on documentation that you just cited – we follow exactly that process.

Document continuously – documentation for features is written as they are written.

Document Late – we do NOT document features in anticipation of them being written, in case they are not delivered in the current version.


As managers, many of us need to develop or strengthen ourr abilities to
maintain a single-mindedness oof focus so we can more effectively achieve our business goals.
Your feet will probably swell, and tight shoes
will become uncomfortable. You can create different circles
community based on people’s interest and there relkation with you.


Leave a Reply

Your email address will not be published. Required fields are marked *