Process

In some respects, this whole book is about process. In this section we present the process-oriented project guidelines that do not require much contextual information. Those that do require more context in their description are presented in subsequent chapters.

The Prime Directive

Let's start with our fundamental guideline about process, also known as the prime directive of process. This guideline is shown in Project Guideline 7.

Project Guideline 7 The prime directive of process

Only do those activities and produce those artifacts that directly lead to delivering value to your customers and stakeholders.

The real trick for the software engineer is to determine which tasks are really necessary. We have a simple way of determining this. We ask the following question about everything we do: If we don't do this activity, or produce this artifact, will anything bad happen ? If the answer is "no," we don't do it. That seems simple enough. But you have to be brutally honest. It is very easy to fool yourself and tell yourself what you want to hear, rather than recognize reality. You can convince yourself that nothing bad will happen if you don't document your design anywhere except in the code, or if you don't address architecture issues early. You may be able to produce software that works today, but is not sustainable for future releases.

Bob Martin, from ObjectMentor, has a slightly different way of stating the question above. He says that you shouldn't produce the artifact or perform the activity unless something really bad would happen. ^[4] We can quibble over how bad something has to be before you do something, but you get the basic idea.

^[4] Bob stated this in a posting to the XP mailing list in 2001.

Address Risk

Another way of thinking about the prime directive leads to the next project guideline. If we're going to do something to avoid a bad outcome, then what we're really saying is that we need to make sure that our process addresses risks. Think about it. Why would you do something if it doesn't address a real risk that you face? Now, not every action you take on a project is directly related to a known risk. That is okay. There are things that you have to do in order to ship your product. If you don't do them, then a potential risk may become an actual risk. See Project Guideline 8.

Project Guideline 8 Have a risk-driven process

Make sure you perform activities and produce artifacts that reduce risk.

Don't Reinvent the Wheel

So, we have to make sure that we do the right things, and don't do unnecessary things. That's great to say, but what things should we consider? If you have ever tried to establish a process in an organization, you know what a difficult job it can be. You may have a wealth of software engineering experience, but it takes time and a lot of effort to put together a coherent , consistent description of what needs to be done. What should you do? Project Guideline 9 will tell you.

Project Guideline 9 Start with a proven foundation

Base your process on proven practices, techniques, and principles.

We're concerned about software reuse. We should also be concerned about process reuse. Starting from scratch and reinventing the wheel, so to speak, is never cost-effective for the following reasons:

• There is too much information to wade through and absorb .

• Once you do uncover the information, you still have to decide how the different techniques work together and how to present the information in a coherent, consistent way.

• Not every idea or technique really works for your project.

Let's consider each of these separately, starting with the amount of information. There is so much information about technology, process, management, and so on, that it is impossible for any one person to keep up with it. Gary reads the mailing lists for XP and agile modeling. About two hundred mail messages appear each day on just these two lists. There is a lot of noise on these lists, but if you want to understand what is happening in the communities, you need to read them. There are usually one or two messages that really have something interesting each day. Add in the articles and books on XP and agile software development and it's hard to keep up with just one area, let alone multiple areas of interest. Now assume that most people have "real jobs," such as developing software. By using a process framework or reusing a process instance, we let others mine the field and distill the interesting information for us.

Next we have the problem of producing a process that is well-defined , consistent, and understandable. What format should you use to present the process to your team or organization? Are there examples and instructions? Is each person on the team forced to look at all of the details, even if they already know what they're doing? There are many more questions and issues to address. When you start from scratch, you have to think of everything. This situation is similar to the software developer who can either develop a set of cooperating classes from scratch or use an object-oriented framework. Smart developers will always start with an existing set of classes and customize them to fit the situation when they can. Smart process engineers (people who configure processes for development groups) start with an existing process and customize it for their needs.

Finally, when you have a set of practices, principles, artifacts, and so on, you need to decide when they apply. We often talk about using best practices. What does that really mean? Are there universal best practices that apply in every situation? Perhaps; however, many, if not most, apply best in certain cases and you need to know when to use the practices rather than blindly follow them all the time. This means that you need to configure your process for specific contexts and projects.

Make Your Process Yours

