Managing Product Development

I’ve been teaching workshops for much of the past few weeks, and I’ve noticed an interesting pattern. I get great comments (and usually good numbers) from people who participate in the workshop. I don’t get many comments, and I get substantially lower numerical grades from people who leave their laptops open during the workshop.

These people are convinced they must pay attention to their work issues while they are in the workshop. And, they are the same people who want the “cheat sheet” or the “10-second overview of user stories” (true!). They are the ones who don’t participate in the debriefs for the experiential activities. They are the people who don’t see the value of instructor-facilitated and experiential training.

I’ve started a new introduction to my workshops. I say something like this: “I know that you are an adult. I trust you to make the right decision about your laptop open or closed. I will warn you that it is impossible to fully participate in this workshop with your laptop open.” (I smile as I say this.) “You have the choice to leave your laptop open or participate in the workshop. If you choose to leave your laptop open, please don’t prevent the other people at your table from working through the activities.” I stop then and start with the workshop.

I have mixed results. The people who believe me at the beginning learn a lot in my workshops. The people who realize I was serious later on in the workshop and finally   put away their laptops learn too, and it depends on when they put away their laptops. I can’t tell about the people who don’t put away their laptops. From the way they debrief the workshop, I don’t think they learn much.

I sort-of understand why conference-workshops are like this. Few people expect experiential activities at a conference workshop. (Ha! Gotcha!) Many of them have never encountered interactive and experiential training before. And, too many of them are expected (so they say) to check in at work while they are at the conference.

I don’t understand why a company brings me in and expects their employees to be on their laptops all the time while they are supposed to be at training. People really cannot do two things at once and do each of them well. They can do one thing well and the other not at all. They can do both things poorly. But they can’t learn and work at the same time.

I do ask people in in-house workshops how often they need to check email and check in back with their teams. I try to have enough breaks and a long-enough lunch to take that into account. But it’s quite difficult if the answer is “I have to be on email all the time.” I can’t teach and accommodate that request.

If you are attending a workshop, please participate. If you are working, go ahead! But, please, don’t try to do both at one time. It just doesn’t work.

Remember, the AYE conference is all experiential and interactive sessions. We would love to have you. And, we give you long-enough breaks between sessions so you can email or phone back to work. You’ll learn to work better. Isn’t that the whole point of workshops?

Tweet This Post 

I have a new article posted on ganthead.com: Point Play. You can comment there. I think you have to have a (free) registration to post a comment.

Tweet This Post 

I’m now the proud and happy owner of a new reservoir for our tankless hot water heater. (Tankless is a relative term, when it comes to hot water heaters.) A week ago, the reservoir part of our system finally broke. We had a new reservoir installed on Wednesday, and our lives have changed for the better. We have much more and much hotter water than we had in the past 9 years.

Looking back, I can see the graceful degradation of the hot water heater. First, a few years ago, we had slightly cooler water and we had to keep the temperature higher to maintain enough hot water. We actually ran out of hot water this past winter (but we thought Teenage Daughter Showers were responsible). Then came the drips. We’ve had trouble with the pressure relief valves for the past couple of years, but the plumber has been out monthly since January to fix the drips. When the reservoir finally went, it was not a drip, it was a full-fledged flood!

Our system degraded gracefully, but as with many complex systems, we couldn’t tell it was degrading. It would have been better if it had failed. At least then, we would have spent much less time and aggravation on the current system.

That happens in software all the time, too. We want  graceful degradation, but I maintain we need quick failure. Quick failure helps us see where the system works and doesn’t work and tells us where to look for problems.

Tweet This Post 

Seth Godin has a great entry, Saying ‘no’.

No is the essence of project portfolio management, no matter who you are. If you don’t say No, your yes’s don’t mean anything.

As Seth says,

Saying no to loud people gives you the resources to say yes to important opportunities.

Tweet This Post 

I’m in some variety of “final” editing on Manage Your Project Portfolio. I’ve reorganized the first chapter into two chapters, rewritten a bunch of things, added a new zero-sum game, and have managed to tighten up some of the writing. I’ve received great feedback from Esther, Don, and Dwayne that I’m still incorporating into my edits.

For me, the challenge in writing a book is to write it all down. I need to make sure I show why and how, and not forget the things I do that are so obvious to me but may not be to my reader. Once the book is ready for review, my initial editing challenge is to find ways to show the problems and solutions. But where I am now–close to final editing–my challenge is to not write any more words. Yes, I may have to write more words somewhere, but I have to manage the overall word count, or the book will not fit for its intended audience.

Jerry, in his writing workshops, and in Weinberg on Writing: The Fieldstone Method, taught me to cut by a third: cut a third of the words in a sentence, a third of the words in a paragraph, a third of the paragraphs, a third of the pages. I haven’t had to cut a third of the chapters–yet

At the beginning of writing any piece, I allow and encourage expansion. Starting in the middle, after some initial review and towards the end, I work at trimming. (Sort of like life, right?) This looks a lot the way I used to write code too. I’m still writing when I edit, but my mindset is a little different.

For those of you who want to know when the book will be done: it depends on how much editing I finish this week, which also depends on when the hot water heater is fixed. Let’s hope the plumbers get here soon. Life is a little too challenging with no heat or hot water. I may have that story later this week.

Tweet This Post 

