Esther and I are offering another public workshop, Managing One-on-One April 23-25, 2007, in Minneapolis. Here’s the flyerwith the details. Questions? Email or call me. Labels: Behind Closed Doors, public workshops
My Stickyminds column, Codependent Schedule Games is up. Enjoy!
I’m close to falling into “Crossing the Desert” syndrome. A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert
I’m happy to report I met my Jan 1 date to finish the manuscript draft for Successful Project Management. I wrote many words last week. So many that I have no idea whether they are good words or not 🙂 I’ve been blathering at my editor, who is probably ready to shoot me if
Pawel caught me being ambiguous. See his comment, “1. I’ve seen features/fixes which required 2 days to be developed and released.” Sorry, me too. But what I tried to say was this: A feature was estimated to be some duration of person-hours. Those person-hours have come and gone. The feature still requires another 10-12
I ran a little workshop today about transitioning to agile. I was talking about timeboxed iterations, and one of the participants asked this question. “So I don’t quite finish one of the features I want to finish in this iteration–and it’s the end of the project. I think it’s going to take me a
I’m catching up with my blog reading. Several posts caught my eye, all dealing with taking time to think: When you take time to think between sessions, the sessions may go faster. You’ll almost certainly have a better outcome. (Esther and I learned this on Behind Closed Doors.) See Ron Jeffries’ take on thinking: Shooting
Thierry poses a question I’ve heard in several of my PM workshops this week and last week: When should the team do the architectural work? Thierry’s concerned if his team continues to implement by feature, how can the team do the architectural work? If they take an iteration or two to deal with architecture,
Joshua asked me to clarify what I meant by implementing by architecture. Here’s my picture-story. When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture. When a team implements by feature, they are cross-functional teams. When teams implement by feature, they do what’s needed in whatever part
Scott points out Software Product Delivery – 20 Rules? that you should do the riskiest part of the project first. (He explains that you modify that given what’s most important.) I’d add a further refinement: that what’s most important better provide the most value. If it doesn’t, do the most valuable parts first. You