Appendix A. Common Mistakes Utilizing RUP

Appendix A. Common Mistakes Utilizing RUP

I have received many comments from practitioners who read about the RUP and become excited at the prospect of implementing it on their own projects. Indeed, it seems like applied common sense. Yet situations seem to occur that derail many people attempting RUP, especially for the first time.

Applying the RUP is not always intuitively obviouscertainly it's less so than traditional Waterfall processes. Most of the difficulties organizations experience with implementing the RUP center on the correct use of iterative development. Many organizations struggle with this. By examining some of the mistakes organizations make when applying the RUP, you can take steps to avoid them. Although it is not possible to cover every conceivable way things can go wrong, this appendix explores the more common ones. The scenarios covered in this appendix are situations I have encountered working as a consultant.

Mistake 1: Iterations of Inappropriate Length

The appropriate time length of iterations depends largely on the size of the team involved. A small team of 3 to 4 people might have iterations two to three weeks long. An appropriate length for a medium-size team of 5 to 20 people would be anywhere from three weeks up to six or seven weeks. Teams much larger than 20 may have iterations several months long. These are only rough guidelines. In general, shorter iterations are better. But the larger the project and the more contractors and the amount of ceremony involved, the iteration lengths need to be longer.

I have seen projects with relatively small teams define iterations several months long. This is a mistake. The advantages of iterative development cannot be realized in these situations; these projects tend to resemble and experience the disadvantages of Waterfall projects.

The key is to define iterations that are long enough to get something meaningful completed given the group's size, but short enough to maintain a sense of urgency. Another reason for keeping iterations short is the importance of exercising all the activities involved in the project. In other words, integration, testing, demonstrations, incorporating feedback, and replanning, among others, should be performed frequently. This allows risks to be identified and addressed and needed course corrections identified and implemented quickly. Also, iterations should be of equal length. This allows teams to fall into a natural rhythm.

Mistake 2: Iterations with No Clear Goal

I have seen several instances where project managers simply take the total amount of time available for development and schedule the work across the entire period of time. They divide the schedule into equal segments of time and name them Iteration 1, Iteration 2, Iteration 3, and so on. This completely misses the point of iterative development. The content of the iterations should be determined partly by the phase of the RUP lifecycle (Inception, Elaboration, Construction, and Transition) and by the highest risks appropriate for the current lifecycle phase. For example, consider the following:

  • Inception phase: The iterations in the Inception phase should cover the following:

    • Is this project possible? Is it technically feasible? What business need motivates this project's execution?

    • Do we understand conceptually what the stakeholders want? Have we identified all the stakeholders?

    • Identify candidate architectures to accomplish the system's goals.

    • Identify requirements that are of particularly high risk.

  • Elaboration phase: Iterations in the Elaboration phase should focus on the following:

    • Which of the identified architectures is the best choice for the system?

    • Elicit and define the system's requirements.

    • Implement functional requirements that fully exercise the chosen architecture. This requires a small portion (about 20%) of the system's functional requirements to be implemented.

    • Implement any units of code that must be in place before the bulk of development is performed (such as common code and libraries).

    • Implement any other requirements that are particularly high-risk.

    • Demonstrate releases to stakeholders, and elicit and incorporate feedback received into the subsequent iterations.

  • Construction phase: By the time you reach the Construction phase, you should have eliminated or mitigated all the high-risk items on the project risk list. By this point, the developers are mostly "heads down," developing and creating periodic releases at the end of each iteration. Here are some suggestions for determining the content of iterations at this point:

    • First, focus on scheduling requirements for iterations that developers are not completely certain how to implement. In other words, schedule the most-difficult-to-implement requirements in the earlier iterations.

    • Also in the earlier Construction iterations, schedule requirements in which stake-holders seem to have particular interest. These are the features that the stakeholders will want to see first. They are also the most likely features to elicit change requests from stakeholders, because the implementation of these will be scrutinized the most.

    • Continue with demonstrations to stakeholders, and elicit and incorporate feedback.

  • Transition phase: By this point, the product is functional. The focus in the Transition phase should be on any adjustments required for the product to function well in its production environment. The system must be installed in its operational environment so that the users can exercise the system to ensure that it is fit for production. Defect reports may be received at this point. These should be prioritized and corrected in the Transition phase before the project is concluded.