Managing Product Development

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 maintain the AYE web site as part of my responsibilities this year for the conference. I post the news, the new articles, and do the general updating. Monday, I posted one of Don Gray’s articles, Shifting the Burden - Whose Monkey Is It? Except, Don and I had both made a mistake. Don had originally spelled Whose Monkey as ‘Who’s Monkey.’ Something looked off (!) to me, but I couldn’t figure out what it was. One of the people who attend the conference yearly reviews the site updating I do, and she told me about the Who’s and Whose. So I fixed the article title. Today, I received an email reminding me that the title wasn’t just in one place, it was in several places, and could I please update all of them?

After saying “duh” several times, and fixing the name, I realized what had happened. I had literally fixed the title of the article and that’s it. I had forgotten about all the referring places.

I didn’t mean to be stupid, or fix just one piece of the problem. But I was in a rush and didn’t take the time to ask myself, “Where else is this problem?”

If I’d been pairing, I doubt the other person would have let me forget. We would have had a good few seconds saying “Where else is this mentioned?” and fixed everything at once. But this is why I ask for peer review.

I find it impossible to see all of my own mistakes, even when I look for them. I’m sure you also find it difficult to find all of your mistakes. But other people who haven’t authored the work are much more likely to see my (and your) mistakes. So it’s ok if we have blinders on, as long as we make sure someone else reviews the work who can see what we’ve done.

I’ve been thinking a lot about impossible schedules. I’m talking about the project schedules that no matter how you organize the project, it’s not possible for this group of people to cram that set of features into this much time. At least, the developers don’t think so.

If people are up against impossible schedules, in my experience, they stop thinking. They cannot imagine a new technique or tool will help them. So even if their configuration management is in the pits, they will limp along instead of acquiring and using a new tool. And a change in technique is even worse. People who can’t imagine any way to success resist any ideas like iterations, implementing by feature, test-driven development, or even peer review of code. (This happens to testers too, it’s just that my examples here are for development.)

People aren’t stupid. When they’re up against an impossible schedule, they will hunker down and do what they can, so they won’t be fired. That’s all.

But with merely a difficult schedule, people will consider alternatives. They know that with alternatives they could make this into a not-so-difficult schedule, and they may be willing to take the chance on a different technique or tool — or even both.

So if you have an impossible schedule, don’t try to change anything. Or, change enough of the schedule that people have a little breathing room to try something new. But don’t expect people to try something new in an impossible schedule. The personal risk is too high. It’s much safer not to take a risk and miss the schedule than it is to take a risk with something new and miss the schedule.

So if you want your project staff to think, make a difficult schedule, and then set a personal challenge: “How can we make this schedule more reasonable?” In my experience, this is the kind of challenge many of us thrive on. But don’t set a stretch goal. That discourages thinking and will encourage people to throw out any good ideas that have not yet become good habits.

Frank sent me the music baton. I don’t do chain letters, but I thought this was cute. Sorry, Frank, I’m still going to relate it to work.The official stuff: Total volume of music on my computer: 1128 songs (or 3.2 days, 5.23 GB) The last CD I bought: I can’t remember if it was Saturday Night Fever (for workouts and dance practice) or 25 Bach Favorites for writing. Song playing right now: Neville Brothers, Voo Doo (from Louisiana Gumbo) Five songs I listen to a lot, or mean a lot to me: Mozart (I can’t pick just one) when I write, Albioni and Vivaldi when I write, Nigel Kennedy when I write, Van Morrison, Steely Dan for cleaning up my office. Sorry, I’m not following the directions to choose just one song. I don’t know how to do that :-)Five people I’m passively passing this on to: Esther, Dale, Don, Alan Francis, and Clarke Ching. Now, to why I titled this post about muse. I’m one of those people who’s frequently humming. When I work out, I sing while working out (I can only do that at home, not when I travel. Even I know that!). I learned early that if I wanted to write, I needed to listen to music with no words. Otherwise, I would write down the words to the song while I was thinking. So I write almost exclusively to instrumental music, primarily classical. (I started this post while listening to task music, and switched when I realized I wasn’t writing well.)For tasks such as cleaning up my office or getting organized for the next day, I use rock and roll of some variety. I need something that makes me want to get up and move around.I find that my choice of music absolutely affects what I can and cannot successfully do. If you haven’t tried classical music yet for writing, whether it’s a natural language or code, I highly recommend it. My favorites are violin concertos.

In Who Wants to be a Technical Lead? I promised I’d talk about succession planning.

