Show me an IT project that runs without speed bumps, and I'll show you a work of fiction. Certainly, roadblocks are to be expected with any work endeavor, but the skirmishes born out of ego, fear, or the need for control have to be among the most frustrating for any team -- and they hurt the final product. Many moons ago, I worked on a project that somehow managed to succeed, despite some players' resistance to teamwork and collaboration.
It started with a government agency's request for an application to be developed. The agency wrote up the requirements and handed them over to a third-party developer. Later on in the process, they hired my company to provide IV&V (independent verification and validation). Both the development team and our test team were devoted solely to the project.
[ More about the IT job on InfoWorld: "Eight is enough! IT's biggest frenemies." | Get your weekly dose of workplace shenanigans by following Off the Record on Twitter and subscribing to the Off the Record newsletter. ]
As testers we had a great working relationship with the developer "worker bees." The roadblock stemmed from the developer's management wanting total control over the entire process. They did not take kindly to the idea of someone else potentially questioning the thoroughness of their job, and they viewed IV&V as a negative metric generator.
In the beginning, we wanted to talk to the end-users to glean day-in-the-life-of information that would enable us to create more robust test procedures. But because the developers had come on board first, their managers convinced the government agency it would be a waste of time for us testers to talk to the end-users. They claimed the developers knew what the users wanted, and they considered the requirements to be well defined. In their estimation, our questions were unnecessary, and thanks to their efforts, our requests were regularly rebuffed.
At times it felt like a futile situation. Why had we been hired at all if we weren't given what we were needed to do the job? But our team's managers said to do what we could and they'd keep working with the developer and agency managers. We gave up butting our heads against the brick wall and did the best we could with what we had.
As it turned out, the government agency's point person for the project had previously worked in the very end-user job that our application was supposed to serve. He couldn't let us talk to the end-users, but was able to provide us with many ideas of various real-life scenarios to try out. Finally, a ray of hope!
As the project continued, our tests caused all sorts of problems to bubble to the surface -- if they didn't outright crash the application. This resulted in a large number of defect reports. Development management was definitely not happy about those metrics, but in contrast, the developers themselves appreciated the feedback and offered their fixes quickly.
The whole project took longer than it should have -- likely due to our inability to get more real-life scenarios from a variety of users. The desire not to "waste time" with tester/end-user collaboration up front was more than offset by considerable time and effort spent later identifying and fixing a host of easily preventable bugs, then retesting the application before a workable version could finally be delivered.
Those of us in the trenches managed to eke out one positive from the experience: The developers and testers considered ourselves on the same team with the shared goal of delivering the best, most error-free product possible no matter what. We found ways around the baffling roadblocks, and in the end, we were proud of the robust, useful application we delivered to the end-user. It easily could have had a different ending.
Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to email@example.com. If we publish it, you'll receive a $50 American Express gift cheque.
This story, "When developers battle testers, users lose," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.