Originally published on stickyminds.com

I have a theory. I think that technical people are being insulated from important business matters. Perhaps it’s because management wants technical people to concentrate on technical concerns. Perhaps it’s because management isn’t convinced that technical people understand anything about business strategy. Whatever the reasons might be, I want to put my theory to the test.

Think about the project you’re working on now. Mentally examine your part of it, then expand your mind to encompass the entire project. Think about all the groups working on it and what they do. Think about the timeline. And think about the anticipated end result. Got all that firmly in the forefront of your consciousness? Good, because it’s quiz time. See if you can answer the following questions:

1. Why is this project important?

2. How does it contribute to the long term strategic direction of the company?

3. How will it improve the company’s competitive position in the near term?

4. How much will it cost?

5. What financial benefits (reduced costs, increased revenues, etc.) will the project bring?

6. Who will benefit most from a successful outcome to this project?

7. What will happen if the project fails?

8. What capabilities will the users find most compelling and why?

9. If users don’t use this software, what will they use instead?

10. How well would the majority of the technical contributors on the project answer these questions?

My final question is more personal: how did you feel when you were answering those questions?

If you felt confident that you understood both the marketplace in which your company operates and the business case for your project, you’re probably in the minority. More often I find that technical people (who themselves are usually quick to chastise management for technical cluelessness) are unaware of the business reasons behind project decisions.

No wonder many software defects boil down to miscommunications. It’s difficult to understand what you’re building if you don’t know why you’re doing it.

Let me give you an example of the importance of “why.”

Early in my career I was put in charge of document production at a small company. Eager to be precise, I provided precise measurements for the spacing of 3 holes along the left hand side of the 8.5″ x 11″ booklets. The day before the documents were due back, Barry, the manager at the document reproduction company, called me.

“Why do you need the holes in these documents?” he asked.

“Uh, so I can put them in 3-ring binders.” I replied, wondering where this conversation was going.

“That’s what I thought,” he said. “In that case, whoever did these measurements is smokin’ something.” I blushed furiously; glad he couldn’t see my expression over the phone. That would be me, I thought to myself. Barry continued, unaware of my embarrassment, “They won’t fit in a 3-ring binder at all. Should I just punch these for a 3-hole binder and ignore the measurements?”

“Yes,” I replied meekly. As I hung up the phone I realized that I’d made a silly mistake in trying to be so precise. My intent was to ensure that there could be no room for miscommunication. Instead, I’d almost caused a disaster. Fortunately, Barry had enough experience with documents that he guessed my intentions. Knowing intentions is the key to requirements. That’s the difference between “recorded requirements” and “real requirements.”

I often see requirements that read like my specifications for the three holes in the documents. They’re precisely worded, but there’s no hint about why the software should do what the requirements ask.

“The window shall be no more than 800×600 pixels in size.”

Lovely. Why?

Some of you may have recognized those numbers, a common monitor resolution. A window larger than that size will overwhelm the screen on a low-resolution monitor. But how much harder would it be to say, “The warehouse personnel use machines that operate at 800 x 600 resolution. All windows must fit on the screen without scrolling, so don’t make them larger than that size.”

If you are beginning to wonder if you know enough about the business, seek out the information you need. Read everything you can get your hands on: your company’s press release, financial data, competitor’s web sites, customer discussion forums, and consumer reviews. Ask your manager about the company’s strategic direction and how your current project contributes. Keep asking questions about the business until you really understand not only what you are being asked to do, but also why you are being asked to do it.

Then, if you find yourself in a situation like Barry, asked to do something that doesn’t make sense, you’ll have the knowledge to articulate your concerns. And in doing so, you might find that management is a little more open with technical people about their business concerns. Show them that you can learn about their world, and they’ll give you the information you need. Go ahead, challenge them to give you “the business.”

Originally published on stickyminds.com

Let’s peek in on a discussion in a bug triage meeting.

Tim, the marketing manager, is shaking his head. “That’s a high on the severity scale. It’s really bad, guys. You have to make it a high.”

