Managing Product Development

I use enetation as my comment service. The comment spammers have found a way to access enetation’s database to spam this blog and my hiring blog. After receiving over 100 spam comments this weekend, I can’t take much more and am looking for an alternative commenting service. In the meantime, ignore the spam comments you see, as I slowly remove them.

Do any of you know how to import comments? I know how to export comments from enetation, but I don’t know of any comment services that allow you to import comments. Please send me email if you know how to import comments. Thank you.

Tweet This Post 

I led a two-hour writing workshop this past weekend. The attendees ranged from a 9-year-old who says, “I LOVE to write,” to retired adults who are involved in community projects who hate to write. We performed two writing exercises. Although the writing is useful, it’s the debrief of each writing activity that helps each writer grow. The first exercise was to write for three minutes to introduce yourself and why you wanted to attend the workshop. Some people had trouble writing anything — even for only three minutes. When it came time to debrief, people first read their intros (where that fit for them), we offered gentle commentary, and if people dicussed a problem, I referred them to the handout, so they would have a printed reminder of some suggestions.

The most fascinating debrief came from the participant who didn’t write very much. She’d written a few phrases, and proceded to speak her intro. Now, as a professional speaker, I certainly appreciate speaking. But she was stuck. I interrupted her several times and finally was able to break into her (speaking) fugue. She has “almost” finished a book. She thinks she needs another chapter, but she was stuck. She couldn’t figure out how to finish the book. She told us why: There is no finishing this story. One of the other participants caught that and gently said, “That’s the ending.” She was unable to process those words into meaning. So I asked her to repeat what she’d just said about no ending, and I said, “Write that down.” Of course, she’s an extrovert (like me), so she had no idea what she’d just said. Luckily, of the other 12 or so people in the room, other people did remember. I insisted she write down the phrase and sit with it for a while to see if that’s what she needed to end the book. She might need a paragraph or two, but no more.

If you are the kind of person who needs to speak in order to think, you’re an extrovert. Take care with your speaking, because as soon as you’ve spoken the thought, it’s out. You no longer need to write it down. I use a number of aids, including a voice recorder, to avoid losing thoughts I need to write down.

Those of you who are innate writers: make sure you’re not writing over your gems. If you write everything, it’s hard for other people to see the gems you’ve written. Edit yourselves carefully. If you love some words, take them out and replace them with something else. If you’re like me, and want credit for everything you write, save those words in another file and take credit.

In the second exercise, each of us wrote down three of our favorite words on index cards, one to a card. I collected the index cards, shuffled them, and then everyone took three cards from the pile. Each of us had 5 minutes to write something using those cards. Some people created compelling short stories. Others created marketing literature. I got started on an article that’s been eluding me for months. One person wrote “garbage” (his words, not mine). Even when this activity doesn’t succeed by starting you on your way, you write something. And if the something isn’t so hot, you throw it out, because you’ve only spent 5 or 10 minutes on it. BTW, I don’t think he wrote garbage at all. I think he wrote a yucky first draft — I heard energy and the germ of an idea.

I’m always amazed that timed writing can be so successful. To me, it’s successful because you know you don’t have to stare at a blank page very long. Joel Spolsky in Joel on Software and on Diverse and Occasionally Related Matters… says on page 51 (about why people don’t write specs) “…so many people don’t like to write. Staring at a blank screen is horribly frustrating. … Writing is muscle. The more you write, the more you’ll be able to write.” Knowing I can write for a short time frees me from having to write the whole darn thing — and being scared that I won’t be able to do so. Timed writing is like a Hudson’s Bay Start.

We discussed how adverbs weaken verbs (from Stephen King’s On Writing), Anne Lamott’s idea (from Bird by Bird) of the (expletive deleted) first draft, and a bunch of other ideas from Naomi Karten’s and my writer’s workshop at AYE the past few years. And, I pointed people to Brian’s blog entry about editing.

We discussed one of the ideas in Brian’s entry, that of taping the piece to the wall and reading it through binoculars. I sometimes print my writing and look to see what it looks like. I look for shorter-than-normal paragraphs and longer-than-normal paragraphs. I like to keep a particular tempo in the piece — unless I want to shake people up with something out-of-tempo.

If you’d like to write — or write better, start. You can start short, with 5 or 10 minute timed writing. (Write for 5 or 10 minutes. Do not stop. Keep writing. If you get stuck, write blah, blah, blah, but keep writing.) Find someone who’ll review it. Or put it aside and read it later. I find I need at least 24 hours before I can read with a critical eye and a critical ear.

Writing is not an innate skill — even for you introverts. The more I practice, the better I write. You too.

Tweet This Post 

Shimin asks, What do you mean by “peer review”? Here are my definitions:

Peer review. An author asks a peer to read, comment, and critique a work artifact. If the work artifact is code, the reviewer will read the code, and may even develop and run some unit tests to check that the code works as advertised.

Walkthrough. An author presents the work artifact to others. If the work artifact is code, the author walks through the code, explaining what this pieces does, what that piece does. If the author is like me, the author trails off in the middle of a sentence and says, “Oh no, that’s not what I wanted.” Or, “There’s the problem.”

Inspection. An author requests the services of a moderator, scribe, reader/reviewers in a formal meeting. The moderator books the room, sends out the material. The reader/reviewers read the material before the meeting. During the meeting, the reader/reviewers take turns reading the work artifact out loud. The scribe takes notes of issues the reader/reviewers discovered in advance and during the meeting.

