Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

Personal Quality Management 
with the Personal Software Process - Page 3

Alan S. Koch, ASK Process

Personal Quality Planning

"If you don't know where you are going, any road will do.
If you don't know where you are, a map will not help"

Watts S. Humphrey

High quality at low cost does not just happen; You must plan for it! As suggested by Watts Humphrey, there are two parts to planning: knowing where you want to go, and knowing where you are.

"If you don't know where you are going, any road will do."

Most of us never consider Personal Quality Planning. We may be unhappy with the quality of our work. We may be aware of the damage that poor quality does to our reputations or our company's bottom line. We may wish we could spend less time debugging and fixing problems; but we tend to be unsure what we can do about these things. This article provides lots of ideas about things that we can do, but taking advantage of these ideas requires that we take action. Deciding exactly what actions to take can be difficult to do unless you have a plan.

First, you must decide what quality levels you want to achieve. While absolute zero defects springs to mind (and is a laudable long-term goal), it is not a reasonable goal to strive toward. After realizing that you are human and prone to error, you must decide on a goal that is aggressive and challenging but achievable with available time and effort. If you are unsure of what might be a reasonable goal, a good starting point may be some level of incremental improvement over your current defect levels. (See, "If you don't know where you are..." below.)

Merely setting goals doesn't change much. To make material changes in your performance, you must make material changes in your actions. You must determine what steps you must take to achieve your goals, and what day-to-day process changes those steps imply. Do you need to log and track your defects? Do you need to do reviews you currently skip? Do you need to change your approach to certain tasks?

"If you don't know where you are, a map will not help."

Even if you know the quality that you want to achieve, you will still be lost until you know your current performance. What quality level do you normally achieve? ... at what costs? ... using what methods? If you can not answer these questions, you will not know where you are falling short of your goals or what direction you need to move to reach them. You won't even know when you have achieved your goals!

So, you must identify important attributes of your performance. What do you need to measure, and at what level of detail? For example, if you are going to log defects, what pieces of information will be important or useful? What will you care about? What will help you to determine how to improve your process?

Finally, you must actually measure your performance; collect interesting data over time and periodically examine it to see how you are progressing against your goals. If you are not progressing, what changes can you make to your personal processes to improve your performance? If you are progressing, do you expect the improvement to continue? And when you've reached your goal, celebrate! Then check your long-term goals to see if you need to set a new goal and continue improving your work.

Improving your work is hard but rewarding work. It requires good plans, specific actions, and measurement of your progress. Without these things, your best efforts are merely a shot in the dark

Personal Process Improvement

We have been talking about improving our personal processes, but have not yet looked closely at what this means. Every process (personal or otherwise) has a natural capability and a natural range of variation. This is easiest to see in a control chart like those used in manufacturing. (See the figure.)

The solid black line indicates the capability of the process. This is the expected result of the process. The dotted black line indicates the range of variability of the process. This is the range around the process capability within which the actual results generally stay. The red jagged line shows the actual performance of the process in specific cases, with time running from left to right.

The first step in improving a process is to gain control over it. A process that is out of control does not stay within an expected range of variation; it is essentially unpredictable. For most of us, project schedule estimation is like this. Each estimate we make is wrong by a different and unpredictable amount, sometimes over, mostly under, and sometimes by several hundred percent.

Gaining control over a process includes things like understanding the steps in the process, assuring that we do them consistently and mitigating outside influences on the process. For many things, gaining control will mean actually writing a description of the process steps, and creating a checklist or other mechanism to help us to remember to do the steps in the right order each time. Gaining control over the process results in its variability being limited to its natural capability.

Only after you have a process under control can you think about improving it. Improving a process involves things like changing the steps in the process, changing the way the steps are done, and enhancing the skills and tools that you use in the process. The net result of improving a process is a narrowed range of variability (as indicated by the big arrows, above). An improved process has a smaller range of variability, and is more predictable than it had been before.

The important point of this discussion is that you can not improve a process before it is under control. Your first focus must be to bring the process under control. Only after it is under control can you improve it.

Using Your Personal Quality Plan

