I get to see a lot of meeting behavior. A few rules I use for meetings: 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. Ask people to turn off phones, laptops, etc directly. If […]
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,
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
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.
Last Tuesday, I had a blast at Boston SPIN. I led a roundtable about transitioning to agile, and discovered that not everyone takes the feedback the timebox gives them. In this case, people weren’t finishing what they “attempted to commit to” in the timebox, but they extended the timebox. I suggested that was not such
Jurgen asked me to help publicize his survey. Ok, I’ve done it. Now, let me rant about explain why I think surveys like this are not useful, and may be harmful. A survey does not take your context into account. Surveys about any practices without considering the industry, the products, and the management don’t tell
I’ve been writing this post forever (for a month), and finally deleted that one and have started over again. We had over 1500 submissions, so the stage producers and review teams made the difficult decisions when they accepted about 20% for the program. (Difficult is not nearly descriptive enough. Complex, merciless, intricate, knotty are helpful
There’s a discussion on a mailing list about a partially committed-to project: there aren’t enough people on the project, the people don’t have the time to do the work because they are interrupted all the time by support of previously released applications. The only people available are part-time people who are not available when the
I’m trying to clean up the project portfolio management book for technical review, and I realized the other night (well, morning, when I woke up), that I’d missed explaining a key idea. We all work on several kinds of projects: Projects that maintain the organization, the kind we need to run. These projects “keep the
Jack has an intriguing post, The fun of productivity measures. He ponders how to measure knowledge workers. For software project teams, it’s easy: the number of running, tested features over time. The features have to be complete. No partial credit for partially done features. But what about for managers? That’s a little trickier. I like