Managing Product Development

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 bought everyone on your team a copy of Esther Derby and Diana Larsen’s Agile Retrospectives: Making Good Teams Great, you don’t know what you are missing. Literally.

You don’t need more than a couple of hours at the end of an iteration to really learn what was working and what might need to change. You’ll gain way more from a short retrospective at the end of the meeting than any form will tell you.

Forms help people hide behind what they think happened. Forms help people blame one another. Forms prevent people from exploring options. Forms are not agile. They are the worst artifact of a serial process. (Gee, tell us how you really feel, JR.)

If you want to buy Agile Retrospectives from the publisher, I get no money, and Esther and Diana get a little bit more royalty. If you want to buy it from Amazon, I get a few cents and they get slightly less of a royalty. Buy it now, however you choose to do so. Just don’t think that forms are an effective retrospective technique. They aren’t.

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 feedback to the entire project team and helps them see how to proceed based on their immediate past experience. Esther and Diana have written a readable actionable book that explains how to plan, conduct and use the results of retrospectives. They include a full explanation of the 5-step process for a retrospective:

Set the Stage

Gather Data

Generate Insights

Decide What to do

Close the Retrospective

They included 30 activities with instructions on how to use those activities (and which stage(s) in which to use them). Even if you’ve never facilitated a retrospective before, you could use this book to learn how.

I particularly like the quick reference matrix and the moebius-strip-like picture of how the retrospective fits into an iterative lifecycle.

Everything in this book is applicable to any project. Even if you’re using a stage-gate lifecycle, you could benefit from having a retrospective at any management review milestone. The ideas in this book are applicable.

Esther and Diana explain how to timebox a retrospective so the team uses the time most effectively. Too many of my clients use questionnaires to perform “post-mortems.” Ugh. To those of you who are suffering through those questionnaires: put down your pens, and conduct a time-boxed retrospective. You’ll learn a lot more and have fun doing it.

You don’t have to be a part of an agile team to use the ideas in this book. If you’re willing to understand what’s happening (or what has happened) on your project, and you’d like to improve things as you proceed, you can use this book. And what project manager or team wouldn’t want that?

You can buy the book at Pragmatic Bookshelf or at Amazon.

I’ve been thinking about project retrospectives. Too few project teams participate in end-of-the-project retrospectives, and to few managers arrange for them. My clients seem concerned by the price of an outside facilitator and the cost in time to the next project.

To address the facilitator cost, I’ve suggested that any facilitator not on the project team is acceptable. Oops. I wasn’t specific enough. Any facilitator who understand retrospectives *and* is able to not blame anyone on the project team is an acceptable facilitator.

The retrospective facilitator has to be non-judgmental, and willing to postpone finding solutions to problems until the retrospective data is gathered and absorbed by the retrospective participants. In fact, I like to see the retrospective participants define their own solutions. One of my clients was attempting to use the process staff as facilitators for their retrospectives, but one of the process people was too eager to blame some people (”Those developers wrote bad code”) and was too eager to decide on a course of action (”You should use month-long iterations”).

Blaming people, especially in a retrospective where the objective is to see the history of the project and learn from it — to see how things got the way they are — is counterproductive. And it’s not just counterproductive for the moment. Blaming will prevent people from fully participating in future retrospectives.

And, as much as I’m a fan of iterations, deciding that month-long iterations is the Right Size during a retrospective is premature. Maybe 3-week iterations is the right duration. Maybe 5 weeks. Maybe even 2 months, while using a staged delivery lifecycle. Until people look at the entirety of how they are willing to work, a retrospective is too early for someone *not on the project team* to decide how long the iterations should be.

So schedule retrospectives as you schedule the end game. And make sure you select a facilitator who understands enough of the issues to be helpful, but will not push the project team into one direction or another.

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.

I’ve been at this now for a year, and here’s my mini-retrospective on my blogging:

• What did I do well that I don’t want to forget? I learned that even a small entry that helps me to think more is useful. I don’t have to wait until I have completely well-formed thoughts. Pointing you to other authors is useful too.
• What did I learn? Some of my entries are useful for turning into longer articles. Your feedback helps me learn where I should write more (because I’m too vague or because I have a lot of energy around the topic). I also learned that Frank Patrick and Hal Macomber are great reviewers. I already knew that Dale, Esther, Keith, and Laurent were great reviewers.
• What should I do differently the next time? Make fewer mistakes For example, I completely failed to understand the impact of spam and phishing on email and productivity. Consider taking off more on other authors.
• What still puzzles me? I suspect I could use the blog even more for trying out things in my writing, and I’m not sure how to do that yet.
• What do I need to discuss in greater detail? Should I convert from an RSS to ATOM feed? The conversion is easy; I can’t tell if it benefits you, my readers.

In case you’re wondering where these questions came from, they’re from Norm Kerth’s book on retrospectives. When I facilitate project retrospectives, I use these questions to focus the conversation. I’m becoming the princess of focused conversations (Esther is the Queen), so when I debrief simulations or activities in workshops, I use the focused conversation technique. To me, a year of blogging felt more like a project than a small, focused, well-contained activity.

I just returned from my younger daughter’s fifth grade graduation. (For those of you without children, sixth grade is now part of middle school.) It was lovely, and reminded me of how important it is for us to have rituals or ceremonies for the ends of significant work.

If you’re scheduling a project, schedule in the retrospective and the celebration at the beginning. I schedule both at the beginning, so that everyone’s expectations are set (management and the project team). We’re going to learn about this project in a formal way (retrospective), and we’re going to ceremonialize the end.

I’ve been on projects where we didn’t have a retrospective. We made all the same stupid mistakes again.

I’ve been on projects where the last day was just the last day. No special acknowledgement. No appreciations. No lunch. No nuthin. Big let down.

Make part of your project completion a retrospective and some sort of celebration. You and your project team will thank you.