Managing Product Development

I’ve signed all the paperwork, so now it’s official. I will be offering a public project management workshop September 22-24, 2008 in Waltham, Massachusetts. The workshop syllabus is at Manage It! Pragmatic Project Management Workshop. Everyone receives a copy of Manage It! plus a workbook for your writing and working through the workshop.

Have questions? Email me. Want to register? Here’s the registration form. If you’ve been thinking about bringing project management training into your organization but want to try before you buy, this is an ideal way to try me out.

Since Esther and I started advertising our One-on-One workshop, I’ve been hearing wonderful stories about how managers and team members have benefited from one-on-one meetings. Here are some:

• A tester said he’d been ready to give notice when his manager started doing regular one-on-ones. WIth the advent of one-on-ones, his relationship with his manager changed. And, he started testing in a variety of ways–using techniques that helped him get a job on a project he enjoyed for a couple of years.
• A manager was “phoning it in” as he explained, not investing in himself or in his staff. He started doing one-on-ones and was re-energized.
• A developer who was doing well and had no complaints used one-on-ones to determine a career path with her manager so that she could do something new and the manager had a way to backfill her position.
• One manager who’s started using Scrum to manage his projects put starting one-on-ones in his timeline of important events at work. He’s found that he better understands what people are doing. They trust him more–and he trusts them more. He’s finding it a great complement to the iterative/incremental lifecycle.

One-on-ones work. If you want to practice doing them better, please join us in July. Here’s the One-on-One workshop link. If you want, call or email me.

A couple of weeks ago in Positive Results With One-on-Ones, I let you know Esther and I would be running public workshops soon. We are finally ready to announce the workshop.

July 10-12, 2006, in Minneapolis, we will hold the first Behind Closed Doors: Managing One-on-One workshop. Interested? Here’s the flyer (PDF). I’ll be adding a workshop page to my site later today. I’ll update this post when it’s done.

This is a workshop for managers, project managers, and technical leads. Here’s what we’ll be exploring and practicing in the workshop:

• How people really take in information and where things can go wrong, how to recognize when an interaction is off track, and what to do about it.
• How to actively listen to what someone else is saying.
• How to give–and receive–effective feedback.
• How and when to coach and mentor.
• What issues to address in career development and how to address them.
• How to build trust with each person in your group.
• How to have effective one-on-one meetings.

If you ever work with people in a managerial capacity (whether you’re called a manager or not :-), this workshop is for you. Email me if you have questions.

I teach a class called “Software Methodology” at The Gordon Institute. My goal is for the students to be able to recognize if a software project is not being managed properly, and to give them a feel for what a software project might be like. So, I have them organize themselves into teams and perform a software project.

I’m grading the final exams, and have encountered these programming techniques:

• Panic Programming: Writing code as quickly as you can because you realize the deadline is approaching and the project is far from done.
• Peer coding: (this is not a typo) When you and your peer learn to program together because neither of you know anything about code. One student said, “Different perspectives of the same problem lead to a much faster solution.”
• Pair party: Get everyone on the project in one room, give them short tasks, teach each pair enough to do the task. When a pair finishes a task, they check another pair’s task. Move around the pairs.
• Beer-and-projection-group-debugging: The night before the project is due, buy enough beer for everyone. Project the code on the wall. Program and debug together. Loop until project is done or beer runs out.

I wish I could say these programming techniques were new to me. But I’m pretty sure I’ve tried them all except for the one with beer. I can think of a project where the beer might have helped; sobriety didn’t

I’m excited that the students had a chance to feel what a software project is really like. I suspect they were more willing to try pairing in a variety of ways because most of them had little experience writing code.

Look at your project. Anyone using any of these techniques? Would they help or hurt?

A couple of weeks ago (yes, I know I’m behind :-), Scott Berkun asked in Teaching programming / management the Harvard way“Anyone have examples of CASE or situation based courses for managers, designers and programmers? Undergraduate or graduate?”

