No individual is a success who hurts the team, and no one is a failure who helps it.
—Software Project Survival Guide by Steve McConnell
Programmers are there to do coding. Testers are for testing. Project leaders are responsible to coordinate and ensure it all gets done. Are you working in a team that believes in such one-man shows? Is everyone in your organization restricted to one territory, so that they can’t interfere in others’ business even if they have something relevant to share? It’s an organizational, political, and attitudinal problem. This is a problem that can seriously interfere with productivity and quality.
The last time we slipped a delivery, I heard testers talking to each other: “I knew it on my very first day in the project. The development team was just pretending to work. The first release to QA took forty-five days to happen. The bug cycle was too slow. The testing team didn’t get much time to prepare a test strategy. The code reviews detected that code conventions were not followed properly, but no corrective action was taken. So many flaws in a process and you expect it to be delivered on time? You must be kidding.”
The tester community laughed at the process, cried for the team’s failure, blamed the methodology, and kept quiet.
The developers in the other corner discussed something similar, which was now not going to help the project anyway. Some blamed testers for not testing properly, some complained about resource reductions, and some doubted the project manager’s capabilities.
But all agreed that they saw the failure much in advance, in their own ways.
There is always more than one reason why a project fails, and interestingly, the people contributing to those reasons are none other than the team members. When a failure occurs, some members try to scapegoat others to keep the heat off themselves. When a tester said, “I knew it from the very beginning,” others asked, “Then why didn’t you do anything?” He drew a blank at that. Could he have really done something to prevent the present situation?
Maybe he thought that it was not “his place” to give warnings about the project’s future. Some work environments unfortunately encourage a “know-your-place” mentality. Besides, he is paid for testing, which he did perfectly. Or maybe he saw a problem but didn’t connect it to a potential future disaster. The answer could be any of these. But could he have saved the project from failing if he had just talked about it earlier?
As testers, we often come across weak links in the system. While testing, we get to see not only the problems in the software, but also the problems with people, processes, schedules, and planning. Unfortunately, we tend to ignore these. But if you can detect a future problem, what should be your course of action?
Talk about it early
If you see a problem somewhere, don’t hesitate to talk about it. However small the issue may be, if you sense a danger, then approach someone responsible. By keeping quiet, you naively convert those deleterious possibilities into certainties. Don’t deliberately deny a problem, just because you don’t want to complicate everyone’s life. The earlier the problem comes to light, the easier it is to get out of it. Do not wait until it’s too late to do anything about it.
It is your business, too
Don’t ever make the mistake of only relating the project’s fate with people on the executive level. Testers, developers, and others in the team often think it’s the manager’s headache if a