Release Retrospectives

The Agile dev team/project I am currently engaged at recently released version one of the application. The application is a K-12+ knowledge portal for animal information. The portal itself is really interesting and I have had a lot of fun working on the project and I have also learned and honed a lot of my agile skills while here.

So anyway, we released the product into the wild and it is getting great reviews. It is pretty solid while employing lots of moving parts.

During the development we went through a typical Scrum style process - daily standups, poker planning,iteration planning, business verification (show n' tell). We also did weekly retrospectives for the previous iteration. It was a fairly boilerplate operation.

Once we released the product we had a release retrospective with the entire team - Product Owner, Dev Team, Content Team, and QA team. Just to be clear the whole team works together in an open agile space with pairing stations and the board, etc so we were in constant contact with each other for the whole lifecycle.

The release retrospective went better than I anticipated it would since I had met some resistance to points I had brought up in the past at iteration retros and I tend to be a rather blunt, no BS person. I don't like mincing words and that can get me in trouble at times but, well, that's just me.

So we executed the retro using the same basic formula that we used and I am sure everyone has some experience with. WE did the standard "What went well, What didn't go well, What can we do better" and then we determined which points to improve were the priority and who would lead those up for the next go round.

There were many good points brought up during the retrospective. The initial "What went well" section had valid successes such as good cross team communication, Product Owner availability, quick resolution to technical problems, etc. We ran into some nasty issues in piecing the app together and our team and especially the Tech Leads were very good about figuring out what was wrong and how to fix it.

The "What didn't go well" and "What can we do better" portions are more interesting to me as these are the ones that drive process improvement and lead to smoother development later. We covered a lot of ground with these and identified many things that were important to getting things to flow better. Things like paying better attention to skill buckets and avoiding knowledge silos were brought out. Trying to achieve something closer to push-button configuration for the pairing stations was another item given the problems we had with keeping workstations relatively synchronized was another point we wanted to address.

After we went through the process of discussing our good, bad and uglies we all then voted by placing checkmarks next to three items in each column that we as individuals thought were the biggest priorities going forward. We tallied the votes and chose the items with the most votes as the topics we planned to pay particular attention to in the next release.

The whole experience was a good, cathartic exercise for the group. We had the opportunity to address points that we all felt were important to discuss, we had the opportunity to voice our opinions about everything related to the release, the team and the process, and we were able to get it out of our systems in a healthy way that will hopefully assist us in continuous improvement for the next release.

If you aren't currently doing release retrospectives then I encourage your team to think about it. It doesn't take a long time to do it and it has the potential to remove roadblocks to future success. And it is empowering to the team to know that their input matters.