Managing Product Development

From time to time, I refer to AYE. It’s a conference several other consultants and I created back in 2000. We were tired of feeling forced into short sessions where it was too hard to convey how our topics felt to people. (There’s just so much you can do with PowerPoint.)

At AYE, all the sessions are experiential or at the least, interactive. I experiment with new simulations and experiences there. Because we limit the conference attendance to 99 people, even if I screw up a simulation, there aren’t so many people in a session that I can’t somehow make it right.

I’m leading 5 sessions this year:

• The Savvy Project Manager:Dealing with Multitasking (changed simulation from last year)
• Writing Workshop with Naomi Karten
• Management Behind Closed Doors with Esther
• Transforming Rules into Guides with Jerry
• Reinventing Yourself

The early-bird discount deadline is April 30. For $1200 (only through April 30) you can participate in everything the conference has to offer. I hope you join us. For more information, take a look at the wiki and the registration page. Even if you choose to not join us yet, I hope you join our low-volume, private email list.

Labels: AYE conference

I’m finally back home after 4 weeks on the road. Yes, I was completely nuts to spend 4 weeks away. My office is a disaster, and so is my email. (My domain name is being spoofed, so I’m getting thousands of returned failed email messages a day. Pain in the tush to process.) So, here’s my trip report from AYE 2006.

Normally, I lead 5 sessions out of 6 session slots. This year, because Jerry was recuperating and unable to be there, I led 6 sessions. I’m thinking of limiting myself to just 4 sessions in the future. We’ll see

Monday morning, I led a session about Multitasking. The multitasking simulation went well, although I’m planning to get different puzzles to make the work different for each group. I then added too much stuff to the session, to deal with multi-tasking. I’m going to have to focus the next piece better next year. This simulation is different from the one in my PM workshop. I think this one is better.

Monday afternoon, Esther and I led a Behind Closed Doors session. I was pleased with this one. We even got a nice writeup on cio.com. Esther and I have been refining the simulations and activities for a couple of years now and our practice shows.

Tuesday morning, I facilitated Reinventing Yourself. This session is about recognizing the patterns we have in our (work) lives, and choosing whether to continue those patterns. Last year, I had about 40 people in the session. This year I had about 10. Because of smaller group, I was able to abandon my session design partway through the session and kept moving with the energy in the room. (One of the reasons I keep my workshops small is so I can see where the energy is and move with it.) I’m still hearing nice things about this session, so I’m happy with it.

Tuesday afternoon, Naomi Karten and I led a Presentation session. Naomi’s been a professional speaker for many years, and suggested I also join National Speaker’s Association. I’ve been a member for about 10 years, and have found it valuable. Several of the participants started the session concerned and ill-at-ease speaking in front of groups. By the end, they seem to have learned some ideas and tips to help.

Wednesday morning, Naomi and I led a writing workshop. I love facilitating this session. You can see some of the results here. I’m planning to post my rough draft about multi-tasking there, and refine it here, and then further refine it for the PM book.

Wednesday afternoon, I led Transforming Rules into Guides originally one of Jerry’s sessions. We all have survival rules. Looking both ways before you cross the street is a very handy survival rule. But some of our rules, especially about our conduct with other people or what we can say to other people can be quite limiting. We may need to choose whether we keep these rules as is or transform them into guides, so we can choose whether to follow them. We were able to transform two rules in the session–quite an accomplishment. (I was the facilitator; the people in the session do all the work.)

I’m finally back, working on the PM book and catching up on my email. Hope you had a delightful 4 weeks

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.

I’ve just returned from the last of my spring conferences. And, I’m struck again by how much training is available to people at conferences and how cheap it is. You may be shaking your head, saying, NO JR, Conferences are expensive, about $5000 per person for the week, once you factor in travel along with the conference fee. How can you say they’re cheap??

The value of a conference is partially in the tutorials, partially in the sessions, and partially in the networking you do with other attendees. Here’s a way to qualitatively measure value of a conference, assuming you attend for 5 days, taking 2 tutorials, and 2.5 days of sessions:

Days 1 and 2: Participate in a tutorial from 9-5. Take away three things from each tutorial you can apply next week. Network with and meet 3 other people (in each tutorial) in similar circumstances to you. Days 3, 4, 5: Attend sessions, some in your area of expertise, some not. Attend one session with interactivity of some sort. Meet 3 new people each day. Take away 3 ideas each day. At the end of the week, you have 15 new ideas, and 15 new people in your network. If you just stopped there, you’d have received plenty of value for your money. It will take you months to try each of the 15 ideas and see how to adapt them to your environment. If you also continue to correspond with your 15 new colleagues, using them for support, mentoring, and coaching (which goes both ways), you’ll received peer consulting of tremendous value. I don’t know how to quantitatively measure this, but it seems to me that 15 new ideas and 15 new colleagues can help you make at least some progress on what appear to be your intractable problems. If you can even partially solve one problem, you’ve regained the cost of the conference.

