This is a response to a recent blog entry from Michael Bolton. He challenges to spot as many management mistakes as possible in a short dialog excerpt between a project manager and a tester. I will quote the dialog and walk through each of the problems I can spot. Though asked differently, I will not only mention those problems related to management, but also to the tester there.

Magnus the Project Manager: “Hey, Tim. Listen… I’m sorry to give you only two days notice, but we’ll be needing you to come in on Saturday again this week.”

Tim the Tester: “Really? Again?”

The manager does not give the reason for this action. He simply states there is the need for the tester. This sets up emotional pressure on the tester, who does not want to let the team fall. I’m not sure if the manager put this up by intention or just by coincidence.

Tim on the other does not start to challenge the claim. The project manager simply says they need him, especially. But maybe another tester could do the job. What’s his mission? How long should he test? To whom should he report his results? Who is the client? Instead, he simply asks from the personal perspective, which might indicate an emotional reaction to the claim from the project manager. So, let’s look how the manager responds to this.

Magnus: “Yes. The programmers upstairs sent me an email just now. They said that at the end of the day tomorrow, they’re going to give us another build to replace the one they gave us on Tuesday. They say they’ve fixed another six showstoppers, eight priority one bugs, and five severity twos since then, and they say that there’ll be another seven fixes by tomorrow. That’s pretty encouraging—27 fixes in three days. That’s nine per day, you know. They haven’t had that kind of fix rate for weeks now. All three of them must have been working pretty hard.”

The build is a replacement for a broken build. The programmers seem to have produced some lousy work the last time. Now, that’s interesting information. Despite this valueable information, the manager seems to rely on the facts as counted by the numbers. There seems to be some corporate metrics program, that let’s this manager look more particularly on the number of bugs fixed than how many further bugs could have been introduced by fixing those. Again, this information is available in any bug database, but the manager simply ignores this valueable information. Last, but not least, his interpretation in the last sentence indicates that “more bugs fixed” means “harder worked”. This mustn’t be the case. Another point that Jerry Weinberg made me aware of, is the fact, that there is nothing stated about how many incidents correlate to the mentioned bugs. There could have been 10 bugs fixed by a single code line change. Similarly there could be a single bug which needs fixing in several components. The numbers alone lie here. A final point: The manager should know if his programmers have worked hard , if he would have paid attention to what they were doing rather than looking at the numbers, only.

Tim: “They must have. Have they done any testing on those fixes themselves?”

Tim clearly should know better here than to give in to the manager. The developers mustn’t have worked very hard as pointed out before. Tim could know this better, if he paid attention to the past of the project. Just by stating that the only outcome here is that the developers were working hard, he proves his manager correct – in the manager’s eyes. If you believe something hard enough, your mind makes it a fact. This is inattentional blindness.

Magnus: “Of course not. Well, at least, I don’t know. The build process is really unstable. It’s crashing all the time. Between that and all the bugs they’ve had to fix, I don’t imagine they have time for testing. Besides, that’s what we pay you for. You’re quality assurance, aren’t you? It’s your responsibility to make sure that they deliver a quality product.”

Of course the developers did not test, how could they deliver that many fixes otherwise? There are several pointers that this managers ignores relevant information. He doesn’t know if they tested their code, the build prociess is unstable, but that doesn’t give him a clue, either. In combination with the Assurance Fallacy of Testing (“You’re quality assurance, … It’s your responsibility…”) there really is more need to fix bugs, than to fix them properly. Of course, the build process crashing all the time could indicate a problem in the quality of the code these programmers seem to produce.

Tim: “Well, I can test the product, but I don’t know how to assure the quality of their code.”

When someone is arguing irrationally, don’t try to argue with logic. “I know that you have many duties as a project manager, but doesn’t the broken build process point out, that there might something wrong?” could be a response to get the attention of the manager back to quality rather than delivery. The hidden message Tim wants to send here just doesn’t work in this context.

