Managing Product Development

I’ve been working with Gil Broza on our teleclass series, Prevent Your Agile Titanic, both on marketing it and on its content. And it never fails, we have questions for each other almost every day. Sometimes I’m developing something and it looks “funny.” So I ask for review. Sometimes, as with the content, we discuss and one writes, and then we switch.

Pairing seems natural to us. We hadn’t paired before this venture, and that doesn’t matter. We are both ready to pair, which helps. Neither of us have egos that get in the way of the outcome: a great series of classes.

Tweet This Post

I’d recommended a group consider pair-programming as a technique to help everyone learn more about the system. One of the developers came up to me later and said, “How do I give feedback while pairing?” I said “Nicely,” and promised more specifics. Here are my guidelines for pairing feedback:

• Explain the effect on me for that line of code/writing. “I’m confused by that…” with the specific confusion.
• Recognize when it’s time to change positions. If I’m the navigator and I object constantly, it’s time to change seats.
• If one person says, “I wouldn’t do it that way,” the other person has the right to say, “Ok, but we both have to live with the product; this isn’t just yours.”
• Don’t label the work product. “This code is awful” is useless feedback. It doesn’t explain what’s awful, and the label feels like it’s on the person, not the work product.
• Meta-feedback: Listen for laughter or some other expression of enjoyment. If no one is laughing or obviously enjoying the pairing, something could be wrong. When Esther and I stopped laughing when we were writing Behind Closed Doors, we knew it was time to stop for the day.

I’m sure there’s more and I’m blocked for now. If you have a favorite mechanism for feedback while pairing, please comment. And read some of Esther’s writings on feedback, especially Peer-to-Peer Feedback.

Tweet This Post

I was sitting on the couch was organizing a database last weekend, with daughter #2 sitting next to me. I was creating a script to go through each record removing a field’s contents and adding new contents to another field. Not a difficult thing to do. I created a loop, and daughter #2 said, “Hey, how does the computer know how that loop will end?” She’s not a developer. I don’t think she’s seen the inside of a program. But she knew enough to see that I had an infinite loop.

I’m a pro at creating infinite loops. When I was developing, I would regale Mark with my infinite loops. But when I was a developer, I had a notebook in which I marked all my normal techniques for writing infinite loops. I don’t write many scripts these days, so I don’t track my loop tendencies. Which is why it was even more important for someone to be sitting next to me while I was working.

I took advantage of the situation, and asked her what I should do instead. She pointed out what I could do, I suggested another technique, she replied with another suggestion, and we both jointly agreed on what to do. The whole conversation took maybe 5 minutes.

The cost of the infinite loop was small, but instead of having to clean something up, I was able to write it correctly and continue with my work. It would have taken much more than 5 minutes to clean up that mistake.

Pairing while I work has been cheaper for me, in terms of preventing defects. Peer review after I write something is next, followed by formal inspection, followed by me finding my defects and fixing them. I was particularly pleased with this pair experience. Even though I didn’t impress daughter #2 with my software development expertise :-) Better to be unimpressive than to spend more time fixing.

Tweet This Post

I’m teaching project management (and some hiring) workshops in Israel. I’ve caught up with timezones, so I may even be able to post this week.

I attempted to explain why pair programming works to some skeptical project managers last week. I explained that in the best environments, a person can work 6 hours a day on technical work. And that person creates defects as well as creates work product. When pairing, the person can work for about 2 hours at a time, 2 or 3 times per day. But the created defect rate is much lower. The skeptics in my class pounced on the time spent working. I think I dealt with that question. But the real question that stumped them was how to do performance evaluations and give raises to pairs.

The problem I have is this: how do these managers give performance evaluations and give raises now? No one writes code or tests or whatever in a vacuum. All software is interdependent. So why is pairing somehow different? If we always performed peer review or inspections, wouldn’t it be the same problem?

I need more words or ideas to help explain pairing more successfully. Or, I need some more arguments to help people overcome their fear/resistance to this new-to-them idea. Got any words for me?

Tweet This Post

I’m working with Esther this week on the book. We’re editing (and continuing to pair-write and pair-edit). Today, one of the things we addressed were the comments dealing with the people we name in the book. We hadn’t done a good job drawing our readers in to care about the people. So we’re fixing that. One technique we’re using is to fill out a character sheet about each character.

I already had a picture in my head for each character. Esther may have, and her picture is different from mine. At one point today, I joked, “Can’t you just read my mind?” Esther replied (with a straight face), “No, your skull is too thick.”

Well, we lost about 5 minutes of work with that. I was almost rolling on the floor. Esther laughed almost as hard as I did.

Even when pairing, people can’t know what the other person is thinking. You can be headed in the same direction, but still veer off. And that’s ok. We don’t have to be clairvoyant to be effective working with each other. And I still think that pairs who laugh together are very effective.

Tweet This Post

Esther and I have been editing the management book this week. We’re pairing to edit also – one keyboard, one file, two heads. It’s exhausting and fun. Here are things I’ve learned this week:

• We don’t have the same default ways to write — and that’s ok. The manuscript is richer for us talking through how the words should be.
• When we’re laughing out loud, we’re synching. Not quite in flow, but close.
• When one snaps at the other, it’s time for a break.
• The product is much better than it would be if we did the standard one-person-write/other-person-edit pass back and forth. We tried that. The writing is crisper. The word choice is better. The manuscript flows.

If you haven’t tried pairing yet, to create some form of intellectual property, consider it. I’ve paired for programming and for writing now. It’s fun. Exhausting and trying sometimes, but absolutely worth it.

Tweet This Post

Esther and I are working together this week, starting over again with the management book. This time, we’re pair-writing, and it worked surprisingly well today. We collaborate — and we have conflict, where the person at the keyboard says, “Oh no, I’m not writing that down.” However, we worked until about 5:30 today, when we were were exhausted, but have close to two chapters in first draft form. And, this first draft is far superior to the previous first drafts.

Writing English (or any other natural language) is different than writing code. In English, it’s not just the design of the writing that we discuss, it’s also the structure and the actual words. Computer languages are much more structured and very specific on how the language can be used. So we have more options for every decision. It’s a challenge, but it’s working. With any luck we’ll have more to share later this week.

Tweet This Post