By Johanna Rothman
I was at the Better Software conference last week, met a bunch of great people (including Jim Shore and Joel Spolsky).
Another important person is someone who’s not famous–and important nevertheless. A senior tester explained her situation and asked for some help. “Most of our testers can’t read code. And, we don’t know what the developers are putting into the code when they fix problems. Even if the testers could read the code, we don’t know what to look for. We don’t know what to test. The developers add and change features without telling us.”
I asked if the developers had to write check-in comments. She said that they did not. I suggested she work with the build people to write a script that forwarded every check-in comment to an email list of all developers and testers. If there was no comment, it would be an empty email with just the person’s name and the filename. If there was something in the email, she and the rest of the testers might have more information with which to test.
On this project, there is little transparency about who is doing what and the kind of progress they are making. Normally, I wouldn’t email check-in comments to an entire project, but if there is no other way to see what’s happening, it might work.
Transparency in a project is key to the project’s success. No, it’s possible that not everything has to be transparent. If you’re working on a project where you have different levels of clearance for product content (something that occurs on DOD projects), then it’s critical to keep some content opaque, not transparent. But most of us work on projects where transparency would help–sometimes dramatically.
I didn’t gratuitously name-drop at the beginning of this post–I had a reason… Both Jim and Joel make portions of their work transparent to the rest of us, so we can learn from them. We need to learn from our own projects too. If there’s a piece of your project that seems to be causing problems for another part, think about how you could make the output of the “troublesome” part more transparent to everyone. You may well discover the troublesome part is reacting to someone else’s work that’s not transparent.
If you’re a project manager or involved with project management in some way, think about what is not transparent to the rest of the people involved with the project. Could you create some transparency to make things clearer? It’s worth a little thought.
Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.