A Quality Plan is a waste of effort unless you use it to manage quality. While the thought that goes into making the plan has value, the real value of a plan is in the effect it has on your work. If you make a plan and set it aside until the work is done, then you are losing the major value of the plan. The best use of your quality plan will be in validating each step of your process; that is, using your quality plan to determine if you have done a sufficient job at each step in your process before you move on to the next step.

We tend to think of "validation" as being certain types of activities, like reviews or tests. In fact, any activity can and should be validated, even review and test activities. This kind of validation allows you to manage what you do so you can achieve the desired goals.

For example, before moving on to the code review, we should take a few minutes to validate our coding activities by asking questions like:

  • Did I build all of the parts I intended to build?
  • Is the product as big as I expected it to be?
  • Do the pieces fit together as I intended?
  • Do I need to take any corrective action?

With our answers to these questions, we know if we are ready to move to the next step and validate the code itself in our code review. Then, after the code review, we should validate the review by asking questions like:

  • Did I find fewer (or more) defects than I expected?
  • Did I spend as much effort on the review as I should?
  • Is the defect rate consistent with my quality target?
  • Do I need to take any corrective action?

By using our quality plan in these validations of the steps in our process, we can detect when things begin to go awry, and take corrective action before the whole project is out of control.

Post-Project Data Analysis

Whether your organization does post-project reviews (sometimes called "postmortem" or "retrospective" reviews), managing your personal quality performance will generally require that you spend some time with your personal data at the end of each project. A small amount of time at the end of the project can yield major rewards in the next one.

At the very least, you should take a few minutes at the end of each project to assure that all interesting data about the project has been recorded and stored in a safe place. The more time that has passed since you did the work, the less likely it will be that you will be able to reconstruct the data from memory. While you should always strive to record data as you work, you should use the post-project time to assure that nothing has been missed, and fill in any holes to the best of your memory.

The data you collect about your project can be a gold mine. Make sure you analyze it on a regular basis and understand what it is telling you. With the right data stored in a usable form, you can do many things. For example, use your data to:

  • Plan your next project. Your best indicator of how you will perform on your next project is how you did on the last one. The best way to estimate product size, effort required and schedule is to compare the new project to others you have done and use your actual performance as a guide. (Don't expect your performance to be significantly different this time unless the project is very different, or you have made material changes to your process.)
  • Set quality goals. In the interest of making incremental improvement in the quality of your software, you will want to use your historical performance as the basis for setting quality goals. But realize that each project will not be better than the prior one was. There will be a certain amount of variability, but you want to aim for improvement over the long run.
  • Defend your plans. If your plans are base in historical fact, you will be better able to defend them to your management. Management will always pressure you to promise too much; but if you can show that you understand your capability and will deliver what you promise, they will learn to respect your estimates and plans.
  • Identify candidate processes for improvement. When your data shows that a process is either out of control, or has too wide a range of variation, you should use that information to look for ways to change the process to bring it into an acceptable range of variation.
  • Evaluate the effectiveness of process changes you have made. Each process change is not guaranteed to actually improve things. After making any change, you should carefully measure the results of the change to assure it had the desired effect and no undesirable side effects.

Personal Quality Management and the PSP

The Personal Software Process (PSP) teaches software engineers how to use a variety of disciplined practices, including the Personal Quality Management techniques described in this article. By learning to apply these disciplined methods, programmers can begin to make the transition from programming as an ill-defined craft toward software as an engineering discipline.

References

[Humphrey] Humphrey, Watts, PSP(sm): A Self-Improvement Process for Software Engineers, Addison Wesley, 2005

[Hays] Hayes, Over "The Personal Software Process (PSP): An Empirical Study of the Impact of PSP on Individual Engineers"CMU/SEI-97-TR-001

© 2000-2007 Copyright ASK Process, Inc.


Related Software Process Articles in Methods & Tools


Go to page 2

Click here to view the complete list of archived articles

This article was originally published in the Summer 2007 issue of Methods & Tools

Methods & Tools
is supported by


Testmatick.com

Software Testing
Magazine


The Scrum Expert