infoTECH Feature

August 27, 2015

A Look Back: How to Optimize IT Project Management with the Help of Retrospective

By Special Guest
Pavel Novik, QA Unit Manager at A1QA

Imagine a group of people watching a movie and then discussing it; you’ll often find the discussion to go beyond what happened at the surface of the movie. This is how a retrospective works in IT.

Shaking up the Team

What is a retrospective? From a general point of view it’s just a look back. Doctors use retrospective when preparing patients’ case histories. Watching old movies of a certain director is also called retrospective in cinematography. In the IT world, retrospective refers to a meeting held by a project team at the end of a project or process (often after an iteration) to discuss what was successful in the project, what could be improved, and how to incorporate the successes and improvements in future iterations or projects.

What is the value of retrospective for managers? A retrospective allows them to detect hidden project problems and raise the effectiveness of the team. Moreover, it helps testers eliminate the fatigue they would otherwise experience as a result of monotonous tasks. It’s an acute problem for long-term projects (one that lasts for 1-2 years), when monotonous tasks annoy some team members and they don’t perform their best work as a result. Many of these types of situations can be “cured” with retrospective—once their work can be shown and discussed, all team members receive other members’ advice, and share their opinions, giving a fresh look on teammates’ work.

Collecting Problems

There are four stages every retrospective should include:

-Collecting opinions (positive and negative)

-Voting and defining topics

-Making resolutions

-Fixing results

To simplify the process of collecting opinions, it is a good idea to choose the topics that should be “retrospected” in advance. For instance, topics such as the communication within a team, the quality of testing, the defects description, etc. can be discussed. When the project is completed, pros and cons should be gathered, and the team should determine the most serious problems by voting.

Once team problems are prioritized, the hardest part – discussion and searching for solutions – can start. This typically consists of a brain storming session covering all topics.

A Good Day for a Retrospective

How often should a retrospective be conducted? The project should reach a certain stage when the retrospective is suitable. Usually, it can be done after a certain phase of the project, when it can be seen with fresh eyes – phases such as a project sprint, iteration, release or completion.

When coordinating the retrospective meeting, you should arrange for a day, a couple of days, or a week in advance. This gives your team the necessary time to perform analysis and reflections, so they can come to the meeting prepared. The actual retrospective meeting could take up to several hours. It depends on the size of the project and the team, and the number of problems that need to be discussed.

Before the meeting starts, determine who the facilitator will be; this person will need to watch and observe the regulations of the retrospective. Ideally, this should be an independent person, even from another project. He or she should make notes and write down the problems pointed out by the team members. The facilitator should also push everyone to share their opinions.

The meeting should begin with a quiz and gathering of opinions. The key points can be written on a whiteboard, so everyone can see them. This is followed by potential options being voiced by team members. Finally, the most efficient and reasonable ideas should be decided upon.

When the meeting is done, the results should be designated. A letter should be sent to all members of the meeting, so that all results and decisions are stated for each person in writing.  

Avoid Fake Problems

While a retrospective is quite an efficient method of solving project problems, there are some factors that can ruin the entire process. If team members are passive and inconsistent, they can end up with no result. If you are the one who initiates the retrospective, try to engage and interest everyone. If everyone on the team realizes that each of them will gain benefits from the retrospective, they are more likely to participate in reaching a decision.

Another potential problem that can arise is the discussion of unnecessary topics. When it becomes difficult to identify the real problem, all team members should discuss the possibilities collectively.

Also be aware of fake problems, such as uncomfortable chairs or slow Internet connection. These are not the types of problems retrospective is meant to solve. To avoid such situations, follow the regulations of the retrospective – encouraging teammates to discuss only the most essential questions.

It is important not to blame anyone in particular for problems discovered during retrospective. The team problem is a common problem, so everyone should participate in solving it.

When used correctly, retrospective can be an extremely efficient and valuable tool to help optimize project management in IT. For this reason, it is becoming quite common to use this method of reflecting on what has happened in the iteration and identifying actions for improvement.

About the Author: Pavel Novik is QA Unit Manager at A1QA, an independent software testing company, and a QA Coach with a breadth of technical experience. Pavel is responsible for QA project management and conducting tests to ensure mobile applications function according to business standards on any size and scope of projects. Pavel is also a frequent speaker at international QA conferences and his local QA Club.




Edited by Dominick Sorrentino
FOLLOW US

Subscribe to InfoTECH Spotlight eNews

InfoTECH Spotlight eNews delivers the latest news impacting technology in the IT industry each week. Sign up to receive FREE breaking news today!
FREE eNewsletter

infoTECH Whitepapers