Tailoring your process means more than just selecting a subset of the practices, activities, and artifacts that might be specified by your process. It means you should select those that fit together in a consistent way. It also means that you should feel free to modify them by removing things that are not necessary (the prime directive) and adding things when necessary. This brings us to Project Guideline 10 and its corollaries.

Project Guideline 10 Configure your process

Tailor your process for every project. Don't assume that every aspect of a process will automatically apply to your situation.

Accepting process guidance blindly is a sure recipe for disaster. You might think of this in the context of a road map. If you want to travel from Lexington, Massachusetts to Cupertino, California, there are thousands of possible routes. You need to decide which is appropriate for your needs. If you go to some of the Web sites that provide driving instructions, you are offered a choice of routes, depending upon your ultimate goal. ^[5] Similarly, you may choose one process if you are under extreme time pressure because of a rapidly changing market, and another if you have significant overhead imposed on you by customer requirements and regulations.

^[5] The MapQuest site, www.mapquest.com, asks if you want the shortest distance or shortest time route. You could consider many other parameters, based on the sights you want to see or other interests.

One thing we have found in our experience is that people tend to configure too much into their process. They think that if they are not sure whether they need something, they should do it. We recommend doing just the opposite , as stated in Corollary 10.1. If you omit something you really do need, it usually shows up quickly and you can add it. If you add something you don't need, you often will just keep doing it and never remove it from your process because you don't know that it isn't necessary. The choice is yours, but we prefer doing less rather than more. We find that the risk is usually small.

Corollary 10.1 When in doubt, leave it out

When configuring your process, if you are not sure whether to do something, don't do it. If you later discover that you need it, you can add it.

How do you decide if you are doing something that's unnecessary or not doing something you need? If you are doing something that is not necessary, you can usually spot it during your iteration reviews. During these reviews you not only assess the work done and progress made, but you evaluate the effectiveness of your process. Some symptoms that can indicate useless work are:

• You produce an artifact that no one looked at.

• You did something that did not lead to delivering software or reducing risks.

Always ask yourself, why am I doing this and who cares?

Configuring your process is more than just deciding what to do, when to do it, and how to do it. It also requires you to decide how formal you need to be. Once you decide that you need to perform an activity or produce an artifact, you should decide how rigorous you have to be. Should you use a tool? Will the artifact need to be modified continually? Who will look at what you produce? These are some of the questions you have to ask yourself to determine how formal you need to be. We find that small teams are usually less formal than large teams . This makes sense because there are fewer lines of communication that need to be established, and those that do exist are usually quite informal ”possibly one team member leaning over into another team member's work area and asking a question. Whatever you decide, don't be formal for the sake of formality . Don't lose sight of your primary purpose, to deliver working software to your customer.

How do you configure your process? There are several approaches. We find the easiest is to configure it by focusing on artifacts. That is, we decide what artifacts are necessary to help us reduce risks and deliver the software, then base our process on producing the artifacts. If we know what we have to produce, we can figure out how to produce it. In the next chapter you will see how we configured the process for the PSP Tools project.

Corollary 10.2 Take an artifact-centric approach to process configuration

Configure your process based upon the artifacts you need to produce. Once you know which artifacts you need to produce, you can then figure out how to produce them.

We will see more process-oriented project guidelines in later chapters. The ones presented here are the ones that are most important to understand.

Use Your Brain

We have one final process-oriented guideline, Project Guideline 11. It almost seems silly to mention it, but we have often been surprised by the number of projects that forget to apply it.

Project Guideline 11 Apply common sense liberally

Having a process to guide you in your development efforts does not absolve you from using your brain and applying common sense.

People, especially software engineers, are paradoxical. On one hand, they want to be creative and hate being told what to do. On the other hand, they want someone to show them how to do things. The key is that they want to be given the freedom to do things they like to do ”the creative activities that challenge their intellect. They are looking for step-by-step instructions for the simple, repetitive pieces they would rather not have to think about. They also want to make sure that the creative parts dominate their time and that they don't spend one second more than necessary on the drudgery.

If you don't consider Project Guideline 11 when configuring your process, you may end up with a process that is too heavy: process for the sake of process. Instead, you want your process to account for the skills of the people on your team, along with your project and organization needs.

When using a process, even if it has been configured, you still need to apply common sense. When the process prescribes something that does not support the people or the ultimate goal, you have the responsibility to question the process element and ensure that it adds value to the project.