Many companies turn to the Rational Unified Process (RUP) to save them from disaster. Unfortunately, RUP has a dirty little secret that may mean salvation is further away then it may appear. Actually, it isn’t a very well kept secret, but it is something that many people seem unaware of. The fact is that RUP is not a complete process but something akin to a process framework. “Buying” the RUP is a little like buying building materials for a house: you have what you need to get started, but there is a lot more work to be done before you can move in.

So, what must be done and how does one go about doing it? Essentially, RUP provides the pieces (roles, artifacts and activities) that are a part of the process and each organization must put them together. Sound easy? Its not. As it turns out, not all of the pieces that you need are there, so you must find alternatives for the missing pieces. And it won’t be quite right the first time around. And it will take a Herculean effort to get buy-in from all of the necessary people.

To use another analogy, imagine going to the store to buy a Lego kit for constructing a castle. You know ahead of time vaguely what you want: a moat, a wall with a drawbridge and towers. When you get to the store, instead of having a nice prepackaged kit with all of the right pieces and instructions all they have in stock is a 5 gallon bucket containing most (but not all) of the different Lego bricks that are currently made. You have to sort through the bucket looking for the pieces that will fit together to form the castle you originally envisioned.

What about the missing pieces? The RUP tries to be all things to all organizations, but each organization is different and process is not a one-size-fits-all solution. It is inevitable that there will be some pieces that don’t fit right and others that are missing altogether. Organizations implementing the RUP will have to get creative or look to other processes to fill in some of the holes. Any creative product reflects the biases of its creator, and the RUP reflects a project management bias at the expense of other areas of software development. This is why many point to Extreme Programming or other agile processes as being complimentary to the RUP, but that is a different article.

If it sounds like I am picking on the RUP a little, that is because I am. I am using the RUP as an example since its one-size-fits-all nature and rigid rules make it more difficult to implement than many of the agile processes currently in fashion. However, the story isn’t really any different for any other prepackaged process. The point is that process in general, and the RUP in particular, is not a silver bullet. Implementing any process is hard work and in the end it won’t save a failing organization.

Process is not a replacement for good management. Going back to the house analogy, good management and a strong development team are the foundation for building a successful process. In the end, process is undeniably important to the success of a software development organization. If done correctly, a well defined process can improve developer efficiency, increase quality of the software and raise the stakeholders’ opinion of the development team. None of this comes for free, though, and you have to be prepared to work to make it happen.

Tags: agile, management, rup, teams