Here’s the general idea: as someone who works for a living, your job should be to work yourself out of your current job by learning, practicing, and mastering some new skills. The less work experience you have, the easier this is to do. With more experience, it’s possible you have fewer — or more likely different — areas of interest, and you’re already on your way or have mastered several areas of interest. As you work yourself out of your current job, you work yourself into a new job.

As a manager, you may need to be more purposeful in planning who will take over your role or pieces of your role so you can do the next great thing. That means you have to know what you’re doing. One of the suggestions I make to managers is to write down everything they do in a week or two. That includes dealing with the people issues. If you have an employee who’s indispensable, it’s time to have that employee drop that area (ok, transition out of it in a week or two if necessary) and learn something new. If you have an employee who’s never been challenged to try something new, it’s time.

Not everyone will enjoy the opportunity to learn something new. Some people will reject all of your attempts to have them try something new. Then it’s time to ask yourself if these people are truly contributing what you need contributed to the organization. Successful managers are successful because they deliver results while improving capacity. If people on your staff refuse to improve their capacity, maybe they don’t belong in your group. Similarly, if you have someone who refuses to be anything other than indispensable (because he or she won’t learn something new), read Ready, Aim, Fire!

If you’re a new manager, the way Rich is, consider this possibility. You’ve reorganized the group, you may as well reorganize the work. You could ask for volunteers to lead specific areas. You could ask people to work in a more agile, self-organized team way. You could ask for other options to change the way you’re working, because the one thing you know is things aren’t working well enough now.

If you aren’t in transition, start using your one-on-ones to talk with people and see where they’re headed. If you’re not considering who could take over from you sometime, you’ll never be able to move out of this job. You’ll always be too valuable where you are.

The most effective employees (although not always the easiest to manage) are the people who are constantly learning. They don’t have the same year of experience several times; they have years of experience, mastering different parts of their jobs. The most effective managers hire people who are willing to and are successful at learning new things. It’s easier to plan for succession (whether this is management succession or technical contributor succession) when you can see people practicing new and different skills.

So, how will you work yourself out of your current job, into a better one?

I’m looking for a reference to something I thought I read but can no longer find.

Technical people can work up to 6 hours a day on technical work.

They may be at work longer, reading email, going to meetings, getting coffee, but they can only effectively do 6 hours of technical work a day. (Yes, for short periods of up to a couple of weeks, people may be able to do more. But once they get tired or they’re not taking care of their personal lives, they can put in as much time as you want, but you won’t get nay more out of them.)

in case you’re wondering, I’ve measured this (number of technical hours of work per day) on some of the assessments I conduct. In several cases, people were only accomplishing about 4 hours of work per day (too many meetings). At the most productive places, the average was just under 6 hours per day.

Let me know if you have a source for this.

Later… I was catching up on blogs and found Ole Eichorn’s Tyranny of Email. In the essay, he talks about working in three-hour chunks. On page 15, he explains:

Here’s another reason for three: it kinds of “fits” into a workday. For example, you get in at 8:30, check email, pick up voicemail, do all that. Then you shut everything off and work for three hours, ’til say 12:30. Now you break for lunch. You get back at 1:30, check email, pick up voicemail, do all that. Then you shut everything off and work for another three hours, ’till say 5:00. Then you check email, pick up voicemail, play foosball, run around and bug everyone, etc. You’ve had two nice periods of time to get work done.

I’m a Tour de France addict. I bicycle like those guys only in my dreams. But when I was watching the race last night, I realized something: the riders who are in a position to win the Tour are adaptable riders. They don’t excel at just sprinting, or just mountains, or just rolling-hills, or just endurance. They have enough endurance and skill in all of the riding conditions to stay competitive every day. They adapt their knowledge of the road, their practice in each type of riding, and their preferences for each type of riding to the current moment’s conditions.

So what the heck does this have to do with development? If you’re staffing a project, make sure you have enough people who are adaptable to several types of work. Maybe that means you need an architect who can also mow down defects. Maybe that means you use people who can pair with anyone else at any time. Maybe that means you have testers who can also design test architectures. It definitely means that as a project manager, you need more than one approach to project management.

The riskier the project, the more adaptable the people need to be. That way the project team can work itself out of any problems that arise. I’ll be avidly watching the Tour to watch the cycling and to see what problems arise and what the teams and individual cyclists solve them.

If you haven’t read the comments starting from here from the previous posts, please do. Effern blew the whistle — so very nicely — when he perceived I hadn’t considered enough options.

