I love it when my readers challenge what I’m saying, as in Plunge In or Dip Your Toe? (for Projects). I do believe in small steps for projects. I’ve long been an advocate of inch-pebbles, of standup meetings, of iterations and incremental development. I love knowing what done means, for the project and for features […]
For years, many project and functional managers have believed they need the “exact right person” in each role on a project. Those exact right people are specialists, and some of them have quite narrow specialties. Here’s the story of one specialist and her impact on several projects. Two project managers needed the same person, a
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
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
I’m editing the project portfolio book. Yes, I’m trying to get ready for beta. No, I have no idea when I will be ready. I’ll have more information before Wednesday, if you want to know. I realized that when managers don’t make ranking decisions about the project portfolio, when they don’t fully commit to a
I gave a talk last night at the Software Quality Group of New England about schedule games. During the talk, I explained how serial lifecycles don’t manage technical, schedule, or cost risk. Serial lifecycles actually increase the duration of the project. And, serial lifecycles don’t offer feedback early enough for the project team. (They only
I spoke with a program manager who’d been displaced from his program because he doesn’t scream or yell at people. (No, I’m not making this up. This is true.) He’s an effective program manager, because he doesn’t tell people to do this or that task. Instead, he tells them the goal and the results he’s
I was reading Ralph’s post, Whose Fault Is It?, and I realized that if you don’t know enough about management, you can misunderstand the root cause. Ralph’s example is of defects in an iteration and how they were not detected early enough because the acceptance criteria were missing. The criteria were missing because the testers
I spoke recently with a (new) Scrum Master with a team who’s new to Scrum. One of the team members is a little stuck. He doesn’t feel comfortable going to the task board to take a task when he’s done. He wants to wait until someone else is ready and then work with that person.
I don’t normally pay much attention to these kinds of things, but what the heck, this will give Jurgen a link back. Jurgen has collated the Top 100 Blogs for Development Managers (Q3 2008). I have no idea if he will continue to do this quarter after quarter (!). I’m glad that other people find