Jordan, the development manager, is barely containing her frustration. Her eye is starting to twitch as she replies, “No, Tim. That’s not all that bad. It’s an inconvenience, I agree, but there’s an easy workaround.”

“Inconvenience?!?” Tim says a bit more loudly than he intended. “You call not being able to print an inconvenience?!? That’s a disaster!”

“Yes, I call not being able to print from one particular type of printer without installing an upgraded driver from the vendor’s website an inconvenience. The user just needs…”

“I know what the user needs,” Tim cut in. “The user needs to be able to print out of the box! You can fix this in our code, right?”

Jordan nods, “Yes, but we’d just be working around the vendor’s…”

“Then fix it.” Tim stood over Jordan, glaring.

“But it’s a medium at best!” Jordan objected. “The user isn’t losing any data, doesn’t have to reboot, isn’t crashing. They just have to update a driver.”

This argument could continue forever. I’ve seen many arguments like this go on and on. What’s really happening here? Why are Tim and Jordan about to be at each other’s throats?

Priority is Business; Severity is Technical
Tim is looking at business priority: “How important is it to the business that we fix the bug?” Jordan is looking at technical severity: “How nasty is the bug from a technical perspective?” These two questions sometimes arrive at the same answer: a high severity bug is often also high priority, but not always. Allow me to suggest some definitions.

Severity is levels:
* Critical: the software will not run
* High: unexpected fatal errors (includes crashes and data corruption)
* Medium: a feature is malfunctioning
* Low: a cosmetic issue

Now you see why Jordan was arguing that the Print bug was a medium: a feature was malfunctioning.

Priority levels:
* Now: drop everything and take care of it as soon as you see this (usually for blocking bugs)
* P1: fix before next build to test
* P2: fix before final release
* P3: we probably won’t get to these, but we want to track them anyway

And now you can see why Tim was so adamant that the issue was a high. From his perspective, it was a P1 matter.

They’re both right. It’s of medium severity, but P1 to fix.

Priority is Relative; Severity is Absolute
Further, the priority might change over time. Perhaps a bug initially deemed P1 becomes rated as P2 or even a P3 as the schedule draws closer to the release and as the test team finds even more heinous errors. Priority is a subjective evaluation of how important an issue is, given other tasks in the queue and the current schedule. It’s relative. It shifts over time. And it’s a business decision.

By contrast, severity is an absolute: it’s an assessment of the impact of the bug without regard to other work in the queue or the current schedule. The only reason severity should change is if we have new information that causes us to re-evaluate our assessment. If it was a high severity issue when I entered it, it’s still a high severity issue when it’s deferred to the next release. The severity hasn’t changed just because we’ve run out of time. The priority changed.

Priority and Severity Don’t Mix
In response to Johanna’s column last week, some people suggested using both severity and priority to come up with a composite risk number. While this intuitively sounds like a way to resolve the priority-severity divide, I suggest using such an approach with extreme caution. It’s multiplying apples by oranges in an attempt to quantify bananas. Risk is yet a third type of information.

The risk associated with any bug depends on the severity of the issue, certainly. But it also depends on the likelihood that the user will run into it as well as the possible losses that might occur. I don’t attempt to quantify all this when assessing the severity of an issue. In fact, I think that in most cases assessing the risk of a single issue takes more time than it’s worth. Only for potentially poisonous bugs involving dangerous fixes do I really want to weigh the risk of fixing it against the risk of not fixing it.

Establish Work Precedence
The best way to avoid confusion about what comes first is to ensure everyone in the organization takes their cues for work precedence from priority and nowhere else. Developers fix P1 defects first. Testers verify P1 fixes first. Technical writers document P1 issues first. Everyone works in priority order: the priority reflects importance to the business. Saying, “This bug is more severe than that one so I’ll work on it first” is as bad as saying, “I like this bug more, so I’ll work on it first.” The severity rating is technical information used by managers as a piece of the formula in determining the priority rating. The priority rating is the final word on the order in which the work is done by programmers, testers, and everyone else.