Magnus: “Of course you do. You’re the expert on this stuff, aren’t you?”

Without knowing this particular project manager for sure, I sense that he is basically just trying to sell the idea on testing to this poor tester. For any reasonable tester it’s obvious that he does not know anything about testing at this point. Instead, by giving kudos (“expert”), he tries to let the tester feel comfortable. This is the “washing machine selling management”. In this style management acts as if they were selling you a washing machine. Here, the selling involves the tester to be the right person to do overtime on the weekend. Anyone who thought about testing at least a tiny bit, should get to the conclusion, that testers don’t assure any code quality. But as pointed out, the manager simply wants to get this tester to work over the weekend by sacrificing even his own credibility.

Tim: “Maybe we could arrange to have some of the testing group go upstairs to work more closely with the programmers. You know, set up test environments, generate data, set up some automated scripts—smoke tests to check that the installation…”

This is a brilliant idea. Let testers and programmers work together to fix the team problem, help programmers get started with unit testing and the like. Too bad his claim is interrupted here by the manager, thereby undermining the testers management capabilities. Of course, the tester shouldn’t make suggestions on how to manage the project here.

Magnus: “We can’t do that. You have high-level testing to do, and they have to get their fixes done. I don’t want you to bother them; it’s better to leave them alone. You can test the new build down here on Saturday.”

At this point, the manager fires back by telling the tester how to test. Personally, I think this is a response to the tester’s attempt to manage the project. Of course, the fallacy of testers interrupting and interfering with the development is inherent here. Testers help developers get going. If the priority is to fix the bugs, rather than to fix them properly, then it’s more important to get some software. If the software does not need to work, I can hit any other requirement (The Zeroth Law of Software taken from Weinberg’s Quality Software Management Volume 2).

Tim: (pauses) “I’m not sure I’m available on Sa…”

Magnus: “Why not? Listen, with only two weeks to go, the entire project depends on you getting the testing finished. You know as well as I do that every code drop we’ve got from them so far has had lots of problems. I mean, you’re the one who found them, aren’t you? So we’re going to need a full regression suite done on every build from now until the 13th. That’s only two weeks. There’s no time to waste. And we don’t want a high defect escape ratio like we had on the last project, so I want you to make sure that you run all the test cases and make sure that each one is passing before we ship.”

Noticed that this manager does not even let the tester finish? Again? This indicates that the manager does not have any interest at all to get to know what the opinion from his tester is. It’s more important to have him working on Saturday. Opinions do not count. In addition. he puts more pressure on the tester here. The schedule is of course pressuring this manager, but it’s his job to manage to get a quality release.

In addition his claims in this response are not congruent to his earlier message. He cares about quality from the tester, but not about the quality from this who arrange quality in the code itself. This is ridiculous and I really do not want to be in Tim’s situation at this point. The manager again tells the highly-educated tester what he has to do. Mary Poppendieck explained to me that this is really a problem.

Once again the manager is ignoring the facts. Every “code drop” has had problems in the past. So, where are the code reviews? Where are the unit tests and walkthroughs? Where are the design reviews? Given the information the manager seems to have, he could really do better.

Tim: “Actually, that’s something I’ve been meaning to bring up. I’ve been a little concerned that the test cases aren’t covering some important things that might represent risk to the project.”

This response again is good, but he could do better. Telling the manager that the problem indeed might be in the way he manages the project with the information at hand, is ridiculous. The Candidate Product Rule says, “Actually, it ain’t nothin’ ’til it’s reviewed” (Weinberg, QSM Vol. 2, page 290). This manager seems to manage by the rule, that it’s nothing until it’s tested, but we can skip review easily. The claim Tim makes here is still valid, but he doesn’t respond to the things Magnus just raised. He could bring his point out more clearly by doing so.

Magnus: “That might be true, but like I said, we don’t have time. We’re already way over the time we estimated for the test phase. If we stop now to write a bunch of new test scripts, we’ll be even more behind schedule. We’re just going to have to go with the ones we’ve got.”

