Mistakes When Adopting the RUP

The objective of implementing the RUP approach is to help you deliver working software, with fewer defects, in as short a time as possible. Implementing the RUP can potentially have far-reaching implications to the adopting organization. Those implications are both technical (with new tools being adopted to automate certain aspects of the process) and social (with the introduction of new working practices and culture). The implementation should therefore be treated as a project or a program. These are some of the common mistakes we have found when organizations adopt the RUP:

• Adopting too much of what is in the RUP may slow down your development effort, reduce your flexibility, and increase development costs.

• Adopting everything at once, rather than incrementally, may overwhelm project members , likely leading to a failed RUP implementation.

• Not planning the implementation of the RUP may, among other things, lead to a lack of stakeholder buy-in, insufficient funds, or a lack of resources for mentoring and training.

• Not coupling process improvement with business results makes it harder to get stakeholder buy-in and may derail the RUP implementation so it does not provide expected returns.

• Customizing too much of the RUP too early leads to an overengineered process, or time spent on needless customization due to lack of understanding of what process is really needed.

• Playing lip service to the RUP makes stakeholders think that you have adopted the RUP, while you have done so only on the surface. You may lose your credibility, and the RUP may be blamed for failure, when it really is the process predating the RUP that is to blame.

• Not managing the RUP rollout as a project or a program, consisting of a series of projects, thus adopting the RUP but not measuring and assessing its success, making changes, or fine-tuning its usage over time (see Chapter 11).

Let's look at some ways to avoid these mistakes.

Adopting Too Much of What Is in the RUP

Possibly the most common mistake people make when adopting the RUP is to use too many of the artifacts or to do too many of the activities found in the RUP. Adopting too much of the RUP will slow down your development effort, and rather than providing you with increased flexibility, shorter delivery times, and reduced cost, it is likely to lead to the opposite and, ultimately, major failure. The RUP process framework is like a smorgasbord, and you're much better off not eating all the dishes if you want to stay healthy and happy. Adopt only the aspects of the RUP that add value to your project. See Chapter 11 for a discussion on adopting the RUP and Chapter 10 to understand how to streamline the RUP for your project.

The entire RUP knowledge base contains a lot of artifacts, and most projects should not try to use more than a fraction of them. What you should do is decide which of these artifacts makes sense for your organization and your particular project. For example, you may choose not to use any of the 8 artifacts for business modeling, to use only 4 of the 14 artifacts for identifying requirements (say, Vision, Actor, Use Case, and User -Interface Prototype), and so on. In total, you may find that 15 or 20 of the total RUP artifacts are the most useful for your organization. This may still sound like a lot, but remember that the RUP treats as artifacts many project elements that you may not normally think of as artifacts, such as Component, Build, Change Request, Design Class, and Subsystem. In the RUP, these are considered artifacts, even if you draw them on only a whiteboard ”or even a napkin. Note that the formality with which you document and review the artifacts is often more important than the number of artifacts you produce.

Using too many artifacts will slow you down. People may pay more attention to perfecting various artifacts than on building the right system. On the other hand, if you do not have enough artifacts, you may find that you repeatedly solve the same problems, increasing rework due to miscommunication . The same may be true if you document the artifacts in too informal a way. For example, you may have created a great implementation for storing persistent data, but if your solution is documented on a whiteboard, it cannot be used by team members at other sites. You need to formalize the documentation, perhaps using a visual modeling tool. So it is important not only to choose the right artifacts, but also to make them accessible to all project members. As discussed in Chapter 3, you need to choose the right balance between low and high ceremony for your project.

When faced with a decision on whether to include a particular artifact, ask the questions, "What would be the implication of not having this artifact present now or in the future?" and "What risk is this artifact mitigating?" Even though you want to use a minimum set of artifacts, the RUP uses artifacts for a reason. It is important that you consider the value of the artifact and its level of ceremony in this as well as future maintainence projects.

Adopting Everything at Once, Rather Than Incrementally

We highly recommend that you adopt the RUP incrementally. If you are not already using a very similar approach, trying to adopt a complete process all at once will prove overwhelming, potentially leading to decreased productivity and ultimately a rejection of the RUP. Hence, we recommend that you focus on adopting the parts of the RUP that give the highest return first.

Assume that you have set a goal of 18 months in which you would like to have guidelines for and consistency around producing the 15 or 20 artifacts that make the most sense for your organization. How do you get there? Let's look at an example.

