News

Is RUP right for small teams?

• By Dan Romanchik
• February 24, 2004

Many programmers feel that the Rational Unified Process (RUP) is too rigid and structured for small development projects. Proponents of agile and extreme programming have similar concerns. To answer these criticisms, I spoke recently with Gary Pollice and Liz Augustine, two authors of the recently released book "Software Development for Small Teams: A RUP-Centric Approach." Here's what they had to say.

Q. What are some of the criticisms that those in the extreme and agile programming communities have of the Rational Unified Process? Are these criticisms well founded?

A. One concern is that RUP is too big and too prescriptive, but we disagree. In actuality, you always need to configure RUP to fit your project's needs. Recent changes to RUP have made it easier to navigate and configure.

Another common misperception is that RUP only applies to large projects. One reason we wrote the book is to show that RUP can be used effectively on small projects. RUP shares many of its principles with other methodologies, including agile methods. The values of feedback, customer relationship and delivering valuable software are fundamental to RUP. Per Kroll stated these principles in his article on the spirit of RUP in "The Rational Edge" (http://www.therationaledge.com/content/dec_01/f_spiritOfTheRUP_pk.html).

Most software today is developed by teams of fewer than 10 people, even if they are part of a larger team. We think an important benefit of RUP is that it provides a single language and consistency to projects throughout an organization.

Q. What are some of the mistakes that small development teams make when deciding on a process for their development project?

A. To ignore the human aspect of the team -- each person's needs, different styles of human interactions and different approaches to work. Give thought and time to forming your team. People are even more important than process in determining the success of your project. In our book, we encourage teams to work toward the goal of producing software and to resist getting caught up in the process.

We think that many teams produce too much unneeded documentation or artifacts as they build their software product. In RUP, you should create artifacts only if they are useful to you in future stages of the project. Further, RUP encourages you to work at the level of formality that is appropriate to your project. For example, you can base written documents on RUP templates, but you can also write your documents on Post-It notes or even come to an oral agreement.

Q. Besides buying your book, what's the one piece of advice you would give leaders of small development projects that would help them to improve their development process?

A. Worry first about the people on your project. Then develop a process that's right for your team and situation. Perform the bare minimum of tasks needed for your project; don't do something just because it's "in the process" or because you did it on the last project, unless it's truly useful. In other words, don't let the process become your goal.

Design your process to help you get to your real goal -- building a piece of software that satisfies your customer's needs.