I recently spoke with a project manager. He was concerned about the product managers handing off the requirements to the development staff. He was right to be concerned. Handoffs don’t work. The more people think they are done with “their” part, the less likely you are to receive/finish a great product. That’s because no one […]
Jurgen wrote Lesson Learned: Automate Project Evaluations a couple of weeks ago. I’ve been trying to find a nice way to explain that no, Jurgen is wrong. I can’t do it. Jurgen, You are WRONG. If anyone here is doing some form of agile or incremental or any kind of development, and you have not
About a month ago, I spoke with a project manager who’d inherited a project in chaos. No one was making progress. He was stumped–he’d never worked on a project where the developers couldn’t do anything, the testers couldn’t do anything, and time was just slipping away. I suggested he try baby steps. What’s the first
Esther and I were teaching a Behind Closed Doors tutorial at Better Software yesterday. One of the participants was a program manager. He couldn’t see the value of the standup meetings the Scrum teams used every day. “They talk to each other all the time–why do they need the standup? I can’t see the
A number of my clients and colleagues are struggling with the problem of bringing people into their organizations. In Hiring the Best …, I recommend the buddy system for bringing people on. I wrote a little article, How2 Create a Buddy (Informal Mentoring) Program. But maybe you didn’t know that, or can’t figure out how
Glen Alleman in What’s Wrong With This Picture says this: dentifying, sequencing, and assigning durations to tasks is NOT the role of the Project Scheduler, it is the role of the project team, along with the Project Scheduler. The Work Package Manager, the Customer, the entire team that is accountable for delivering the business
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
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,
A colleague asked me what to do when you’re in an iteration and you realize that the story you’re working on spawns other requirements. I suggested that the person add them to the product backlog (the backlog of everything you want to do for the product) and re-rank the requirements in preparation for the next
Want to save time on your next project? Improve working relationships? Understand what contributed to your success–or what didn’t? You’ll need a retrospective to do these things, and if you want a great retrospective, you’ll buy a copy of Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. A retrospective provides