But you can use conferences in other ways too. You can meet experts in your field, learn what you can from them, and continue to contact them throughout the year for quick feedback. At the conferences, the speakers and famous experts meet with people at mealtimes formally and informally, through BOFs or Open Space or other informal discussions. I had an Open Space session last week that only had 3 people (one of which was Esther, so the participants got to hear from two of us how to identify appropriate skills and questions (and write ads) for bringing people into an agile team and into a highly technical test team. One-on-one consulting for 2 hours — included in the price of the conference. That’s unbelievably cheap.

Conferences re-energize people. Conferences with highly participatory sessions, such as the AYE conference help you learn by practicing while you confer. But as long as there is space in the conference to discuss issues with new-found colleagues and speakers, you have the opportunity to learn at a conference.

Don’t dismiss conferences as a waste of time or a boondogle. Speakers (whether they are consultants or not) use conferences to articulate techniques to solving problems. They may even be able to help you adapt their solution to your problem.

So try a conference this year. Local one-day conferences are extremely cheap (a few hundred dollars at most). If you do attend one, make sure you know how to contact the speakers, so you can follow up with questions later. If you want more than one day, but you’re not sure about an entire week, try a shorter conference, or go for just part of the week. Wherever possible, choose interactive and experiential sessions because you’ll learn more by discussing the problem with your peers and practicing solutions than just by thinking about or listening to how someone else solved the problem.

Last week at the AYE conference, Naomi Karten and I facilitated a writing workshop. We ask people to write for five minutes and then for ten minutes. We find that people who are stuck on their writing make significant progress in five or ten minutes. However, we need to set our expectations low — very low — for a zeroth draft. We each took the challenge of writing on a subject of the attendees’ choice. I took on the “The Role of Footwear in Software Development.”

Here’s my zeroth draft on “The Role of Footwear in Software Development”

Earth shoes. Running shoes. Sandals. Hiking boots. Software developers wear all kinds of footwear, and all footwear has a common role.

Footwear for software people serves one simple purpose: to disguise the owners’ foot odor. You’d think that software people — people with desk jobs — wouldn’t necessarily smell. However in a surprising number of cases, they do.

Some software people forget to bathe. You might ask, “How could people who put a man on the moon, or create a clearinghouse for the Federal Reserve or manage your health insurance program have such a difficult time with such a basic skill?”

The answer is simple. Bathing is not an intellectually challenging task. Bathing is simple. Bathing is something you have to at home — not at work — so you have to be home to do it. Given the state of many software organizations, too many people aren’t home enough — at least — not long enough to bathe.

That was the end of my five-minute timed writing. As you can see, it took me a long time to figure out where I was going:

• that software people may not rank intellectually simple tasks at the same priority as intellectually challenging tasks, even though the “simple” tasks are just as necessary
• that the state of the project may create a situation where people can’t perform the most simple of tasks
• smelling your project is an indication that something might be wrong on your project.

The subsequent draft, the 10-minute timed writing, was nowhere near as funny, but started to link in the idea of code smells.

If you’re writing and having trouble, try timed writing. I find it a useful technique to extract that useful nugget so I can start writing the real work.

And, I now have a partial draft of an article that may be useful to project managers. When I finish it, I’ll let you know.

Ron, Laurent, Dale, Willem, Esther and I are all together at AYE - we’re having a blogging BOF.

We discussed things that stood out for us at the AYE conference: facilitating a panel, the presentation workshop, working with Jean McLendon, how difficult electronic room keys are to keep track of…

Laurent: thanks to Johanna for providing a laptop and dial-up connection ! I’ve attended two sessions so far - one on “Conscious choices for change”, one led by Jean McLendon on Satir system coaching… but what has been nagging at me in the background is how annoying these electronic card keys are. It takes a few seconds to open a door with a regular key - with the electronic equivalent it takes three tries and five minutes, because you have to fit the card into the slot just so and I haven’t gotten good at that yet. Why adopt a new system that’s worse than the one we had before ? That’s another topic that was covered at AYE - “What does it take to really improve things around here ?”

Esther Derby here, really much to tired to blog.

[ronpih] What stood out for me today was the afternoon session I attended on doing presentations. The presenters were Johanna and Naomi Karten. I myself wimped out and didn’t deliver the presentation that I prepared but I learned a lot about doing presentations from the folks that did deliver their presentations.

I’m also a little bummed that I didn’t set up the computer I brought to be able to write to my own blog but I’ll be taking notes and posting once I get home

I’m at the AYE conference this week, and a bunch of fellow bloggers are here: Laurent Bossavit, Esther Derby, Steve Smith, Ron Pihlgren, Willem van den Ende, Dale Emery. I hope I haven’t forgotten anyone.

Laurent suggested a blogging BOF (Birds of a Feather), so if we’re not too exhausted, we’ll sit around one of our laptops and blog. Maybe even pair-blog. Ooh, that would be fun!

Since it’s another conference week, don’t expect much output even if we blog together…

It’s fall conference season, and I’ve been quiet because of the travel and final preparations for sessions. One of my sessions at the AYE conference is called Predicting Project Completion.

I decided it was time to explore how to predict the end of a project when I encountered two clients this year. One made a practice of yelling at the managers and project members, demanding they complete the projects when he wanted them completed. Big surprise, that was ineffective The other client uses a more agile approach, dividing each project into month-long deliverables. This client doesn’t need to yell to “make” people complete the project on time. However, the client still wants higher output. Which is a different problem. I’ll try to address that tomorrow.

From my handout, here are the three things I think are critical to being able to predict project completion:

1. Estimating what you have to do. Do you know what you want to accomplish and how well can you estimate that?
2. Measuring along the way. What quantitative and qualitative measurements can you take during the project to refine your prediction?
3. Knowing what done means. If you know how good the product has to be and how much content the product requires, you can know what done means. Otherwise you’re never done.

If you have other ideas about what is necessary for predicting project completion, let me know. I’ve devised several simulations to explore this. We’ll have fun!