Clarke Ching’s post, Functional Blindess, reminded me to post the ways I know about how to see the current state in a project or in an organization. For projects:
- Ask to see a demo. Can you see anything at all? If you can’t see the results of prototype tests, unit tests, some kind of working software (even if it’s not all put together), don’t believe your schedule. It’s possible your schedule is still correct, but there’s no way to tell at all.
- Ask what’s left to do. I tend to use charts that discuss what we planned and what we still have left to do, a type of burndown/burnup chart. (See Brian Marick’s summaryand SprintBurndownChart, and Big Visible Charts for more charts.) I use charts that show a running total of what’s accomplished and what’s left, so that if people add more things to the project, the line goes up, and as the project team finishes work, the line goes down. Up = more to do, Down = less to do.
- Ask for obstacles. If a PM asks about obstacles to completing the project, people are more likely to explain what’s preventing them from finishing the work.
- Perform an interim retrospective to really see what’s happening. (See below).
- Gather data about what’s important to you. Make sure you’re gathering multi-dimensional data. (See Single Dimension Measurements for my thoughts about measuring people’s output in a single dimension. The same thing applies to projects. If you only measure the date, you’ll meet the dates, but the features won’t be there, and/or they won’t work.
Seeing in the small is one thing. Seeing in the large(r) is another. Some ideas to understand your product development issues:
- Perform a retrospective of a just-completed project. If you’re the PM or somehow involved in the projects, you can’t facilitate this; you need to participate, not facilitate. I use Kerth’s questions to drive retrospectives:
- What did we do well, that if we don’t discuss we might forget?
- What did we learn?
- What should we do differently next time?
- What still puzzles us?
I facilitate interim retrospectives in a few hours, and post-project retrospectives in 1-2 days. In 2 days, you will be amazed at what you can see.
- Perform an assessment to see the problems and what caused them. Again, someone outside the organization needs to perform this.
People in the project and in the organization have blind spots. They can’t help it (and neither can you). So consciously look for techniques to become aware of the blind spots, so you can fix them.