When to use RUP and when to use Agile?

Question

What parameters should I use to determine whether a project will be more successful if conducted through a methodology Agile (Scrum, XP), or through the Unified Process (RUP, Praxis)? I can think of some features of the project that may benefit from one methodology or another (e.g.: whether partial deliveries are possible and desirable, the degree of complexity of the conceptual model and/or data, etc.), but I would like a more general framework.

I also wondered if it would be advisable to mix the two (ex.: Agile Unified Process - AUP), but to answer this I lack a better basis of the applicability of one and the other in specific scenarios (i.e. back to the original question, which criteria I must observe before adopting one or the other).

Context: in my view, RUP and Agile have more in common than, say, Waterfall and Scrum; Both are "iterative and adaptive" processes, focused on building large systems as if they were several smaller systems. The main difference, as I see it, is that in the OR there is an emphasis on elaborating a detailed design of the system as a distinct phase of the process, and although partial deliveries (called "releases") are in general not destined to enter production (are more to gather feedback). And unless I’m quite mistaken, this is not how agile works (partial results could be put into production or at least type approval).

For that reason, I’m racking my brain to determine in which situations one is more appropriate than the other. The issue of delivery is one of them, but as I have little experience mainly with Agile, I’m having difficulty seeing the other parameters in which they differ significantly - so evaluate for a particular project whether they fit these parameters or not.

Answer 1

I consider the question to be valid and relevant, but I have to admit that this goes a little into personal opinion.

Developer’s View

As I am primarily one developer, I have difficulties in seeing some advantage in a process framework such as RUP and other types of control such as ISO, COBIT, CMMI, MPS.BR and ITIL.

This is because the developer in general is much more concerned about delivering the software he has been assigned to do. In addition, experienced developers know how to do their job very well and manage themselves.

Team View

Within a large company, a development team has a small view of the whole. This means that she is only aware of the projects with which she is involved, but does not have global visibility of the company’s guidelines.

Agile methods are also more attractive to teams because they "empower" them in the sense that those involved can redefine the process as best suits them to deliver what is needed.

Manager’s view

Process frameworks are usually management initiative.

This is because managers in general cannot have a visibility of the projects from the technical point of view and need "abstract" planning and monitoring mechanisms.

Formalization and bureaucracy are the way to bring visibility on the project to those who are not effectively participating in it.

Processes and the hierarchy

If we imagine a hierarchy, with the president of the company at the top and the developers at the bottom, we can say that agile processes work from the bottom up (bottom-up), flowing from the team, while the "traditional" processes come from top to bottom (top-down), from the management side.

It is not uncommon for the company to formally adopt a process such as the RUP or CMMI while the team adopts a process Scrum-like with a manager interface between one world and another.

Customization of processes

An interesting point of view is that agile processes start with minimal bureaucracy and you can add whatever else is needed to the process. On the other hand, frameworks with the RUP bring an arsenal of papers, activities, artifacts and you need to remove the ones you will not use.

After all, after undergoing an adaptation process, the RUP can become virtually the same as the Scrum, with only a different starting point.

Partial deliveries

There are actually projects that require partial deliveries and others with a date set for "full delivery". But what literature and experience show is that the model Waterfall does not work well in virtually any kind of software project.

In the case of projects with "full delivery", what is generally recommended is to generate deliverables and define a "client" that will test the executable software. It could be a manager, a test team, product Owner or someone who has sufficient knowledge of the business rules.

However, in delivery to the end user, it is inevitable a shock proportional to the amount of functionalities delivered, because there will always be a gap between what was expert and what it really is necessary.

Anyway, if the customer wants to opt for a full delivery, he must be aware that the time required for adjustments will not be small.

And what is the difference between agile methods and the RUP in this sense? Virtually none. Observe the phases of the RUP:

The RUP is divided between several disciplines, among them test (test) and handover (Deployment).

Consider that the colored area of each discipline represents the level of activity of the same.

Since the Elaboration phase, the RUP already provides for testing and delivery activities. In fact the whole idea of this phase is to have an executable architecture to mitigate the biggest risks of the early project.

Returning to the contrast between RUP and Scrum, of course there can be differences in iteration size and quantity of deliveries. Considering also practices of XP, unit tests and automation of builds can bring great benefits. However, all of this ends more in technical and particular team issues than in the process itself.

With the exception of XP, which has several technical definitions, Scrum and RUP are too abstract from software development to impose a very large difference.

However, something that greatly influences planning, is that Scrum seeks to give the customer the possibility to define which features he wants first. The idea is to deliver to the customer what brings value to the business as soon as possible.

Of course this decreases the flexibility of the developer or manager when planning. It’s also something hard to achieve, which causes a little overhead in the development and requires a considerable capacity of those who model and develop.

Is a trade-off. Some lean to one side, while others go to the other. It is much easier to developer a system linearly than to start directly by core and, as some agile methodologies preach, refactoring the system until it starts to do all that is needed.

General considerations

Process frameworks such as the RUP have been designed as tools for managers. Agile methodologies focus on team self-organization. In companies, both end up being somehow necessary.

On the other hand, reports in general indicate that entrepreneurs, startups and even large high-tech companies have taken much more advantage in "de-bureaucratizing" the development process, of course, relying on experienced and highly qualified developers for this.

Something very important is to consider that control, as well as quality, has a built-in cost. Increased bureaucracy reduces productivity exponentially and often creates unnecessary obstacles. Although this may even be desirable in certain environments (Banks, Stock Exchange, Insurers), I do not believe it is recommended nascent companies, whose dynamics and flexibility are the differentials to be able to enter the market.

Completion

What everyone can (and should) do is try to understand the functioning and purpose of each process, as well as the good practices that each one seeks to disseminate. With this knowledge in hand, it is possible to adopt those that are most important to the project without the need to adopt a process label itself.

And something that everyone should keep in mind, is that no process does magic in quality or productivity. On the contrary, it can get in the way. One thing we all agree on today is that:

Individuals and interaction between them more than processes and tools