Why using Retrospectives is the secret sauce for Migrations

Christine Box
Feb 28
5 min read

Updated: Mar 3

As a leader of projects at Sourcesense, an Atlassian Platinum Solutions Partner, my days can vary from day to day and even hour to hour, and the pace of work and changes can sometimes mean that time for lessons learnt feels a little rushed.

However, I believe teams must stop, reflect and learn from projects and experiences, to refine and improve future outcomes in projects. In previous roles, at times project retros have felt challenging, especially when issues and challenges have occurred. However, a good structure for the feedback can often assist in this and ensure that the retrospective is based on improvement and not a blame event.

Sometimes I see a chunk of time in my calendar for a retro and think is it needed, should I take this much time out for the reflection? Yet, after each retrospective, I am reminded of their importance and the remarkable shared understanding that emerges from these sessions.

Justification for spending time in retrospectives

The reasons retro’s are essential include:

Multiple points of view perspectives - project retros work best when there are various points of view, with each person contributing their experiences from their seat in the project - be it customer, stakeholder, developer, tester or project lead. But also including commercial team members and sale/pre-sale helps spread an understanding of the challenges and successes of a project for future opportunities. In our cross-functional teams, we have a breadth of experience and knowledge so the perspectives can differ, and sharing them helps the team develop.

Shared understanding - when issues and successes occur it's often knowledge held between a small number of the team, and if not escalated or discussed in stand up or review can be hidden. Sharing some of the hidden successes and issues can bring new processes and changes to light, but also highlight the breadth and depth of work completed. Teams need to avoid focusing on the surface of a project - and the thinking needed in a retrospective can often help rise above shallow feedback.

Creating collective actions - when a retrospective is held and in real-time feedback overlaps or is repeated between team members, it gives credence to any action plans made out of the review. Having a shared understanding is only valuable if actionable tasks are created and completed outside of the session. This is how continuous improvement is seen in action, through inspection and reflection - but with actions. I have been in teams where actions out of retrospectives were not taken, and there is no quicker way to destroy quality retrospectives than not delivering the actions out of them.

Lessons learnt - as a partner completing Atlassian migrations, every time we complete one we learn something new, and being experts in the products from Atlassian - especially Jira, Confluence and Jira Service Management - does mean we are occasionally surprised but changes. For example, we often use the bundled changes functionality in the Admin area (for Premium and Enterprise products) to ensure that the test migrations we complete match the production migrations. a lesson learnt in a migration pre Sourcesense for myself!

Some retrospectives examples

While a good retrospective can glean clarity and improvements, a poorly run one can cause issues and de-motivate, hence using a template or structure for a retrospective is key, but also having time to prepare is critical.

Some excellent retro's I have personally used in projects previously include:

The Classic Start-Stop-Continue

Best for: General project reflection

Why I like it: It's a great retro that can be used in projects that run long or are using an Agile methodology. It can be light and efficient or detailed depending on the needs of the team.

Structure:

Start: What should we start doing to improve?
Stop: What isn’t working and should be stopped?
Continue: What’s working well and should be continued?

The 4 L’s (Liked, Learned, Lacked, Longed for)

Best for: Learning-focused retros

Why I like it: It gives the participants a chance to reflect using more emotive language and avoids some negative language that can sneak in by re-framing the discussion with improvement instead of criticism.

Structure:

Liked: What went well?
Learned: What did we learn?
Lacked: What was missing or insufficient?
Longed for: What do we wish we had?

Sailboat (or Speedboat) Retro

Best for: Identifying risks and opportunities

Why I like it: For teams with a more creative than technical approach this is a great way to connect to their feelings and gives more chances to discuss with some lightness and humour while keeping the continuous improvement approach.

Structure:

Wind: What helped us move forward?
Anchors: What held us back?
Rocks: What obstacles did we face?
Land Ahead: What’s our goal?

Timeline Retrospective

Best for: Reviewing the full project journey

Why I like it: When completing a programme of work and project with dependencies and multiple deliverables, a full timeline is a great way to revisit the points in the project and ensure the breadth of feedback is focused on more than just the last week. better for more corporate or SLA contractual retrospectives.

Structure:

Plot key events on a timeline (milestones, challenges, achievements, surprises).
Discuss patterns, trends, and key takeaways.

The 5 Whys

Best for: Root cause analysis

Why I like it: As an approach this works well for development or support projects, if there is a development aspect or fix procedure as it allows for a review into the why, digging into the multiple causes and assists well in root cause analysis.

Structure:

Identify a problem.
Ask “Why?” five times to get to the root cause.

And of course - a good collaborative tool can make running retrospectives efficient and effective, my favourite is a Miro board inside a shared Confluence space using a free template from Atlassian!

The Takeaway

anime image of a team working in the day

It's often said that it's important for people to understand their history so they learn and grow from this. and the same applies to working life, looking back and learning from both the successes and failures make the future work better. Continuous improvement is the way to achieve this and retrospectives are an excellent approach to achieving efficiency in future, as well as helping create action plans for teams to achieve.

And finally - why are retrospectives the secret sauce for Atlassian migrations? The majority of companies completing migrations from DC to Cloud, or Cloud to Cloud will only complete this process once or twice in a decade inside their business.

However, at Sourcesense International and in our wider Sourcesense group we have multiple migrations happening at any one time, meaning we are learning from the good and the challenging more often, as well as having certified and accredited migrations specialists who are constantly updating their qualifications with the latest first-class training from Atlassian to ensure success in migration work. Using a partner for migration means that the issues an internal administrator might find challenging and time-consuming is a five-minute task for our teams and their automated migration tools.