So far, we have taken a look on how to give the right response to common management mistakes. Today, I would like to take a closer look on the underlying problems that make a test manager react to management mistakes in an inappropriate way. By re-iterating over the dialogue of our manager Magnus and our tester Tim again, we’ll try to guess what the initial reaction could have caused, and therefore seek out for opportunities on how to solve the process problem.

Here are the links to the prequel of this blog entry:

• Management mistakes (Part 1) from Michael Bolton
• Testing and Management mistakes
• Testing and Management mistakes: Replacing placating with blaming
• Testing and Management mistakes: Congruent responses

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?”

Magnus plans in two days of lead time for Tim to re-arrange his family leave in order to be able to get to work on the weekend. This is surely a cause of the previous weeks, as it turns out later. Magnus already became used to convincing Tim on short-notice to turn in for the weekend. Magnus became conditioned by Tim’s earlier behavior, just as Pavlov’s dog. Operant Conditioning might be a cure for this underlying cause here. If Tim would now force a punishment, the negative feedback loop may be broken up. Of course, over time Tim will feel enough pressure to bring in some form of negative reinforcement for Magnus – one way or the other. So, the root-cause here is placating behavior from Tim as a reaction to the (almost) blaming behavior from Magnus.

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.”

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

Magnus is diving into interpretation here almost directly. The only thing that I can derive from the developers thinking they have fixed that many bugs, is that they worked on those bugs. It does not mean they worked pretty hard on it. It just means that the developers think they were fixing that many serious bugs. Actually, it’s nothing, until it’s reviewed goes also for bug fixes. Seriously, it’s nothing until it’s tested. That said, Magnus dives into interpretation and judging mode far too soon. In addition he gets attracted by the numbers and the outlook of the promising delivery. Having faced some assessment and education on Myers-Briggs or another personality model, would reveal his self-blindness in this situation. Maybe Magnus can become more aware of his deficits by getting taught about his personality and acting accordingly.

Tim is just a tester. He may not experience consciously this flaw. But he has to suffer under the outcome of it. So, making Tim aware of the model and talking consciously with Magnus about the situation, his addiction to numbers in this particular circumstance, could help overcome his self-blindness. Though, Tim would need some advice on how to give that advice in a manner that Magnus will accept. Thus far, I never achieved this.

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.”

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

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

There are two messages I can derive from Magnus here, pointing at a serious, but far too common problem in software management. First, he sends out the signal to his developers that it is more important to fix bugs than to test them. By measuring the poor bug fixing rate, the emphasize for the project is clearly given in this situation. Second, he frees precious developer time from testing the fixes. Actually, he tells his developers, that it’s more important to fix the bugs, rather than test them. This is a very bad combination, but far too common.

Tim reacts greatly here, but without Magnus listening to his point the effort is basically waste. Magnus should take the time to listen carefully to his tester in this situation. This would not only raise the trust level for him in the eyes of Tim, but also make him aware of the most serious problems he’s introducing. As a manager, you have to pay attention to what is said to you.

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…”

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.”

Tim seems to be very aware of Agile software development, and knows that co-location the whole team is the right way to tackle the clear team problems they’re facing caused by bad management. Again, Magnus is not listening to the points from his tester. Instead he gives in to react upon Tim’s try to manage the project by asking for a change in the team settings. Far too often I have seen such reaction, where the project manager explains what type of testing is needed. If the manager starts to make these decisions, you’re seriously in trouble. A good testing lead would have explained Magnus the flaw of his assumption, that high-level testing is sufficient. I wonder when this message reaches management world-wide, as I see it far too widespread.

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.”

Again, Magnus should pay attention to the project here. The underlying cause here is the ignorance of relevant facts. With the help of systems thinking, he could see the outcomes of his management decisions here. Tim is clearly not in charge to make the test cases pass. The bugs need to be fixed accordingly by the developers. But based on the previous statements, they got higher priority fixing the remaining bugs. Weinberg called this short-term relief, long-term pain reinforcing feedback loop the addiction cycle. Tim is basically doomed when the developers won’t start to take care for the quality of their own product. The short-term relief caused by the mandated overtime for Tim does not pay this one off, so in the long-term the team will continue to struggle.

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.”

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.”

“We don’t have time to do X” almost always boils down to a management problem. Notice that Magnus uses this phrase quite often in the overall conversation. Bringing in some NLP-approach from Tim’s side here could help. Obviously Magnus is put under pressure, either by time or by his upper management. But he should relax and take conscious decisions rather than giving in. The first thing that shuts down in a crisis is the measurement system as I learned from Weinberg in QSM Vol. 4. And the situation never improves if you shut your eyes when faced with obvious problems. Looking away from the flaws in the written test scripts, will not improve them. Neither will it improve the quality of the delivery. If there is a problem with the time, Magnus clearly should tell Tim to take the time to improve them. Obviously, Magnus did not learn to resist this pressure.

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.”

It’s obvious from this statement, that Magnus just jumped on the Agile wagon without understanding, what it means. One of the core statements in the Agile is to embrace change, even late in the development cycle. In addition, self-organization does not mean self-leadership. The lack of leading the developers and the testers to success is causing here most of the problems. Most probably Magnus view here is shaded due to some emotional reaction. Therefore he’s not seeing the underlying problem here. I don’t claim that Magnus should be a Vulcanian, but he should at least know how to use his emotional reactions wisely.

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.”

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

The aforementioned flaws boil down in Magnus’ last statement here. He does not know how to give in to the pressure from multiple sources, he does not know how to keep his emotion out of the way to do proper management. Tim is just reacting here to the clear blaming behavior from Magnus, and maybe this is the single alternative he now has in this conversation – of course, besides leaving the company.

What I’m really wondering now is, whether Magnus had some education in managing software projects, or if all his reactions were self-educated. What about the manager(s) in your company?