Imagine this scenario: You’re a project or program manager. You suspect things are not going swimmingly well. But no one has told you any bad news. Not yet. What do you do? As a facilitative leader, such as a project, program, or agile project manager (Scrum Master), it’s your job to seek out that bad
Lisa, an agile project manager, dutifully completed her project status deck every iteration to send to her leadership. She hated creating that deck for several reasons: she knew the data she reported wasn’t the data the senior leaders needed. Some of the leaders still wanted to know the schedule variance—which made no sense in an
If you read my Three Alternatives to Making Smaller Stories, you noticed one thing. In each of these examples, the problem was in the teams’ ability to show progress and create interim steps. But, what about when you have a “wicked” problem, when you don’t know if you can create the answer? If you are
For years, I have ranted against traffic lights as a way to discuss project status. That’s because on serial lifecycle projects, or on long projects, the traffic light was always yellow or red. And, because managers, especially senior managers expected the light to turn green by itself with no outside intervention. But Lisa Crispin noted
Have you ever waited weeks for one piece of functionality so you could release a large project? Have you been in the situation where the software is waiting for the hardware? Or where the database admin held up the entire release because his work wasn’t coordinated with the feature-based teams? That’s because you were working
Summary: Long-time advocate of status reports, Johanna Rothman has come across a new way of reporting the movement of a project using something we experience every day—the weather. In this week’s column, she sheds a little sunshine on this new technique, which demonstrates the status of a project a lot like meteorologists announce current weather
by, JB Rainsberger and Johanna Rothman, © 2008 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse
I met a manager recently who relayed his technique for making sure his testers stayed focused on their jobs. “Our defect-tracking system logs people off after 30 minutes of idle time. If they’re logged off, I know they’re not working.” This was a new one for me. I’ve heard of counting lines of code.
David Anderson has an intriguing post, Lawyers, Unit Tests and Performance Reviews. David says “Individual team members can be set specific goals and behavior objectives…” and gives examples. I prefer that team members set their own goals with input from their managers. But the key here is that a technical person should be looking to
Originally published in Computerworld. Drake, a technical contributor in your group, sends you his weekly status report. He’s been reporting on this six-week task for the past six weeks: Week 1: Task 1 90% done Week 2: Task 1 95% done Week 3: Task 1 96% done Week 4: Task 1 99% done Week 5: