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?

YES!

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 project fails. Why should this be, when no one forgets to claim credit when a project succeeds? Ultimately, when the company suffers, every employee will suffer. Everything in a project is as much your business as that of the manager. 

Sometimes project managers know little more about the problem areas than the team members actually working on the projects. People who actively participate in coding and testing ought to know weak areas better and before anyone else. Your input may work as a catalyst to the manager’s planning process. Share your thoughts with your manager.

Foresee the problem

A testing team complained about a slow “bug correction cycle” until they failed to deliver their first client delivery on the scheduled date. The bugs in that version were still pending to be fixed. Surprisingly, the developers were almost ready with their code for the second delivery version the very next day. While inspecting the problem, it was found that the development team was busier writing new code than correcting bugs in the existing code. If the testing team hadn’t neglected the issue and had foreseen the problem, the team could have made the client delivery as scheduled. As if this were not enough, right before the final delivery, everyone in the team had to be on a tight schedule correcting old pending bugs. They managed to slip the shipment by one week, and a very messy product was delivered. When you face a problem repeatedly, try to foresee its cumulative effect in coming days or weeks. Think about potential consequences. You may seem like a “busybody,” but you might also save headaches for yourself and others, and perhaps avoid missed delivery dates.

Finally, team spirit is the key

The final product is a cooperative creation of your team, not of a single great mind. You should feel concerned about the team’s success and the project’s future rather than only your own performance. You surely can make a difference to the project’s fate. The team will work together better, and you’ll ship a higher quality product, if you identify the clues, analyze them, visualize their effects, and then talk about them. By involving yourself, you will push your project one step nearer to success. 

The choice is yours—speak up early or wait silently until you’re trapped.