Managing Product Development

A couple of weeks ago at our Managing One-on-One workshop, Esther and I were teaching about how to give feedback. Here’s the “recipe”:

• Create an opening to deliver feedback.
• Describe the behavior or result in a way the person can hear.
• State the impact using “I” language.
• Make a request for changed behavior.

When we teach feedback, we ask people to practice giving feedback using this structure. Some people take to the structure right away; some need to practice. One of the teams in the workshop had a little trouble giving feedback about hygiene. The feedback giver “fluffed it up” instead of getting to the point. The feedback giver said something like this (all names and situation changed):

“Raymond, got a few minutes?”

“Sure.”

“Good. I wanted to talk to you about something. How’re those Red Sox?” (and more like this for a couple of minutes) Raymond, I have to tell you something.

“What do you need to tell me???” (in a strangled tone of voice)

“Have you considered using mouthwash?”

The feedback receiver sat there with his mouth open, wondering what the heck was going on.

At that point, Esther and I intervened to help move the conversation back on track. Here’s another way for that conversation to proceed:

“Raymond, got a few minutes?”

“Sure.”

“Good. Raymond, I’m not sure you realize this. When I work with you on the budget, I can smell your breath. The smell is bothering me, so much that I’m not happy about working with you that closely. Is there something you can do?

“Oh no.”

“Yes.”

“Of course there’s something I can do! Let me use one of those breath mint strips. And, if I forget, just tell me, ok?”

A completely different conversation. Giving people personal feedback isn’t easy, and it’s necessary to keep a smooth working relationship. The quicker you are, as the feedback giver, to make your point, the kinder the feedback is. As someone in the workshop said, “It’s kind to be firm.”

Also this week, over at the AYE Conference, my Starting With Rolling Wave Planning is up.

I’ve had technical debt on my mind recently, so I’ve been writing about it. This week, the good folks at Stickyminds published my column, An Incremental Technique to Pay Off Testing Technical Debt. Enjoy!

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.