Yes, Scott, I do. When I teach program management and software methodology (at the graduate level at The Gordon Institute, I create projects that the students run and produce. And, Esther and I are developing our management offerings with activities and simulations.

It’s possible the case method approach that Harvard and other business schools are known for works. I certainly like discussing topics. And hindsight is 20/20. But for me, case studies are like hypothetical questions in an interview. Unless you structure the questions carefully, people are more likely to tell you what they think they would do, rather than how they would actually act.

I prefer practices in the form of practicing a skill with peer feedback, or simulations. I do add discussions in my workshops, because I do find that they provide a valuable airing of opinions. But I don’t believe people learn from the discussions. People learn from doing and debriefing what they did.

I’m not the only one who feels strongly about this. At the AYE Conference, all the hosts and guest speakers develop interactive sessions so that people have a chance to practice or explore something. The burden is on us as session leaders (and me as the teacher at The Gordon Institute) to create an environment in which people can learn. That’s not easy.

It’s possible that the case method works just as well for other people, but it doesn’t work well for me. I get all caught up in my head, and don’t realize that when I’m in the situation, I’m not acting the way I thought I would. That’s why I prefer activities where I have a chance to practice or simulations where I can explore a variety of tactics. Since I prefer learning that way, I teach that way. And, no, not everyone likes it. But the feedback I consistently receive is that people learn way more using practice with activities and simulations as long as we debrief them.

I don’t have the opportunity to teach at the undergraduate level, but when I teach my daughters things, we practice. If you teach (anything at any level), I encourage you to add practices and simulations to your teaching. The teaching is more fun and the students love it.

I’m in Albuquerque this week at a debriefing workshop. When I teach, I don’t just read PowerPoint slides. I do use handouts (and frequently PPT) to guide what I’m going to say. However, I add lots of stories, and use interactive activities to drive specific points home to the workshop participants. The way to extract learnings from the activities is to debrief the activities. And this week, fellow bloggers Esther, Dale, Don, Steve, and Dave are here as part of the workshop. (Jerry Weinberg is leading the workshop.) Us AYE hosts are here to improve our debriefing skills so that AYE is even better this year.

Yesterday, I learned something unexpected. I normally debrief my activities with words, either in small groups or as one group. But yesterday, one of the other participants suggested we draw our reactions to an activity.

I flunked drawing (and cutting) in kindergarten. That was over 40 years ago, but to this day, I don’t believe I can draw. (I know I know how to use scissors now So I never considered drawing as a way to debrief an activity.

But there are lots of people out there who find “expressing themselves on paper” (my new codeword for drawing) to be more effective than words for debriefing. And, since I’m the instructor for my classes, it behooves me to learn how to flex to those people’s preferences.

Many of the activities in my project management workshops are best debriefed with words. But not all. And I can imagine a number of activities in the management workshops Esther and I are planning that might use “expressions on paper” as first pass of debriefing.

The best thing about using experiential techniques when teaching is that the instructor learns something in every class. As an instructor, I can plan the interaction and how to debrief, but in almost every case, something unexpected happens. And the real learnings for everyone in the room arises from the unexpected happenings, which is why debriefing is such an important skill.

If you’re planning to take a class (any kind of class), make sure experiences are built into the class. Because the practice and debriefing of the practice will teach you much more than any prepared material ever could.

I’m at an experiential workshop this week, learning how to design simulations for my workshops and presentations. If you’ve attended one of my workshops or public tutorials in the past 2-3 years (at least), you’ve had a chance to participate in a simulation. If you haven’t yet, don’t worry. I don’t ask people to talk about their feelings — at least, not directly, and we don’t hug. So far, no one’s sung any songs, but who knows?

If you’re wondering, what’s the big deal about simulations, here it is:

Simulations allow the participants to practice new skills in a safe way, and to learn from their practice.

If you’ve ever tried to change how you perform some work, you know you need to practice. Practice without feedback can be worse than useless, because you can’t tell if you’re practicing correctly. Simulations, along with their debriefs allow for practice with feedback.

I’ve been at the workshop for one day, and I’ve already edited 2 simulations and developed 2 others. Good return for only 1 day, eh?

I’ll be blogging sporadically this week because of the workshop.