Practice 19. Rightsize Your Process

A focus on executable software means that artifacts other than the actual software are supporting artifacts. They are there to allow you to produce better software. By staying focused on executable software, you are better prepared to assess whether producing other artifactssuch as requirement management plans, configuration management plans, use cases, test plans, and so onwill really lead to software that works better and is easier to maintain. In many cases the answer is yes, but not always.

You need to weigh the cost of producing and maintaining an artifact against the benefit of producing it. The benefit of producing many artifacts typically increases as your project grows larger; you have more complicated stakeholder relations, your team becomes distributed, the cost of quality issues increases , and the software becomes more critical to the business. All these factors are an incentive to produce more artifacts and treat them more formally . But for every project you should strive to minimize the number of artifacts produced, to reduce overhead, and to focus on executable software.

Produce Only Artifacts That Add Value

In most projects you will ask yourself, "Should we produce this artifact or not?" On the one hand, "cowboy projects" pay no attention to process and, as can be expected, leverage too few artifacts. On the other hand, some projects pay too much attention to process and tend to use too many artifacts rather than too few. As an example, one of the most common mistakes RUP users make is to produce artifacts just because RUP describes how to produce them. RUP is a rich, customizable knowledge base, with, among others, artifacts suitable for large-scale, safety-critical systems. But that doesn't mean that those artifacts should be used. Small, nonsafety-critical projects simply should not use artifacts not aimed at them. To reduce the number of artifacts you produce, cut down on the number of types of artifacts you have in your process. Also, do not assume that just because your process describes an artifact of a certain type, such as a use-case realization, you need to produce a use-case realization for every use case. It may be sufficient to produce use-case realizations only for the use cases for which you have complex collaborations.

You should also look for opportunities to reduce the amount of artifacts, and the level of details used when producing an artifact, by changing the way team members collaborate. In the past you may, for example, have produced very comprehensive requirements specifications to ensure that developers understood what they should implement. By improving the collaboration between analysts and developers, you may be able to reduce the time spent on formal documentation of requirements. When requirements are unclear, developers ask for clarifications, and by having developers show prototypes as they evolve , analysts can clarify the requirements as needed. The closer collaboration may not only reduce the documentation cost but also improve the quality of both the requirements and the code.

If you are in doubt as to whether or not to produce an artifact, don't. ^[2] But do not use this guideline as an excuse to skip essential activities such as setting a vision, clarifying a business case, documenting requirements, developing a design, and planning the testing effort. Each of these activities produces artifacts of obvious value. If the cost of producing an artifact is going to be higher than the value of having it, however, you should skip it.

^[2] Ambler 2004 refers to this as "Model with a Purpose."

It is worth noting that some artifacts are not there to assist the project team per se, but to assist the organization to achieve certain objectives, such as ISO-9001 certification, enterprise reuse, financial reporting, management oversight, tracking of metrics to improve predictability of future projects, and so on. For such artifacts, it is essential for the project team to involve appropriate stakeholders in decisions regarding whether or not the artifacts should be produced.

If you choose to produce an artifact, you also need to determine the right strategy for maintaining the artifact. Some artifacts may be treated as throwaways, others may always need to be kept current, and some may be updated only when it hurts. ^[3]

^[3] The latter is a practice from agile modeling; see Ambler 2004.

Understand Where Your Project Should Be on the Process Map

To guide you in how much process to use, and what type, it helps to think of where your projects should be on the process map described in Chapter 1 and shown in Figure 7.2. By figuring out where the "sweet spot" for your project is on the process map, you can better understand how to customize or augment the process you are using now. Should you go for more or less discipline? Table 7.1 lists some of the factors that determine how much discipline is appropriate for your project. If your project requires more discipline, use the practice adoption levels cited in this book to determine what steps you need to take to move your project to the right on the process map. For information on what factors drive iteration length, and hence where you should be on the y axis of the process map, see Table 2.3 in Practice 2: Execute Your Project in Iterations .

Table 7.1. Factors Impacting the Appropriate Amount of Discipline.