Your team is working on three 6-month projects in these next 18 months. You choose which artifacts to produce for the first project, which ones you should add for the next project, and so on. Your plan might look as follows (italics indicate artifacts):

Project 1. Focus on Requirements Management and Iterative Development

Goal: To get a grip on requirements and start using an iterative and risk-driven approach. These areas are critical for the success of many projects.

To achieve the goal, the project introduces seven artifacts:

• Identify actors and use cases, and produce user-interface prototypes .

• Adopt an iterative and component-based process.

• Identify risks, and make sure to mitigate major risks in early iterations.

• Do not create a formal design, but produce well-defined components organized into implementation subsystems, and have these peer-reviewed.

• Do builds every week of the project.

Project 2. Focus on Configuration and Change Management, and Testing

Goal: To increase quality by addressing Configuration and Change Management as well as testing. Measure progress primarily by assessing what code works as expected, rather than what supporting artifacts have been completed.

To achieve the goal, the project introduces seven artifacts:

• Introduce a test plan and a test case, and produce test scripts to improve the testing process. These test artifacts should be derived from the requirements.

• File change requests (such as defects) when appropriate, and monitor these requests to assess how you are doing.

• Introduce Configuration Management tools supporting a project repository and developer and integration workspaces .

• Do builds every day during the last two months of the project, using an automated build process.

Project 3. Focus on Design and Architecture

Goal: To focus on design and component-based architectures in order to ensure that you actually implement the requirements and that the system is easy to maintain.

To achieve the goal, the project introduces four artifacts:

• Introduce design classes and design subsystems in order to build component-based architectures. Ensure that a baseline of the architecture is created by the end of Elaboration.

• Introduce use-case realizations ” that is, produce sequence or collaboration diagrams for each use case ”to ensure that your design incorporates your requirements.

• Enhance your requirement management process by producing a vision document.

Table 13.1. Incremental Improvements Across All Fundamental Principles. In each of the three projects, we made incremental improvements by using several of the fundamental principles representing "the Spirit of the RUP ." Each organization needs to determine what principles would provide the greatest gain and prioritize process improvements accordingly .

Principle	Project 1	Project 2	Project 3
Attack major risks early and continuously, or they will attack you.	Risks were introduced as a way of determining what to do in each iteration.
Ensure that you deliver value to your customer.	Requirements were documented.	Requirements were tested .	Requirements in the form of use cases have a design, a so-called use-case realization.
Stay focused on executable software.	Weekly builds and iterative development.	Daily builds toward the end of project. Strong focus on testing.
Accommodate change early in the project.	Started with iterative development.	Formalized a Change Management process.
Baseline an executable architecture early on.			Created a baseline of the architecture at the end of Elaboration.
Build your system with components.	Defined components in an informal way.		Formalized the development using components.
Work together as one team.	Iterative development forced closer team collaboration. Changed requirements practices enabled closer collaboration with customer.	Increased focus on face-to-face meetings to resolve issues quickly.
Make quality a way of life, not an afterthought.		Quality assurance established throughout the project.

Earlier we saw a concrete example of how you can make an incremental adoption. As you do an incremental adoption, you often need to modify the original plan because you may not make progress as expected or your priorities may change. But how do you decide where to start?

In Chapter 2, we discussed eight fundamental principles of the RUP. In Table 13.1, we outline how we made incremental improvements by using many of these principles in each of our three projects.

Assess your organization to see where you experience the biggest challenges and where your needs are the greatest, as we discussed in Chapter 11. Which of the eight principles in Chapter 2 should you adopt to get the biggest return? The organization in the earlier example adopted the principles in a certain order; the priorities may look very different in your organization.

Not Planning the Implementation of the RUP

Trying to implement the Rational Unified Process without proper planning is likely to lead to failure. Implementing the Rational Unified Process should be treated as a project or program by itself, supported by a business case and rooted in clear objectives such as reduced cost for software development, increased quality, and reduced project lengths. You need to figure out what is the best way for your organization to adopt the RUP, such as the incremental adoption we described earlier. This type of adoption does not "just happen"; it requires continuous planning and support to ensure successful project execution. You should also consider starting the adoption of the RUP in a pilot project, where you can use the RUP and supporting tools in a project set up to ensure successful adoption and to maximize the learning of the process and tools.

