It’s worth taking a quick listen to Commentary – Overtime’s not good for your health. The folks from University of Arkansas actually have data that says overtime is ok and doesn’t reduce productivity. Hah! I wonder where their data came from. On the other hand, Joe Robinson’s commentary makes perfect sense to me. Here are […]
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
From the “I wish I’d said that” list: Via Frank Patrick’s blog, Mike Cohn, in his User Stories Applied for Agile Software Development. Chapter 10, Why Plans Go Wrong in pdf, explains buffers and padding and scheduling: “A Buffer Isn’t Padding — A buffer isn’t padding. Padding is extra time added to a schedule that
My Stickyminds column this month deals with choosing when to start and end project overtime, “When Should You Start Project Overtime?” Frank Patrick has already chimed in with one of the common causes of overtime, multi-tasking. See Multi-tasking Multiplies Lead Time Also see these blog entries from Esther Derby and Hal Macomber. A note: I
One of the most difficult problems in software development is knowing how to elicit and discuss requirements. It’s difficult because the people who are supposed to know the requirements don’t always have a clear idea of what they want. And, even people with tremendous communication and other soft skills don’t always have good ways
Esther’s blog entry this morning set me off into gales of laughter. I’m sure I was the original author of the peanut butter/white bread entry, and with editing, Esther turned it from mud to something that’s ready to be edited. A great case of refactoring in writing. Now that I write for human consumption,
I had a lovely dinner with Brian Marick and our spouses Saturday night. (Now that he’s blogrolled me, I can’t tease him about that. Thanks, Brian!) Two things made me reconsider the way I manage people while managing a project: things we discussed at dinner, and Brian’s recent posting about the explicit role of the
As you can probably tell, I think people are the most important equation in successful product development. Good people can trump inadequate management and/or an inappropriate process. Dorset House has announced the pre-publication price for my book (available in September). I wrote a little more about this on my Hiring Technical People blog.
Last night at dinner, a friend said, “They love us. We’re only 4.8 FTEs, and (the rest of the organization) thinks we do the work of 6 people.” Guess what? There are 6 people. Not all of them work full time, which is why there are only 4.8 FTE (full time equivalents) for the
In a question to yesterday’s post, Bill asked about the effect of multiple ideas for problem solving: “Do readers feel they have to follow one of your multiple True Ways now? Or does the multiplicity meta-message encourage them to generate even more ideas?” Sometimes and Yes. Some people are even more impatient than I