Planning is the key point when starting a new project. It is required to plan the work of the devs team, find potential threats, and ask as many questions as possible to make the team's work easier. However, even the best-planned projects are not free of mistakes. Everybody knows it and accepts it as something normal in the IT world. 

But what about a situation where the team keeps making the same mistakes on subsequent projects? Or do different teams in the company repeats all errors that happened to their colleagues? Despite many completed projects, there are no lessons learned, leading to the perpetuation of bad habits and practices. 

Do you feel that similar situations happen in your company? Do you keep making the same mistakes and don't have any process to minimize them? 

There is a solution that will minimize those mistakes and enrich your software development process. It's a post-mortem meeting.

What is a post-mortem meeting?

Post-mortem meeting is a team gathering at the end of a project, where the project team determines which parts of the project were successful and unsuccessful. 

It's like a reflection where the project team analyzes aspects such as: 

• Things that went well. 
• Things that didn't go well. 
• What could we do differently next time? 
• How to address particular problems to improve ourselves next time? 

The benefits of a post-mortem meeting

There are many benefits for the team: 

• Identification of various things that didn't go well. 
• Valuable conclusions and insights. 
• A good lesson for the future 
• What should we do differently next time? 
• How to avoid inevitable mistakes? 

The client also benefits a lot from this:

• The team that learns from mistakes is a massive benefit for the recipient of a product. 
• Received feedback – it helps the client in terms of better cooperation with the teams it is working with. 
• Action points – the team has already found few elements in project realization that can be improved to achieve better delivery results – deadline and product quality. 

You see that both sides are winners here!

Post-mortem meetings tips

What you should know about post-mortem meetings is that there is no one-size-fits-all form of such a meeting. Each team should find a way that allows them to reach beneficial post-mortem results. 

How do we run it at Synergy Codes?

Preparations

Before you start, make sure the whole team is prepared for such a meeting. We begin with pre-meeting work: 

• Everybody thinks of things that went well and things that didn't go well. 
• When looking for those things, we think of a project from different perspectives: 
• Technical stuff 
• Software delivery process 
• Cooperation 
• Things that we didn't have much influence on 

We also define an agenda so that everybody understands what will be discussed. It's also good to assign one person that will be responsible for running such a meeting – a kind of chairman.

The goal of a meeting

Post-mortem meetings that happen in our company can be categorized depending on when they are held: 

• Conducted at the end of the project – when finishing cooperation with the client. 
• Performed at the end of a particular project's phase. 

The main goal of each post-mortem meeting is to analyze all aspects of the project's lifecycle so that both sides can receive fruitful feedback after it. We analyze the project itself and cooperation with the client from the very first day. 

Discussion

I will describe here the post-mortem meeting that we conducted with one of our clients. 

When running post-mortem together, we went through the list of general questions that allowed us to analyze the project from different perspectives: 

• What went well/made you proud? 
• What didn't go well/was frustrating? 
• What would you do differently next time? 
• Which software delivery processes worked correctly? 
• Which software delivery processes didn't work as expected? 
• If you had a magic wand, what would you do with it in your project? 
• Did we miss involvement from anybody on the client's side? 
• Did we miss any position on Synergy's side so the project could go better (UI/UX, BA with particular knowledge regarding business domain)? 

Such a list was a great entry point for the discussion that is vital for each post-mortem meeting. 

When discussing each point, we were analyzing more deeply particular areas such as: 

• Project realization 
• Preparation of the project. 
• Strategy for the project realization. 
• Organization of the team. 
• Features delivery. 
• Testing process. 

When analyzing each topic, we were looking at it from different perspectives: 

Technical

Everything related to used technologies, programmatic challenges, and difficulties, performed tasks, architecture, coding standards, or technical debt. 

Cooperation

The cooperation focuses on things related to the maturity of collaboration. It covers further requirements, UX discussions, communication channels, work division, appropriate roles within teams, or feedback. 

Human

You can indicate here such factors as involvement, team spirit, and individual skills. 

The result of all these preparations and discussions was a meeting where together with the client, we jointly analyzed the following topics: 

• Project and performed work.
• Cooperation.
• Problems that arose.

Additional elements

As mentioned in the beginning, each post-mortem can have a different form. When running our latest post-mortem, we introduced additional elements such as: 

• Project timeline. 
• Identification of project aims and objectives together with the strength and weaknesses of our product delivery. 

Those elements and the whole approach was more discussed in the Synergy Cafe episode.

When finishing post-mortem, it's essential to have some output. We try to categorize our output in such a way: 

Lessons learned

It's essential to learn lessons for the future based on our reflection: 

• What things did not work out? 
• Why was that? What caused those issues? 
• What can we do differently next time in our projects? 

Identifying lessons learned helps to run projects differently and better next time. 

Conclusions and insights

They're beneficial lessons for running future projects – not only for us but for the whole company: 

• Other teams working on their projects will know what things they should pay attention to. 
• Those that are starting their projects will follow best practices from the very beginning. 

Materials to prepare feedback for the client

When running post-mortem, general feedback concerning crucial points from our discussion should be passed to the client. it's perfect for catching those issues in such a way: 

• Facts (e.g., we didn't have a stable testing environment)
• Consequences (e.g., we couldn't see all the bugs because our testing environment was often down)
• Solutions (e.g., focus from the very beginning to prepare testing environment)

What can we do next?

Remember that a post-mortem itself is not a goal. The most important thing is what we want to do later. Generally, we focus on three aspects (each of them is important in Synergy Codes):

Feedback for our client
We share the most important things that came up during post-mortem and are related to the client. When sharing feedback and talking about negative aspects, we present all caught facts, consequences, and solutions.

Action points
Our clients are primarily interested in issues that appeared and ways to resolve them. By picking the essential issues and connecting them with learned lessons, we can produce action points and assign owner(s) to each of them. Some action points can be technical aspects where we can create PBI (Product Backlog Item) for them; others are more related to cooperation or software delivery processes, where the team treats them as golden rules - good practices that the team follows.

Propagation of post-mortem
It should be a step after each project. We do our best to adapt it globally and help other teams in the company to run post-mortem meetings.

Final words

You see, that post-mortem is a powerful tool that enriches your software development process. It's like a reflection that is usually conducted on the completion of the project. It helps to identify successful and unsuccessful parts of the project. Each team should stop for a moment and analyze their project to draw valuable conclusions and apply them in future projects to run them better. This step will pay off.