I often get the question: “RUP was your baby, but how do you look upon RUP today?” In an interview a couple of years ago I responded jokingly: “Yes, RUP is my baby, but you know babies grow up and some of them need correction.” RUP was created in Sweden under the name Objectory. This was in 1987.
Objectory was really new since its base could be used to describe all aspects of software development. Our focus was to identify all of the rules that we use when we develop good software: what are good use cases, good components, good test cases, etc. The literature in software engineering was totally empty in this space at the time. In order to do this we used object modeling to describe Objectory. Now we could let the base grow forever – technically speaking. Any company could make their own new process using Objectory.
Objectory became very successful. It survived the merge with Rational in 1995. The next version was named Rational Objectory Process, but after the success of UML, the name was changed to the Rational Unified Process or RUP as we all know it. In the work of merging the two companies, the process content grew significantly. However, hidden behind the size, our innovation of how to create a process base and the rules for goodness survived. The crown jewels of Objectory had survived!
Thus, RUP is one of my babies. The challenges with Objectory and consequently with RUP were serious.
Although our way of working in creating a process base was new and great, adoption became quite expensive. To truly be successful with the adoption and consistent usage was to involve customization, mentoring and consulting which most customers couldn’t afford. Thus the success rate was too low.
RUP was developed inside one company and all new ideas from the outside world had to be filtered by our own people and added to RUP. It goes without saying that ideas come from anywhere in the world and by having a process be company owned makes it difficult to assimilate these great ideas. The use of community much like what has been done with open source models would allow for continuous input and improvement. This also allows for scrutiny.
All processes are paper-ware and often managed by people who don’t use the process. This quickly becomes a problem in most organizations because the process becomes a religious document and not a realistic one. This then has the effect that what teams do and what the process tells them to do is often not in synch. And since the team is in charge (doing the work) the value of process becomes small.
These challenges paved the way for the agile movement. The different agile methodologists have one thing in common: they hate RUP. But that is NOT very smart. There are lots of good ideas in RUP. Many companies have made the effort in adopting RUP and done so quite successfully. This has provided them with a very competent staff and something to build on for the future.
However, “the baby needs correction”, and I and my company have done so. The adoption problem is attacked by focus on the essentials and being light instead of trying to be complete. We use cards and game boards to describe the process. Moreover, you don’t need to adopt a complete process all at once, just adopt a practice at the time. The growth problem is not a problem anymore, since we downplay big process and we make instead practices first class citizens. Practices can come from any source including the RUP and much of the practice work we have done is in support of RUP adoption. Practices can be composed to create your own way of working. Finally, the execution problem which is the hardest to achieve, is for the time being our little secret, but you are welcome to learn more about it by studying EssWork and EssUP.
Trust me, this is very smart.