As listed in Table 7.1, one of the factors that determines the appropriate amount of discipline is where you are in the project, or whether you are in early or late lifecycle phases. This factor is often poorly understood. Early in the project you are working with a great many unknowns, so you want to follow a process that enables you to change and augment your solution rapidly , without being bogged down by a lot of rigor and discipline. Late in the project, you want to stabilize your code and make only changes that are well motivated. You thus need to introduce more rigor toward later lifecycle phases (see Practice 3: Embrace and Manage Change ). A common anti-pattern is to have high degrees of ceremony throughout the project, but more process has never helped foster the creativity you often need in early phases to build the right solution.

Scaling Your Process with the Eclipse Process Framework and Rational Method Composer

A capability pattern is a recurring process pattern that accomplishes a well-defined objective. Capability patterns are a key construct in the architecture of the Eclipse Process Framework (EPF) and Rational Method Composer (RMC) (see Appendices A and B), allowing you to scale your process incrementally from very light to very disciplined.

Let's look at an example. In EPF, OpenUP/Basic contains a capability pattern that provides a lightweight and agile approach to defining, designing, implementing, and testing a scenario. A larger project may need a capability pattern providing a little more discipline, if, for example, the design is more formally documented. In this case the project team can choose a different capability pattern that better addresses the desire for discipline. A third project that builds safety-critical systems may need yet more discipline and may use even more rigorous capability patterns, available in RUP within the RMC product, for defining, designing, implementing, and testing a scenario. All three capability patterns are different, but they achieve the same objective: to define, design, implement, and test a scenario. So capability patterns provide a simple mechanism for scaling your process by exchanging one set of capability patterns for another, matching set, thus providing a more or less disciplined process. Our expectation is that the concept of capability patterns, combined with the creativity of the open source community, will over time provide us with access to a broad set of exchangeable capability patterns suitable for different styles of development.

Automate Mundane Tasks

Each product has a series of mundane or administrative tasks that need to be performed. To the extent possible, such tasks should be automated. Rather than having each team member report weekly status, can we automate status reporting by having a reporting tool extract relevant information from repositories and tools? Can we automate the production, and at least basic testing, of builds?

Continuously Improve Your Process Through Assessments

Rightsizing the process is a continuous activity throughout the project. Daily scrum meetings are a great opportunity to bring up issues preventing progress, and some of them may require a process change. Iteration assessments and retrospectives ^[4] at the end of iterations provide you with an opportunity not only to assess what you accomplished in the iteration but also to improve your way of working. Each project should also end with an overall project assessment, allowing you to understand what improvements can be done for future projects (see Practice 20: Continuously Reevaluate What You Do ).

^[4] Kerth 2001

Other Methods

All agile methods focus on the need to streamline process by avoiding unnecessary bureaucracy.

XP goes to the extreme, minimizing documentation and modeling, and capturing secondary artifacts by relying primarily on verbal communication. When items are written down, they are typically noted on index cards or whiteboards . Some guidance is given on how to scale the process for the needs of larger or distributed teamsthe use of Wikis, for example, or ideas from Scrum, such as the use of "scrums of scrums" as a communication vehicle allowing daily management meetings to occur across larger organizations. Even though XP has reportedly also been used successfully for larger projects, and XP has been extended to scale it up, ^[5] the target audience for XP is still primarily teams that want to be in very lower left corner on the process map (see Figure 7.3).

^[5] See, for example, Industrial XP, www.industrialXP.org.

In his book Agile Software Development , ^[6] Alistair Cockburn captured a map similar to the process map in Figure 7.2. The x axis represents project size, and the y axis is the potential damage a system could produce, with a safety-critical system being on the high end. Cockburn has also built a series of processes that scale from less disciplined to more disciplined: Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red, and so on. He leverages his map to guide people when to use which process.

^[6] Cockburn 2002.

Scrum has already been used in smaller as well as larger projects and organizations. One of the scalable techniques is to use "scrum of scrums," meetings in which representatives from each team involved in the larger effort meet daily or as often as needed to sort out cross-team issues. New teams are also introduced to dealing with cross-project issues such as reuse, testing, and production support.

