New Year’s Resolutions…

Have you made any New Year’s Resolutions? Each year, many of us make resolutions that we try to accomplish during the year. So many of us make resolutions, that there’s a Top Ten List…. Not surprisingly, we often fail to achieve all of our resolutions. Health clubs, for example, see a big spike in new members in January and a corresponding high drop out rate in March. Nevertheless, we sometimes succeed in achieving some of our resolutions…

Making resolutions to improve our personal lives is important. If making resolutions can help improve our personal lives, why not use resolutions to help improve the ways we work…

To help get you started, here is my Top Ten List of resolutions for software development organizations for you to consider. These resolutions represent areas where improvements, even small improvements, can have significant payoffs:

Top Ten List

1. Resolve to measure your work – at the organizational, project, or task level.

Everyone needs to have a basic set of measurements to use in their daily work. Ideally, the measurements should be simple, easy to compute, and most importantly, related to your overall business goals. Here are some examples:

For developers

• How many defects did I fix this week?

• How many defects did I create this week?

• How much time did I spend working on a task on my schedule this week?

For testers

• How many new tests did I write this week?

• How many tests did I execute this week?

• How many new defects did I report this week?

• How much time did I spend working on a task on my schedule this week?

For managers

• How many known defects were not fixed in the last release?

• Can my organization meet it’s goals for the year?

• How do I know if we are on track or not?

• Are customers satisfied with the quality, features, and timeliness of our products?

Look in my February 2005 newsletter, where you’ll find suggestions for other quality measures…

2. Resolve to improve the quality of your work.

For developers - learn new techniques to reduce the number of defects injected into your code...

For testers - acquire domain knowledge, improve your testing skills, or actively participate in a requirements review to help identify problems sooner rather than later…

For managers – require that project teams reduce the number of known defects not fixed in the last release by 10% in the next release…

Remember that you need a good definition of quality before you can start measuring. Refer to my December 2004 newsletter for some thoughts on how to define quality…

3. Resolve to start projects with well-written, unambiguous requirements.

More projects fail due to poorly written requirements than for any other reason. The cost of poorly written requirements is significant. We often ask people who have no training in how to write good requirements to do this critical task…

Consider providing training for people who write requirements so they can do a better job.

4. Resolve to manage changes to requirements.

While it is not always possible to have all requirements defined at the beginning of a project, recognize that changes to requirements will have a ripple effective on all aspects of project work. Do this in ways that will identify the real impact to the project, the business, and your customers.

Read about requirements:

• Robin Goldsmith, Discovering the REAL Business Requirements for Software Project Success

• Karl Wiegers, Software Requirements

5. Resolve to institute effective peer reviews.

Making peer reviews effective requires training and management support. The most important peer review to do is a peer review of the requirements.

Find out how you can get your staff trained in planning and conducting effective peer reviews...

One way Management provides support is to resist the temptation to cut peer reviews from schedules in an effort to save time, since that invariably does not work.

Read about Peer Reviews:

• Karl Wiegers, Peer Reviews in Software: A Practical Guide

6. Resolve to improve your ability to accurately estimate tasks and effectively manage schedules.

Many projects are doomed from the start because they have unrealistic estimates and poorly managed schedules.

Find out how you can provide your staff with training in effective techniques for accurate estimating and scheduling…

Read about estimating and scheduling in the October 2004 newsletter…

7. Resolve to identify, manage, and mitigate risks.

Capers Jones on managing risk:

"Software has long been regarded as one of the most risk-prone of all engineering activities. Risks such as schedule slips and cost overruns tend to occur on more than 50% of all large systems. Even more severe risks, such as cancellation of the project prior to completion or serious quality deficiencies are not uncommon." [1]

Capers Top Ten Most Serious Software Risks, based on surveying hundreds of projects, includes:

• Inaccurate Metrics
• Inadequate Measurement
• Excessive Schedule Pressure
• Management Malpractice
• Inaccurate Cost Estimating
• Silver Bullet Syndrome
• Creeping User Requirements
• Low Quality
• Low Productivity
• Cancelled Projects

8. Resolve to fulfill your commitments you make to others.

We make commitments to our colleagues, our boss, our customers, etc., every day. Things like: “Ill have that bug fixed by the end of the day.” Or “I’ll get the customer a patch release tomorrow.” Or, “Of course we can include that new feature in the next release!”

Watts Humphrey on managing commitment:

"The role of the management system is to ensure that projects are successfully completed. This implies some organization-wide agreement on the meaning of the terms 'success' and 'completion.' It also requires a continuing management focus on the progress of each project. [...] This involves managing commitments, project oversight, and contention." [2]

9. Resolve to assess the effectiveness of your testing.

Testing is a very expensive, time-consuming activity. Yet, we have few ways to measure how effective our testing is. Testing requires a significant investment in time and effort. Each year, companies spend hundreds of thousands of hours testing software. Typical test suites often number into the thousands of tests, many of which require hundreds of hours to develop, maintain, and execute.

Often, tests are written against requirements that are vague and ambiguous. Regression test suites evolve over time and often include large numbers of what I call “non-productive” tests. These tests oftenare looking for problems in areas where there aren’t problems. Couple this with the fact that testers are inclined to develop more tests in the areas of the application they are most familiar with, leaving other areas under-tested or not tested at all.

My April 2005 newsletter has a discussion on how to assess the effectiveness of your testing.

10. Resolve not to make the same mistakes on your next project.

In today’s business climate, it is unconscionable that companies continue to make the same mistakes from project to project. Project mortems are not an effective tool for changing behavior. There is a better way. It’s called a Project Retrospective. Learn to avoid making the same mistakes using Project Retrospectives…

Read about Project Retrospectives:

• Norm Kerth, Project Retrospectives – A Handbook for Team Reviews

• For an overview of Project Retrospectives, see my June 2005 newsletter…

Summary

Resolutions can motivate you to improve your skills. Here are some suggestions for personal resolutions:

For developers…

• Read Steve McConnell, Code Complete

• Read Watts Humphrey, A Discipline for Software Engineering

• Improve your skills by attending a short course or workshop. Find Short Courses and Workshops in the Boston-area

For SQA folks…

• Read Lessons Learned in Software Testing by Cem Kaner, James Bach, and Bret Pettichord.

• Attend local meetings sponsored by your local SPIN chapter or ASQ Software Division chapter. Find conferences and meetings in the Boston-area.

• Become a Certified Software Quality Engineer (CSQE). Get CSQE Info…

For managers and executives…

• Read Watts Humphrey’s book Winning with Software

• Make some of the resolutions listed above!

Pay it Forward

If you find this newsletter of value, please consider the following:

Norm Kerth is a highly respected consultant who developed the Project Retrospective techniques discussed in the July-Aug newsletter. He was in a serious car accident and suffered a disabling brain injury. As a result, he cannot work and lives on a very limited income. You can help recognize his contribution to our industry by sending a small donation. Checks can be made payable to Norm Kerth Benefit Fund and sent to Norm Kerth Benefit Fund c/o Process Impact, 11491 SE 119th Drive, Clackamas, OR 97015-8778. You can also visit Karl Weiger’s website (Process Impact) for more details about contributing to the fund. Thanks.

Read more about the Pay It Forward foundation…