Rational Unified Process (RUP) started in the mid-1990s as a small manageable process framework targeted specifically for building software within the context of an iterative lifecycle.
A Very Brief History of RUP
RUP quickly became the dominant process in the late 1990s, but was eclipsed by agile ways of working (WoW) in the early 2000s. RUP was effectively retired by IBM Rational in the early 2010s. Yes, RUP properly applied in the right circumstances can be very effective. Unfortunately though, that often did not happen in practice.
Why RUP Lost the “Process Wars”
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 inappropriately 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 inappropriately instantiated in a heavy and onerous manner.
The loss of RUP is definitely a step backwards, as it did provide a spectrum of flexibility and formality, driven by project requirements and risk, and we now seem to have to choose between Agile and waterfall. Just as RUP was mistakenly instantiated as waterfall, we’re starting to see the same happen with Agile, where we have excessively long Discovery exercises producing requirements baselines, with sprints effectively being milestones in a waterfall plan. This challenge is particularly acute in UK Government, where ‘Service Assessments’ are required early in the delivery lifecycle, which require a comprehensive specification of solution functionality. Feels like we’re heading back into the methodological Dark Ages sometimes.
In Disciplined Agile, see https://www.pmi.org/disciplined-Agile, we adopted many of the great ideas from RUP that I suspect you believe are missing in agile. And to be fair, they are very clearly missing from Scrum.