Pragmatic Advice for Succeeding with RUP
The Rational Unified Process (RUP) is effectively defunct. In 2008 IBM dropped support of RUP as a
product in favor of a plugin for its process repository product called
IBM Rational Method Composer (RMC).
More importantly, for very good reasons, organizations around the world have either abandoned RUP
or are in the process of doing so.
RUP started in the mid-1990s 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 Rational) added additional guidance and artifacts to extend the
applicability of RUP to all sorts of situations, such as package implementation,
maintenance projects, technology specific guidance (J2EE, .Net etc.), systems engineering
and may other project types. In practice RUP suffered from several problems:
- RUP became unwieldy and hard to understand and apply successfully due to the large amount of disparate content.
- RUP was often misappropriately instantiated as a waterfall (with Inception as a big requirements up front (BRUF) phase, Elaboration as a detailed architecture phase, and Transition as a testing phase.
- RUP was often misappropriately instantiated in a heavy and onerous manner.
Yes, RUP properly applied in the right circumstances can be very effective.
Unfortunately though, that often did not happen in practice.
It's Time to Move On
Many organizations that adopted RUP in the past have decided to, or are currently thinking about,
adopting a more agile way of working. Unfortunately they are finding agile methods such as Scrum and XP
to be inadequate as they do not address the full range of complexities faced by RUP shops. Yes, it is
definitely possible to start with something like Scrum and evolve it to meet your needs, but you will quickly
find that this is a time-consuming, expensive, and error-prone strategy.
Luckily there is a better answer:
The Disciplined Agile (DA) framework.
The DA process decision framework is a people-first, learning-oriented hybrid agile approach to
IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware,
and is scalable.
There are clearly some interesting aspects to the DA framework:
- DA is a hybrid approach which adopts proven strategies from Scrum, Agile Modeling (AM),
Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development,
Scaled Agile Framework (SAFe) and several other methods.
- DA is a non-proprietary, freely available framework.
- DA 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.
- DA also supports lean and continuous delivery versions of the
lifecycle: unlike other agile methods, DA doesn’t prescribe a single lifecycle because it
recognizes that one process size does not fit all.
- DA includes advice about the technical practices
such as those from Extreme Programming (XP) as well as the modeling, documentation, and
governance strategies missing from both Scrum and XP.
- DA is pragmatic. Instead of the prescriptive approach
seen in other agile methods, including Scrum, the DA framework takes a goals-driven approach.
In doing so DA provides contextual advice regarding viable alternatives and their trade-offs,
enabling you to tailor DA to effectively address the situation in which you find yourself.
By describing what works, what doesn’t work, and more importantly why, DA helps you to increase
your chance of adopting strategies that will work for you.
Some Interesting Reading