Soft issues, such as getting buy-in from executive management and middle management and making sure project members are motivated to change to a new process (and possibly a new tool environment), are crucial for the success of the RUP implementation. Many organizations are especially challenged with getting buy-in from middle management since they face not only the project risks, but also the risk of managing a project in a new way. There are also financial considerations, and you need to budget for mentoring, training, and potential tool purchases. You also need to ensure that you have the competency, or can acquire the competency, to do necessary customizations of the RUP, including developing project- or organization-specific guidelines for use-case modeling, design, programming, and so on.

Having a person, or a group , responsible for the RUP implementation greatly enhances the likelihood of successful implementation, at least if this person or group is given sufficient mandate to take necessary actions, has the necessary funds, and is measured on the success of the implementation. This person or group drives the implementation project forward, ensures cross-fertilization between groups to ensure that mistakes are not repeated, and alerts management when appropriate. The person or group must, however, be an active participant adding value in project work, not seen as a process police force that adds no value. It should be noted that you might greatly benefit from having an experienced mentor assist you in the implementation of the RUP, helping you avoid falling into common pitfalls. Revisit Chapter 11 if you experience problems with implementing the RUP.

Not Coupling Process Improvement with Business Results

Improving your process by adopting the Rational Unified Process takes a lot of effort and carries with it costs for training, mentoring, and tooling. It is important that you as an organization decide what business results you are trying to achieve, and that expected achievements are properly communicated to all stakeholders. Otherwise, the RUP implementation project is likely to derail, due to lack of stakeholder buy-in (among other things), and you may not see the expected returns.

By focusing on business results, it is easier to get buy-in from higher level management, as well as from project members. Without buy-in from all these groups, it is very difficult to succeed with a RUP implementation. It is therefore important that a solid business case is developed for the RUP adoption. This business case should define future achievements of the rollout of the RUP and should drive the measurement of the RUP implementation.

Customizing Too Much of the RUP Too Early

Just as we recommend that you use an iterative approach when developing software, we recommend that you use an iterative and incremental approach when customizing and adopting the RUP. Do not start with a six-month project in which you customize the RUP before you have tried it out on a few smaller projects. Before you have tried out the RUP in practice, you do not have enough information to truly say what benefits you will reap from changes to the RUP. Instead, make a minimum of customizations and configurations, try the RUP on a project, then customize and configure the RUP a little bit more to address missing key areas, and so on. For example, for your first project you may be satisfied with generating a RUP Configuration, producing a light development case (see Chapter 10), and making external references to process guidance you have elsewhere, before you take on the project of incorporating external process material into a RUP Plug-In.

Paying Lip Service to the RUP

The Rational Unified Process has become very popular, and many organizations find big business value in saying that they are using the RUP. The drawback of this is that some customers seem to be more interested in getting the stamp, "We are using the RUP," than in achieving real process improvements. They may adopt some of the artifacts of RUP and use some of the RUP terminology, but they do not adopt "the Spirit of the RUP" (see Chapter 2). This is likely to backfire on the adopting organization; as stakeholders realize that the adopting organization is not achieving expected benefits, they will lose confidence in the organization and its ability to effectively develop software.

Some of the symptoms of paying lip service include the following:

• You rename functions as use cases, allowing you to state incorrectly that you are doing use-case-driven development rather than producing use cases that are complete and provide one or several actors with a measurable value.

• You produce a risk list, but do not use it to impact the order in which you attack the many problems you always face in a project.

• You detail all requirements before you start with design rather than using an iterative approach with a balanced investment in requirements, analysis, design, implementation, and testing within each iteration.

• You plan a project in detail up-front, from start to finish, rather than producing detailed iteration plans just before you start each iteration.

• You use a waterfall approach, rather than iterative development, or have such long iterations that you lose almost all the benefits of iterative development.

• You measure progress primarily in terms of the number of produced use-case descriptions and a completed design document, rather than in terms of executable software and successfully completed test cases.

• You ignore architecture, including the testing of the architecture, until too late in the project, when architectural rework becomes extremely expensive and causes project delays and budget overruns.

Note that there is a big difference between paying lip service to the RUP and doing an incremental adoption of the RUP. When incrementally adopting the RUP, you should expect to experience some of these symptoms. But when incrementally adopting the RUP, you acknowledge that you have not addressed them, and either have a plan in place for when to address them, or decide that for your organization, you do not see that it is feasible or desirable to address the symptom(s).