Practice 19. Rightsize Your Process


Per Kroll

Choosing the right amount of process allows your project to maximize productivity while gaining agility.

Problem

Projects with no process typically do not work effectively, since they are forced to reinvent proven approaches to attack common problems and also tend to run into more collaboration issues due to unclear division of responsibilities. Projects with too much process may suffer from lack of creativity and productivity due to enforcement of artifacts and activities that add limited or no value to the challenges at hand. This practice provides guidelines on how to choose the right amount of process based on your needs.

Background

We have come a long way in the United States since the days of the Wild West, when an alleged criminal got a quick, though not always fair, trial. But given the large number of crimes, the rapid population growth, and the lack of trained professionals, most people in Wild West society were probably happy with the process and saw little reason to change it. Speed and simplicity were more important than quality.

However, we believe that today most people prefer the more rigorous trial process currently used in the United States. It may not be perfect, but it provides much stricter guidelines for the police, prosecutor, and defense lawyers regarding what is and is not acceptable behavior. In the end, hopefully, it leads to fewer unfair trials, which most people in today's society find more reprehensible than delayed trials. From this example we see that the amount of process needs to be adapted to fit the needs of the various stakeholders. What is right for one situation may not be right for another.

My wife and I are currently building a new balcony, and to do so we need a construction permit. One of our neighbors is probably very happy that one of the prerequisites for this permit is permission from all our neighbors, because that enabled him to insist that we plant some trees to provide him with a reasonable amount of privacy. However, the process of obtaining a permit involved many other steps that I did not care too much for. We needed to prove that the other houses in the neighborhood have a similar look and feel, we needed to provide three revisions of the plans, we needed to get approval from several different departments, we had to meet with some departments many times, we had to have several inspections, and so on. Overall, the permit process probably increased our cost by 50 percent and more than doubled the duration of this pretty simple project, as well as forcing us to reduce the size of the balcony to avoid an even more rigorous permit process. All in all, even though certain steps were very valuable, I found the permit process overly cumbersome and unhelpful. If you do not continuously take active steps to simplify a process, it often ends up being overly bureaucratic and inefficient.

Philippe Kruchten expressed it well[1]: "The purpose of a software engineering process is not to make developers' lives miserable, or to squash creativity under massive amounts of paperwork. Its only real purpose is to ensure that a software development organization can predictably engineer and deliver high-quality software that meets all of the needs and requirements of its userson schedule and within budget."

[1] Kroll 2003.

But how do you choose the right amount of process for your project to ensure productivity, predictability, and quality without losing too much in creativity and flexibility? The answer will vary based on your situation. Let's have a look at some guidelines that will help you to "rightsize" your process.

Applying the Practice

A project will be more effective if you rightsize your process, that is, focus on executable software rather than supporting artifacts and produce only artifacts that add value. You need to choose both the right level of ceremony for your project and the extent to which you should do iterative developmentwhat we refer to as understanding where you should be on the process map (see Figure 7.2), and you need to scale your process accordingly. You need to automate mundane tasks and continuously improve your process through assessment and refinement. Let's have a look at each of these activities.

Figure 7.2. Process Map for Process Comparison.

By organizing processes and process assessment frameworks along two dimensionsLow Ceremony/High Ceremony and Waterfall/Iterativeyou can compare them and analyze which are the most suitable for your project or organization.

(Adapted from Kroll 2003.)


Focus on Executable Software, Not Supporting Artifacts

A clear focus on executable software promotes the right thinking among your team; you run less risk of overanalyzing and theorizing and can instead get down to work to prove whether solution A or B is better. Forcing closure by producing executable software is often the fastest way of mitigating risk.

Artifacts other than the actual software are supporting artifacts.


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.

Producing executable software is often the fastest way of mitigating risk.


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.

Reduce the amount of artifacts by changing the way team members collaborate.


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.

Some artifacts are not there to assist the project team, but to assist the organization.


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.

Examples of factors driving the need for more discipline within a project include large project size, distributed development, regulatory and contractual requirements, complex stakeholder relations, long application life span, late lifecycle phases, or complex projects.

Factors Driving Less Discipline

Factors Driving More Discipline

Small team

Large team

Collocated team

Distributed team

Few stakeholders

Many stakeholders

No regulatory requirements

Regulatory requirements (Sarbanes-Oxley, Food and Drug Administration, etc.)

No contractual relationships

Contractual relationships

Short projects

Long projects

Early lifecycle phases

Late lifecycle phases

Simple projects

Complex projects


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.

One factor that determines the appropriate amount of discipline is where you are in the project.


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.

Capability patterns provide a simple mechanism for scaling your process.


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

Retrospectives provide you with an opportunity to improve your way of working.


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.

Figure 7.3. Process Map for XP, Scrum, OpenUP/Basic, and RUP.

XP targets projects with iterations of one to two weeks, OpenUP/Basic two to four weeks, and Scrum four weeks; RUP provides the broadest range based on how it is customized or what configuration of RUP you use. In a similar fashion, each process provides a different amount of ceremony, with XP being the process with the strongest focus on lightweight documentation.


XP minimizes documentation by relying primarily on verbal communication.


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.

RUP is a customizable framework containing several out-of-the-box processes.


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 Bergström and Lotta Råberg. 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.



Agility and Discipline Made Easy(c) Practices from OpenUP and RUP
Agility and Discipline Made Easy: Practices from OpenUP and RUP
ISBN: 0321321308
EAN: 2147483647
Year: 2006
Pages: 98

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net