Ah, the common time creation myth. Time is not created, you have to take your time. Especially for quality products there is no free lunch. You have to plan accordingly, incorporating the time it takes. The problem that the project is already over estimate, might as well depend on the manager of the project. And the manager is falling for the test phase fallacy. Testing is not a phase, bugfixing might be. Last, not adapting to the project as it unfolds by creating new test cases may as well produce the problems of tomorrow. This vicious cycle the Magnus manages to get in here is very common.

Tim: “I was thinking that maybe we should set aside a few sessions where we didn’t follow the scripts to the letter, so we can look for unexpected problems.”

Magnus: “Are you kidding? Without scripts, how are we going to maintain requirements traceability? Plus, we decided at the beginning of the project that the test cases we’ve got would be our acceptance test suite, and if we add new ones now, the programmers will just get upset. I’ve told them to do that Agile stuff, and that means they should be self-organizing. It would be unfair to them if we sprang new test cases on them, and if we find new problems, they won’t have time to fix them. (pause) You’re on about that exploratory stuff again, aren’t you? Well, that’s a luxury that we can’t afford right now.”

Well, the claim from Tim to do some exploratory testing to fill the gaps for the uncovered areas is great. Magnus’ response to it is fatal to the project. Again the project manager does not adapt to the situation at hand, after the project started to unfold itself. By getting risk-averse coverage of those areas which are not covered by the initial test cases, the manager sets himself up for tomorrow’s problems. Oh, and of course, it’s better if the customer finds the bugs, rather than have the programmer fix them now before the loss of reputation. Last, but not least, exploration isn’t a luxury, neither is testing itself. They’re both a necessity for quality software. Skipping either or both is not only undermining testers’ efforts, but also comprising developers who very well observe what managers do and don’t do. Finally, the manager has misunderstood Agile in the sense to develop software without the weight of documentation, but has not understood that Agile development needs a team. By separating the testers from the developers the manager undermines every benefit he could get from really doing Agile development.

Tim: (pauses) “I’m not sure I’m available on Sa…”

Magnus: “You keep saying that. You’ve said that every week for the last eight weeks, and yet you’ve still managed to come in. It’s not like this should be a surprise. The CFO said we had to ship by the end of the quarter, Sales wanted all these features for the fall, Andy wanted that API put in for that thing he’s working on, and Support wanted everything fixed from the last version—now that one was a disaster; bad luck, mostly. Anyway. You’ve known right from the beginning that the schedule was really tight; that’s what we’ve been saying since day one. Everybody agreed that failure wasn’t an option, so we’d need maximum commitment from everyone all the way. Listen, Tim, you’re basically a good guy, but quite frankly, I’m a little dismayed by your negative attitude. That’s exactly the sort of stuff that brings everybody down. This is supposed to be a can-do organization.”

If it’s natural for Tim to come back all the weekends, he will be asked again. Of course he shows his struggle during this conversation, but it’s really for the manager to influence to get what he particularly wants him to do. Again, in the example stated, the manager ignores very well information which is available to him beside the information he gets from the testers. The pointer to “bad luck” just reminds me on Weinberg, who stated to replace the word “luck” in the phrase with “management”, when a managers refers to bad luck. We might as well prey to the software gods, if a whole company can be built upon management by luck. Of course, the manager’s claims about commitment and can-do organization are just institutionalized to make his argument and get Tim motivated. The problem lies in the decrease of motivation after this conversation. Tim’s trust for proper management has surely decreased, and a few more of these instances may let Tim leave the company searching for a better job opportunity.

Tim: “Okay. I’ll come in.”

Finally, Tim gives up. Never do this, though it might mean to continue fighting for ages or to lose the job. This is ok, as you didn’t like the job, anyways, now do you?

That’s my more elaborate response to Bolton’s challenge. Now, which parts did I miss?