It’s possible I didn’t consider enough options:-) (Maybe I didn’t develop three or more worthy alternatives.) What Effern did, oh so graciously, was to point out what he perceived as a flaw in my thinking, in a way I could hear it. I received the feedback, and although I’m not sure what else to suggest in that post, I’m still thinking. Which is a wonderful reaction to have. Thank you Effern for your tweet.

Adam, your tweet was also eye-opening. “Making clients earn proposals.” What a great way to discuss the two-way street that has to exist for a successful relationship.

Thank you Effern and Adam for your tweets.

The only good thing about this current spate of worms and viruses is that the spammers seem to sending less spam. Naively, a few months ago, I bemoaned the state of automated spam filters. Now I wish my mail program (Eudora) and spam filter (SpamSieve) could detect these ridiculous pif files and delete all mail with a pif attachment.

I’ve come to the conclusion that we buy our tools for emotional reasons, not logical reasons. Why else would so many companies and individuals buy an operating system with easily-exploited security holes? It can’t be for logic. Logic dictates that the second or third (or fourth or fifth or…) time the OS was exploited people would move to a new OS. But they haven’t. (Yes, there are options.)

I’m not out to convert everyone to buying my kind of computer (Mac) or OS. We live in a heterogeneous-OS world, and that’s to everyone’s benefit. If I could, I’d make everyone buy anti-virus software when they buy a computer. If I could, I’d make anti-virus software a part of Windows, so it wasn’t an option. It affects me (and huge number of other people) when other people don’t take care of their environments.

When we choose to own computers and connect those computers to the network, we need to take responsibility for our environments. In my town, we’re not allowed to burn leaves in the fall, because of pollution. When we connect computers to the Internet and don’t install the latest security patches and anti-virus software, we’re polluting the Internet. I don’t know what the right consequences are, but allowing people to be naive is no longer acceptable. Allowing companies to ship security-holed software is not acceptable. Allowing the worm-generators or virus-generators to get off with a slap on the wrist is no longer acceptable.

I don’t care what tools you choose to use. Multiple environments create richer environments for each of us. I care when your choices make my tools difficult to use or prevent me from performing my work. Choosing tools is a personal choice. And my obligation when I choose my tools is to act in an environmental-friendly manner. You too.

Via Steve Norrie’s weblog, I found Kovitz’s “Hidden Skills that Support Phased and Agile Requirements Engineering”. In phased development, projects promise large feature sets to a customer for future delivery. In agile projects, the requirements are refined over numerous little conversations with the customer, day in, day out. Kovitz claims the skills required for agile projects are different than the skills required for phased development projects.Kovitz is correct. The skills are not mutually exclusive, and they are different. Here’s my take on those skills:

• Large chunk thinking (top down) vs. Small chunk thinking (bottom up): In phased projects, we’re used to break requirements into large chunks. We work on continuing to break down the large chunks (top-down requirements, design, implementation) into month-long or even a week-long chunk. Instead, in agile projects, you start with the smallest possible thing you can imagine. It should take a few minutes to implement. This is a huge stumbling block for many developers. The smallest thing they can imagine is weeks of work. Instead, it should be minutes of work. (okay, so maybe it’s 40 minutes of work, but it’s *way* less than a week)
• No code ownership. In phased projects, a developer or several developers own modules. Each developer works as an individual. Each developer is responsible for his or her code. On the other hand, in agile projects, there is no such thing as code ownership. You work with other people, either as pairs, or choosing to refactor whenever and wherever necessary. If you’ve never pair-programmed, I highly recommend trying. It’s completely different from developing alone. I found it energizing and all-consuming. I was tired at the end of the day.
• Write tests first. In phased projects, developers prototype and discuss prototypes with others (hopefully). In agile projects, developers write tests first, to see “What would have to be true for this piece of functionality to exist?” Too many developers don’t know how to test. (Too many testers don’t know how to develop, but that’s fodder for another blog entry.)
• Conversation is expected. I’ve worked on phased projects where some people never talked to anyone else in real-time. They emailed, but they didn’t speak. That’s not possible in agile projects. If nothing else, the daily 15-minute standup meeting requires everyone say something. And, when you start building bottom-up, not top-down, you have more opportunity for conversations about how things could work.

Kovitz goes on to say that phased development requires representation of the system and excellent writing skills so that you can discuss what the product should look like and how it should work. And, the project needs to be able to negotiate deliverables, the customer needs to prioritize their needs, all things that are difficult to do.Does that mean we should never used phased delivery lifecycles? No. But it does mean that right now, many of us don’t have the skills to successfully complete phased delivery projects, nor agile projects. It’s time to learn more skills.