I’m in what might be close-to-final editing on Manage Your Project Portfolio. Not everyone understands all my references for things. For example, one of my reviewers did not know what a backlog is. Since I hope that managers of every level will read this book, it’s entirely possible they may not all know what a backlog is either. (Please don’t sneer at middle or senior managers who don’t know what a backlog is. They’ve used something like it, but if they are new to agile or new to project portfolio management, they may not have heard the word before.)

If you wanted to know the meaining of a word, would you prefer to see it as part of a glossary, or as part of an index? The index is easy. The glossary is not hard to include, either, it’s just a little more work. I want to do what my readers want to read. Please comment. Thank you.

Tweet This Post 

I get to see a lot of meeting behavior. A few rules I use for meetings:

1. End the meeting at 5 minutes before the hour. Most people have another meeting starting on the hour, and this gives them a shot at transportation and bio-break time.
2. Ask people to turn off phones, laptops, etc directly. If I’m teaching a workshop, I cannot know if the person doing email or texting is making the right decision. I don’t bother to ask. I have asked people to move out of the way if their equipment is in the way of the people working on the simulations. If you are in a meeting and someone else’s behavior is bugging you, talk to that person directly.
3. Keep a parking lot of issues to get back to, and get back to them.
4. Track ongoing action items. Especially if you’re dealing with managers who have too many context switches to enumerate, make it easy for them to see all their action items in one place.

I have a few other rants on other workplace etiquette, such as cell phone conversations in the bathroom (Please, put the phone down. Shut it. Don’t forget to wash your hands when you’re done. Ugh).

Many of my rules arise from the idea that just because you can, doesn’t mean you should.

Tweet This Post 

I taught my estimation workshop twice last week and once the week before, and one thing remains true: Estimation depends on the project lifecycle, how the project is organized, the state of the requirements, and the number of people you have available.

I used a number of simulations to help people see how to estimate, and I noticed a number of interesting effects:

• In the public workshops, people were more willing to experiment and live with a different lifecycle for a simulation (a more concurrent lifecycle, or an iterative or incremental approach)
• In the on-site workshops, the participants recreated their environment, even when they said they wanted to try something new. Goes to show you how difficult it is to change.
• Relative sizing is a great way to account for the difference in capabilities when you don’t have specialists or people with subject matter expertise. (”A 2 for this group is more time than a 2 if we had a so-and-so.”)

I encouraged people to try incremental and agile approaches to their projects in the workshop. The participants agreed that the approaches provided faster results, and still were concerned that they would not be able to implement those approaches at work. Some of the people were so accustomed to not having enough people, that even when I asked, “How many people for how long?” they could only assume they had access to the other one or two people in their small groups, even though we had 20 people in the room.

Yes, we encountered Parkinson’s Law (work expands to fill the time allotted), which is why I timeboxed the estimation time. “But we need more time for estimation!” “Do you get that time from your managers?” “No.” “So, maybe you can try some other approaches to make your estimates better in a shorter period of time?”

We discovered that non-functional requirements are more difficult to estimate than user stories or even use cases. And, it still amazed me that people are given broad brush requirements, and are then supposed to generate an accurate estimate (within 10%) with such little data. Yes, we talked about ways to iterate on your estimate to refine it. Will their managers listen? I don’t know.

We even had an opportunity to test out my claim: Multitasking nullifies all estimates. It never fails, when I teach an on-site workshop, some people think their work is more important than the workshop. Maybe it is. But I do know that when they leave and arrive and leave and arrive, it mimics what they do at work, and slows down their project. Because I break everyone into parallel groups, when they return, they can see the effect of their in-and-out behavior on their project.

When you estimate, make sure you think about how the project is organized, how many people you need when, and what information the requirements provide. Then show a confidence graph or a three-point estimate to explain how the estimate is really a guess, but a good guess, not a swag.

Tweet This Post 

I’ve discussed this situation with several managers recently. The manager says, “I have a wonderful developer, who can code circles around everyone else. If he doesn’t like someone else’s code, he rewrites it over the weekend. If he sees a hole, he writes a ton of code over the weekend He starts work early and works late. But, I have a tiny little problem. I can’t keep people who might be just as good. I can keep people who are not as talented, but can’t retain people who are not quite as good. But that’s ok, isn’t it? After all, don’t I have the most productive employee?”

Let’s review what productive means for software. It means the most number of features per unit time per team. Personal productivity is meaningless. Keeping everyone busy is meaningless. But having one employee who is a bottleneck, or one employee who prevents a team from increasing their overall capacity (running tested features per unit time), that’s a problem.

One manager who had this problem has a bottleneck employee, one who prevents other people from doing their work, by interrupting others from finishing their work. (See Retrain Your Code Czar for an article I wrote about this a number of years ago.) Bottleneck employees are frustrating to the rest of the team and prevent everyone from accomplishing work–except the work they want to accomplish.

Another manager has the problem of one person bringing down the expertise of the entire group by being an indispensable employee. Indispensable employees prevent other people from learning because they take care of things for other people. Other smart people don’t want to work with the indispensable employee because they don’t get the challenge of solving the problem themselves.  Indispensable employees are quite dangerous to the longterm health and success of your group.

If you are faced with one really productive employee and some not-so-hot folks, reexamine your situation. Do you have a bottleneck or an indispensable employee? If so, fix the situation. They are not helping you.

Tweet This Post 

Remember Why Projects Don’t Need Specialists? Well, I decided I had a little more to say. I decided to write an article, What’s So Special About Specialists? Please do comment there or here.

Tweet This Post