Agile Modeling articulates a number of different principles with the objective of streamlining process, including the principles of Traveling Light and Model with a Purpose. The former guides us in carefully choosing which artifacts to maintain, since some artifacts may be too costly to maintain and may have fulfilled their purpose once created. The latter guides us in being clear on what the objective is in creating a model or parts of a model, and modeling as little as possible while still addressing the objective.

OpenUP/Basic is focused on iterative and agile development for small teams. It focuses on the most essential tasks and artifacts, to make the process easy to learn and adopt. It provides guidance on when to capture artifacts more formally in tools or documents and when a whiteboard may suffice. It also borrows from many concepts found in Scrum, such as Product Backlog, Sprint Backlog, and Daily Scrum, even though the terminology is different.

RUP differs from the other processes mentioned above by being a customizable framework that contains several out-of-the-box processes, rather than a single process. RUP also scales OpenUP/Basic to cover enterprise needs, by allowing you to add guidelines for larger or distributed teams around technologies such as J2EE and .NET, or for products such as the IBM software development platform. It also provides guidance on various project types, such as packaged application development, legacy evolution, custom application development, systems engineering, business engineering, portfolio management, program management, or service-oriented architecture.

Levels of Adoption

This practice can be adopted at three levels:

• Basic. The project team determines which artifacts and process steps to use as they progress through the project. The decisions are not formally documented.

  The basic practice of deciding as you go minimizes the amount of discipline and brings you down and to the left on the process map.

• Intermediate. The project team documents which artifacts and process it will use, allowing clear communication regarding what process is to be used. As an example, training material can now be customized to train the team on (only) the relevant aspects of the process being used.

  The intermediate practice of documenting the process facilitates reuse across projects and capturing lessons learned, and it should provide team members with a clearer understanding of how to do the work. Capturing these lessons learned should allow you to streamline the work and thus shorten the iteration length. It will, however, force you to spend some time documenting and continuously updating the process.

• Advanced. The project team assesses what worked and did not work for each iteration and project and leverages this assessment to fine-tune the process.

  The advanced practice of continuously improving the process is crucial to a team's optimal performance and should allow you to move down and to the left on the process map. The key is to timebox this activity and to communicate the process in the most effective way. Lengthy process descriptions are not always the optimal communication vehicle, especially for small audiences.

Related Practices

• Practice 4: Measure Progress Objectively describes how to avoid getting a false perception of status by focusing more on primary than secondary artifacts. That same focus is essential as you rightsize your process.

• Practice 12: Build High-Performance Teams discusses the characteristics of a high-performance team and how to build a culture that breeds them. Having the right amount of process for your needs is essential for a high-performance environment.

• Practice 20: Continuously Reevaluate What You Do provides guidelines for how you can improve your process by always challenging what you do.

Additional Information

Information in the Unified Process

OpenUP/Basic is base process meant either to be used as is or extended with additional guidance in required domains. Its focus is on simplicity, with minimum documentation. RUP extends OpenUP/Basic by providing many specialized out-of-the-box processes, covering a variety of project types. RUP focuses on more specialized content, as well as content appropriate for larger projects. RUP also discusses topics such as how to customize a process and effectively implement it in an organization.

Additional Reading

For information on process configuration, see the following:

Peter M. Senge. The Fifth Discipline . Doubleday, 1990.

Alistair Cockburn. Agile Software Development . Addison-Wesley, 2002.

Barry Boehm and Richard Turner. Balancing Agility and Discipline . Addison-Wesley, 2003.

Robert McFeeley. IDEAL: A User 's Guide for Software Process Improvement . Software Engineering Institute, 1996.

For information on how to customize RUP, see the following:

Stefan Bergstrm and Lotta Rberg. Adopting the Rational Unified Process: Success with RUP . Addison-Wesley, 2004.

Per Kroll and Philippe Kruchten. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP . Addison-Wesley, 2003.