Retrospectives

Simple Rules

1. The Program Manager / Project Manager acts as the meeting facilitator

2. The Retrospective scope if focused on the last sprint or the finalized engagement

3. Meeting participants include:

• Program Manager / Project Manager
• Technical Architect
• Engagement Team
• During the iteration level retrospectives, it is possible to have other participants, such as customers or other stakeholders, but that is entirely up to the team to decide
• During final engagement level retrospectives, only GitLab or Partner team members should participate

1. During the Retrospective, the team focuses on the essential 3 questions:

• What went well?
• What would we like to change?
• How can we implement that change?

1. The key to making a Sprint Retrospective useful is to keep it “action focused” (have a bias for action) – meaning the team needs to focus in on what they can change to make their own process better

2. The meeting time is fixed: 45 minutes for each week of sprint duration

Managing Process Improvements over Time

As mentioned, the Retrospectives should be action focused – the intent is to rapidly improve upon the process in order to enable better productivity.

But, the reality is that some improvement suggestions might be quickly addressed, some might take some time, and others might be outside of the teams’ area of decision power or exceed the engagement duration.

It is suggested to keep a running log of improvement suggestions that will help you keep track of what improvement ideas came up, what category they fall into, and what sprint / release they first came up in, etc.

This helps keep the team accountable and ensures you remember all the process improvements you implemented over time.

The time frames that some improvement suggestions fall into are as follows:

Within the Next Iteration / Sprint

An improvement suggestion that can be accomplished over the course of the next iteration, for example, refactoring of a specific CI job. Quit hits, quick successes.

Over Several Iterations / Sprints

Improvements that might take two or more iterations / sprints to implement. Re-architecting subsystems, or a comprehensive obtaining lengthy approvals, tasks that cannot be finished in one sprint, fall into this category.

Over the Next Engagement

Something that you coordinate beyond the current engagement, for example, improving the onboarding process, so you do not interrupt the delivery flow of your current engagement.

Never

Yes, some people do not like the idea that some improvement suggestions will never be addressed, but we all know situations like this. For example, if an automation task would be nice to implement but the implementation effort takes so long that we cannot realize a ROI, we’ll probably never implement it.

This is an improvement suggestion that falls into the “Never” category; not because it might never happen, but because it is a decision in terms of impact and scope that cannot be decided upon by the team.

Common Challenges and How to Deal with Them

Boiling the Ocean

It is incumbent on the Program Manager / Project Manager to keep the team on track during Retrospectives. Sometimes teams have a tendency to focus in on problems that fall into the “Boiling the Ocean” category.

Those are sometimes great discussion topics (especially for a long night over a cup of mint tea), but they almost always fall outside of the scope and sphere of influence of the team.

In order to make sure that the Retrospective is useful and produces good improvement suggestions, the team should avoid these kinds of discussion topics and focus on two parameters to guide the discussion

1. Is the improvement suggestion relevant to the scope (last iteration / current engagement)?

2. Is the improvement suggestion achievable by the team?

Non-Participation

Several years ago a team member refused to participate in a Retrospective. When I asked him why, he said:

"Retrospectives are supposed to be like Lessons Learned meetings… but we never learn any lessons, we still got the same issues we had 2 years ago, so why waste time?"

His point was completely valid. To make Sprint Retrospectives work, you need to focus on what is relevant (last iteration / current engagement) and what your team can actually implement. Keeping track in a log as to what improvement suggestions were brought up, which ones got implemented, etc. keeps the team accountable but also shows the progress.

Blame Game

Improvement suggestions should never smell like blame is being assigned. It is important to have open team communication, and to honestly assess what can be improved upon by the team. Be careful not to assign blame but rather focus on potential solutions.

Everything is Great / Everything is Bad Attitude

Beware of both, irrational exuberance, and downtrodden doomsday forecasts. Both extremes are usually unrealistic. You can always improve on the process, and things are never as bad as some folks might make them seem.

No Improvement from Last Retrospective

Once again, track what you want to improve on, and if it is within the scope of one sprint, put it into the backlog for the next sprint.

As a general guidance, try to reserve up to 20% of capacity in early sprints for process improvements. In later sprints that might go down to 10%. Point here is that you have to account for this work. It is not going to happen by itself, or in addition to an already fully utilized team.

Process improvement activities are part of the iteration activities, not in addition to it.