How to Successfully Migrate from RUP Methodology to Scrum

Rational Unified Process (RUP) has a chequered history. It is dotted by constant attempts to catch up with the innovation at any given point of time. RUP was originally very similar to waterfall, although you’ll hear the term ‘iterative’ used quite often.

Over time, the framework has meandered to include Pair programming, Test-driven development (TDD), Extreme programming (XP) and other such practices from the Agile framework, in an attempt to stay relevant. OpenUP, Agile Unified Process (AUP) and Disciplined Agile Delivery (DAD) reflect these attempts at moving closer to Agile.

Ultimately, the crux of RUP still remains at the heart of its modern successors; namely the IECT – Inception, Elaboration, Construction, Transition phases.

Down Memory Lane

Rational Unified Process is an iterative framework developed in the mid-to-late 1990s. Acquired by IBM, the framework establishes resources and artefacts for software development that can be adapted to suit your specific organisational needs.

Figure 1- RUP Process Architecture (credit: https://era.nih.gov/docs/rup_fundamentals.htm)

The six core principles of RUP are:

1. Iterative development
2. Requirements Traceability
3. Component-based architecture
4. Visual modelling
5. Continuous Testing
6. Change Control

RUP project usually follows a four-phase project life cycle:

• Inception—idea, vision and requirements are finalised here
• Elaboration —feasibility, component-level architecture, concrete plan and 80% of the use cases necessary are identified
• Construction—this is where the heavy-lifting actually occurs, i.e. development
• Transition—shippable product is release to production

RUP is a planning-heavy process framework, as witnessed by the preparation necessary before a team can begin development. Project objectives and requirements are defined upfront, thus defining a very clear direction for the team and their deliverables. Teams and organisations that heavily invested in RUP over the years, are now thinking about making the transition to a solid Agile framework. And with good reason.

Why consider moving from RUP Methodology to Scrum?

RUP lays emphasis on extensive Inception and Elaboration efforts that drive prioritisation decisions. And there is a place for such heavy upfront thinking. For example, when you embark on a highly transformational initiative that potentially impacts your entire organisation (“organisation” could be a vertical within your company, or your company as a whole), the investment in terms of time, resource and money is very high. With heavy investment, the risks of failure are greater. Any leader will try to determine the level of success that can be ‘guaranteed’ by taking such a big step.

In such cases, RUP-type methodologies will help you lay a rock solid foundation to your transformation efforts, and to minimise/mitigate risk of failure. RUP will give you the confidence to move forward with a transformation initiative.

On the other hand, if you are trying to get a small to medium project/programme with normally clear end-goals off the ground quickly, RUP will only slow you down. For instance, if you’re an online shopping website that only supports PC-shopping – i.e., internet browsers for desktop/laptop, then you’re not catering to the large mobile-primary population out there. And if you’re trying to catch up with competitors, your goals are clear: you want to build a mobile presence that brings you more traffic from mobile devices.

The solutions in this case are straightforward: responsive websites and mobile apps. You can’t afford to waste time on detailed Inception and Elaboration phases to de-risk. You want to identify the minimum viable product, and jump headlong into delivering the mobile experience at breakneck pace. You’re better off using Agile and Scrum rather than going for a full-blow RUP project that won’t allow you to begin development for some time yet.

So how do you go about recalibrating your software development practices away from RUP and towards Scrum?

#1 Start Slow and Start Small – or Go Big Bang

By nature, RUP works best when the entire organisation pulls towards it. And if yours is on RUP, then the practices will have permeated everywhere. RUP probably dictates how Annual Operating Plans are created, how budgets are allocated, how individual projects are initiated and delivered. In such a setup, you have two choices:

• Start small—introduce scrum in increments; or,
• Go big bang—transform your entire organisation

I’ve covered both incremental and complete transformation in a waterfall to agile context in the past. The RUP to scrum migration is no different. If you ask me, I’d say go for the Big Bang approach if you can afford it. It’s the most effective way to migrate to Scrum. But it’s not for everyone. The investment involved pretty heavy.

You need both the bandwidth and the willingness of key stakeholders to succeed. And you need the good old values of patience and perseverance—from all involved. Incremental transformation is the alternative if you need to take things slow. Whatever your reasons for gravitating towards this approach, there are some obvious challenges:

• You’re going to try a few projects on Scrum. So you need to protect the scrum initiatives from RUP processes pulling them into the planning abyss.
• You need to stop expecting set-in-stone plans with little give – which is hard, if the rest of your initiatives are on RUP.
• The resulting misalignment in process, planning and reporting between RUP and Scrum will create additional pain for key stakeholders that are across both.
• You’ll need to closely monitor the Scrum initiatives to ensure they don’t make wholesale compromises in the name of collaboration with RUP projects.

#2 Step-up using the Agile extensions of RUP

This is a feasible, if a roundabout, way to move towards Scrum. As I mentioned earlier, RUP continues to attempt to reinvent itself, now by moving gradually towards a more Agile framework. Agile Unified Process (AUP), and its more popular successor, Disciplined Agile Delivery (DAD), are both efforts in the right direction. Specifically, DAD has been touted as an effort at “going beyond scrum”. This framework attempts to address scalability issues commonly faced by Agile projects.

Figure 2 – Disciplined Agile Delivery framework

DAD makes RUP more agile by improving the iterative nature of the framework, while cutting down on the heavy inception and elaboration efforts. DAD isn’t a bad idea if you are looking to introduce as little change as necessary, and simultaneously infuse agile and scrum practices into your project delivery. As with any incremental transformation effort, the degree of success and improvement will also be incremental.

The upside is that your team do not have to grapple with wholesale change. Over a period of time, migrating scrum completely will become progressively less painful.

#3 – Don’t Coach RUP out; Coach Scrum in

Agile defines the need to deliver a working product at the end of every sprint. That means—in waterfall terms—going from requirements to design to development to delivery to working product, all within a span of a week or two weeks.

Figure 3 – Scrum Frameworkss

In RUP terms, this means many releases, each going through an IECT subset.

• Train the team to think I(E)CT for a (much) smaller time frame
• Recruit Agile coaches to support your team on a day-to-day basis
• Use the core RUP principles to iteratively review plan, requirements, and design

With this approach again, you need to know you’re in it for the long run. Expect results; just don’t expect miracles. When the scrum thinking begins to set in, results will pick up pace.

Bringing it all together

Your goals for migrating from RUP to scrum will help you determine the path and level of transformation necessary to get you there. You have the liberty to constantly re-draw your transition plan to accommodate extraneous factors. Remember that the most important change is mindset. If your thinking is still stuck in a traditional RUP world, you’re going to find it difficult to adapt to the fast-changing world of scrum.

Do you have experience in migrating from RUP methodology to scrum in your organisation? Do you have insights and best practices to share? Use the comments section below to share your experience, so others may benefit as well.