RUP and Agility by Ivar Jacobson

July 23, 2004

Another Rational User Conference has just been concluded. Since 1997 I have attended every one of them, now eight conferences. There were many good talks, but I had no time to attend more than the opening keynote by Mike Devlin. Instead my days were filled by meeting people. Many had heard about my recent adventures in Singapore and Korea and wanted to understand where I am heading. Basically, I see a huge need to help people around the world to apply best practices of software development. Even if we have developed the RUP, we have not been successful in getting people to adopt it and apply it. One of the consequences of this “failure” is that agile methods like XP have become popular. I want to change that, and since RUP not yet has penetrated East Asia, this is a good place to start.

My keynote this year was titled “What you didn’t know about RUP”. So this talk was about the secrets of RUP. Actually a lot of people, including RUP evangelists, don’t know about these secrets. One of the secrets is that RUP or the Unified Process in general, is agile and is in fact becoming increasingly agile as time goes by. I feel that we have not succeeded in explaining why it is so. I took it as my mission to do so.

First I developed some vocabulary to explain why RUP already is agile. When people talk about a process being light or heavy, they actually mean that the process definition (the “book”) is light or heavy. They don’t talk about the process in the meaning of what actually is done and created when you run a project. So we actually have two concepts to discuss, the process definition (PD) and the executing process (P). What we really care about is that the P is agile and not really that the PD is agile.

Thus we can have a light PD (a book) but since it doesn’t explain much it is not of much support to the team that runs a project. They will have to invent the particulars of the process as they go. This may slow down the project substantially, something I have experienced in many projects. Thus a light PD frequently result in a heavy P.

Also, although a rich PD may require that people spend time upfront to learn what to do; it may result in that the P works very smoothly. Everyone in the team knows what to do, when to do it and how to do it. Thus a rich PD frequently results in an agile P. I have seen this happen many times in serious commercial software development.

So far most people agree with me. So let us now talk about the executing P and how to make it agile. Today, to get a PD like RUP to be used in a project, it takes three things:

  1. A subset of the PD has to be chosen and maybe some additional process steps will be added. There are good tools to do so, but still this slows down the project. To be able to select what to use you need to know all that can be used. Most companies don’t have the luxury of time and competence to do that. Makes the P heavy!
  2. Once a proper PD has been created, it has to be adopted. This means that people have to learn it, they need to get it into their heads. This requires training which takes time. Makes the P heavy.
  3. Finally, while running a project, the PD must be applied consistently and effectively. This means that people need to know what to do, when and how. Usually, people can’t do this by themselves, it is a far too big step to go directly from the classroom to your office and do useful things in a productive manner. Thus projects need mentors. Makes the P heavy.

Why would people take on all this work (to define and learn a PD) to develop software? There is only one good reason. We know that people will develop better software, better software from all perspectives.

What have we done to make RUP implementations overcome these difficulties?

  1. Now and even more in the years to come, I believe we will see a number of predefined variants of RUP become available. We will have ready-made light PDs, and we will have heavy PDs for product-line developments. This makes RUP more agile. You start using the PD that works for you.
  2. With RUP comes a lot of training material. RUP comes with a set of very systematic models, enforcing traceability and consistency between them. This makes it very systematic compared to the light methods, and consequently we can train developers in a systematic way to understand good software development practices. We can train people to become competent. Still, yet training needs to be done in a more agile way.
  3. Good software and software developed in an agile way can only be created by smart people. You can only be smart if you are competent. Since RUP helps you to become competent, you also have the preconditions to become smart which helps you to become more agile in applying best practices.

However, we won’t stop here. Already when I started the development of what became RUP back in 1987, I knew we need to take one step more. We need to make the process active and executable, not just a dead book. We need to support the developer with “intelligent” tools. This is why we started Jaczone and developed WayPointer. WayPointer will help us make a big step forward in agility:

  1. One day I believe WayPointer will help configure the PD while you are working. WayPointer will recognize what the team is doing and present a PD that is just enough of process. For a small project it will be a light version of RUP. For a larger project a richer version of RUP will be provided. This will happen as you go, without having a heavy upfront configuration activity. Isn’t this agile?
  2. With WayPointer, training doesn’t happen in classrooms but while you work. Thus no heavy training before starting, instead “train as you work”. Very agile, right?
  3. Finally, WayPointer will help you to also apply the PD. It is very context sensitive, so it can give proposals of what to do in every micro step as you work. It can facilitate the doing of many activities which today have to be done manually, but which should follow one another in a natural way. It speeds up the whole project in a substantial way. This is what I would call agile, and it far exceeds what you can do with what is called agile methods.

To summarize, agility can only be delivered by people, people that are smart. People can only be smart if they have knowledge. Knowledge needs to be shared between the members of the team; otherwise it will slow down the team. Most of the knowledge they need are rules about best practices and implementation technologies. Most of these rules can be captured in a “tool” like RUP, but to achieve substantial agility, these rules should be manifest in another more intelligent tool, making the process active. In that way there is no limit to how agile we will be developing software in the years to come.