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
This past weekend, my husband insisted we clean up the basement, and go through a bunch of old boxes. I discovered performance evaluations, memos, status reports, and some project plans dating back from when I started working until I started my business. I discovered a major pattern about my approach to work: Since I’ve never
Some of you are probably trying to plan your vacation around the project you’re on. Good luck. Every time I did that, the project was in some crucial place and my bosses asked me to consider changing my vacation. Don’t give in to their pleading. If the project is in good shape, you being