Tuesday, December 26, 2006

Listening: how I started doing project retrospectives

When I became software quality manager at my former company, responsible to help improve the software development process so our products would make our customers even happier, I realized that reading up on processes used elsewhere and then telling the software engineers how to do their work would be a quick route to becoming excluded and ignored, but what else was there?

I was a member of the then-active arlist-l mailing list, and I took the action research notion of a learning set to heart. I went to a project team and offered to facilitate project retrospectives. I'd listen, I'd take notes, I might ask a few clarifying questions, and then I'd summarize and publish the notes.

It seemed very important simply to listen, and it seemed very important to produce summaries that were useful, approachable, and complete, so each report started with a 1-2 page summary and action plan (theirs, not mine), followed by a more complete transcript of what seemed like key quotations from the tape I made as data. That is one of the few circumstances in which I have taped sessions, for I wanted to make sure I reported their words and not my interpretation.

The first retrospective or two were published both in paper form to all project members, project managers, their managers, and the R&D manager and in electronic form on the internal 'notes' (USENET) system.

After a couple of retrospectives with various teams, one project team said they were tired of repeating the same problems in each project. Could I help them figure out how to change? We agreed that I'd take weekly data, this time from a short survey, and feed that back in the same manner.

Without giving you the entire history, I listened, asked clarifying questions, and summarized. They spoke, read, and changed. That work, coupled with a few other initiatives, began to make a real, noticeable difference in the development of products, their quality at release, and the timeliness of the releases. Product release decisions, which had been big, important events, became more of a check-off, for there were no longer surprises, at least with project teams which had made heavy use of retrospectives.

As evidence of the magnitude of the change, a project team member came to me one day, incensed that a project manager leading another project accused her team of lying on their retrospectives (I don't think that project manager's teams took me up on the retrospectives offer). He said that no project could run as smoothly as their retrospectives had shown. While I would have wished that his projects had tried them, too, and I would have wished that he hadn't accused the other team of lying, it did make clear the distance we had come with a very simple approach. That was the start of my work doing retrospectives.

How is your organization learning from past experience to improve in the future?

Labels: , ,


Post a Comment

<< Home