The ultimate lesson here, regardless of the terms or levels you use to categorize your bugs, is that any classification scheme will only be effective if everyone agrees on definitions. So perhaps that’s the very first question to ask when an argument is brewing about severity, priority, or risk: “Help me understand exactly what information you’re using from each defect record and how you’re using it?”

Originally published on Computerworld

“This new system is driving me crazy!” Janet, the hotel desk attendant, muttered as she punched at the keyboard buttons. She looked back at me, flashing her best customer smile. “Sorry, it will be a minute.”

She returned to scowling at the keyboard. Apparently the system finally accepted her input; she looked up at me with a satisfied expression. There was a pause as we waited for the system to respond. A long pause.

To fill the time, she asked, “So Ms. Hendrickson, what do you do?”

“I work with software development organizations to improve software quality.”

“OH!” she exclaimed. “I wish you were at corporate. I don’t know what they were thinking. This new software was supposed to be an improvement, but it’s much worse than the old system. It’s slow, and I can’t figure out what it wants from me half the time.”

I involuntarily began imagining the process at corporate.

A 15-person Steering Committee directed a five-person Requirements Task Force to analyze the business and user requirements. The Requirements Analysts sent out surveys, poured through help desk call records, and even interviewed a few users. They produced an 83-page tome that they handed off to the Designers.

A three-person Design team wrote a specification answering the requirements. The 96-page specification was nominally written in English, but because of the amount of jargon used it required a translation guide. The Design team sent it out for review with a deadline for comments. The specified date passed with no comments from the Steering Committee or the Requirements Analysts (who were off to new assignments so they couldn’t spare any more time for this project anyway). The specification went to the Programmers.

The Programmers implemented to the specification. There were a few things that were very difficult to do, so they compromised. It would be no big deal if users had to enter a few more keystrokes to access that information, right?

Then the Testers were given two weeks to test it. It took most of the first week to figure out how the new software worked. They found a few bugs, but no show-stoppers. The Programmers fixed a few things and the software was deployed to the field.

That’s where Janet comes in. Janet doesn’t know anything about the ins and outs of creating software. She probably doesn’t want to know. She just wants to serve her customers well. And this software is not helping.

Back at corporate, the Steering Committee, Requirements Analysts, Designers, Programmers and Testers are congratulating themselves on a solid release. What they don’t see is Janet’s pain.

All this flashed through my mind in an instant. I looked back at Janet. “Have you called corporate to tell them what you think?” I asked. “What good would that do?” Janet sneered. “I’ll wait on hold for 25 minutes before getting to someone at the help desk. And they’re never much help. No, I’ll deal with it. Maybe it will get easier. They’re sending me to training next week.”

So the feedback loop is broken. The team back at corporate has no mechanism to find out whether the software is any good. Oh, sure, they’ll detect catastrophic problems that cause servers to go down. But they won’t see the little things that cause long queues at the front desk of the hotel.

If we interviewed the team that created the system, they’d say: “This is our best release ever. We did all the right things. We analyzed requirements and wrote specifications before writing the software. We tested the software before we deployed it. How could the result be wrong?”

How indeed?

Perhaps important nuances were lost in the requirements and specifications verbiage. Perhaps the ship criteria, “no showstopper bugs,” could indicate either “solid code” or “not tested.” And perhaps the lack of a feedback loop from the field means they have no way of knowing how the users like the new system. “We’ve been deployed for a month and had only five calls!” the team crows. Like a broken pipe, they see only the trickle of complaints that make it through and miss the flood of complaints leaking away.

Of course, all this happened in my imagination. But I’ve seen it happen in reality. Ironically, organizations that control their software development process tightly don’t necessarily serve their users any better than organizations that cobble something together and throw it over the wall. It’s easy to become so tied up in process that we forget the reason for building the software in the first place. Unless we close the feedback loop, we don’t really know whether what we’ve produced is really any good.

Just ask Janet.