Let me know if you have other definitions, or other techniques that don’t fall into these categories. These techniques are useful for any work product. You may have to modify them for non-code work products.

Tweet This Post 

I’m reviewing my students’ updated plans for their projects. One team originally wanted full unit testing on the code as it was created, but added (my paraphrase) “if the project is late, some unit testing will be acceptable.” I responded that the farther behind the project was, the more review and testing is required.

Here’s why. Projects get behind because the people don’t understand something. The more they don’t understand, the harder it is to create the product, and the more defects they introduce. This is not because the people are bad — good or bad development skills have nothing to do with it. This is a function of not clearly seeing what the system is supposed to be. If you find your project is behind, consider these options to help people see the system clearly:

• Hold peer reviews on every work artifact. I prefer reviews, not walkthroughs, but anything to put at least one more pair of eyes on the product is good.
• Inspect every defect fix. Yes, I do mean formal inspection, where someone reads the fix out loud.
• Full unit testing on every piece of code. The developer will understand his or her code when trying to test it
• NIghtly builds (more often if it makes sense). The faster the feedback to the developers about potential problems in their code, the faster you can decide what to do about the problem.
• Implement by slice. Instead of implementing the components of a system, implement just enough of a component to complete a given feature or use case. In my opinion, Big-Design-Up-Front doesnt’ work very well because the developers and architects don’t actually understand what they’re doing. This is not a competence thing ; it’s an artifact of us as an industry not being able to fully articulate the requirements.

Some of you may be shaking your heads, thinking, “No, this will put the project farther behind.” Nope, it won’t. Instead of the illusion of progress, you’ll see the real progress. Reviews of healthy code speeds up the project in my experience. Reviews of sick and tired code reveals the work still remaining.

The problem is you won’t catch up. But you won’t lose any more time — not without knowing you’re losing time.

Tweet This Post 

Last week we held the AYE conference. Attending bloggers (in random order) were: Ron Pihlgren, Esther Derby, James Bach, Don Gray, Steve Smith, Tim Bacon, Rachel Davies, Dave Hoover, Dave Pickett, and Dave Liebreich. I hope I didn’t forget anyone.

One of the highlights for me was the writing workshop. We practiced several timed writing exercises. Timed writing works because if you don’t have a lot of time, the evil editor sitting on your shoulder keeps quiet. Without the editor, your passion comes through. What you write may not be of final draft quality — but that doesn’t matter. You’ve found the passion and the energy, so when you review, edit, and rewrite, you’ve got a wonderful piece. I use timed writing as an exercise frequently in my writing. It’s one technique I use to get started when I’m feeling un-creative.

Tweet This Post 

Student Syndrome occurs when the person with the task waits until the last possible moment to start. Some people spend their entire academic career waiting until the night before a project is due and then starting it, pulling an all-nighter, and getting some (hopefully adequate) grade. Student Syndrome isn’t for me, but I know lots of people who do this.

I use these techniques to avoid Student Syndrome:

• Ask each person to develop inch-pebbles so that person (and the PM if necessary) can track progress.
• Use Estimation Quality Factor to continuously predict the end of their current task (not just the end of the project).
• Ask “What have you completed today?” Just asking can help jiggle people into starting the work.

These techniques work for me too, not just when I manage other people. Just because I don’t wait until the last possible moment doesn’t mean I don’t procrastinate every so often. (In English, that means I procrastinate too

Student Syndrome isn’t the same as being stuck, although if I’m stuck, it can look like I’m procrastinating instead of working on the task. I use a timeout to see if I’m stuck. For any given task, if I can’t make progress on it in about 30 minutes, I ask for help. 30 minutes may be too short or too long for your tasks, so adjust accordingly.

If you’re a PM or functional manager, notice if your staff are waiting until the last possible moment to start. If so, try something to help people start earlier. Late-as-possible starts lead to late projects.

---

The reason I thought of this today was because of voting. I hate waiting in line, so I vote in the middle of the day. Mark is an early bird, so he voted at 7:30 this morning. On an errand, someone told me she might not have time to vote. I asked “Can’t you take 20 minutes right now? There aren’t any lines. You could do it and come back to work later.” (She has the ability to do this.) She replied, “I’ll just wait until the end of the day.” Student Syndrome all over again. If you live in the USA, don’t delay. Go vote.

Tweet This Post 

My PM students are articulating insights about projects that I’m happy to see. One project team said this in their charter, “The value of the product is moving the paper successfully across the room. The value of the project is in the journey, not the destination.”

Some projects exist to see if the project team can proceed with a project — any project. For example, a Hudson Bay start, where you organize a project team to deliver something, to make sure everyone on the project understands how to do his or her part, is a project-within-a-project. (See here for some discussion on it.) The idea behind a Hudson Bay Start is that you move something through the entire project, from requirements through architecture and design, into implementation, test, and release. By trying everything on something small, the entire project team will see where they are more likely to run into trouble on big things.

Some projects exist to create some form of capability within the team. For the class, each team is learning how to set up and monitor projects — a new capability for some people. This project will be a success for each team if the teams learn how to set up projects for success — not if the team creates the deliverable.

Each project has a specific value to the organization. Sometime the value is in the deliverable. Sometimes the value is in increasing the capability of some or all of the people on the project team. Maybe the value is yet something else. No matter what, the effective and pragmatic project manager will define the value of this project early so that everyone understands it. When everyone has a common value project goal, everyone can focus their efforts on that value and no other value.

Tweet This Post