Ways To Boost Software Development Teams — Part 1

When we try to figure out the secret of successful teams, we will notice that all have a common ingredient, a good culture that allows teams to establish strong relationships and guide them to strengthen their skills.
In Trendyol, creating a better culture is one of the major priorities. In this article, as Promotion Team, we will share the following practices we adopt.

In addition, you can look at Ways To Boost Software Development Teams — Part 2 to check out other practices we apply.

• Onboarding for Colleagues
• 1:1 Meetings with Colleagues and Regular Feedback Flow
• GoyGoy — Gaming Hours
• The Bug / Incident Review Meetings
• Pair Programming
• Lunch and Learn
• Code Reading Sessions
• System Design Sessions

Onboarding for Colleagues

Providing essential materials to new colleagues is one of the most critical issues for us so they feel safe and can see the path ahead clearly, cause we believe in the power of first impressions. 🙂

As part of the onboarding process, we provide practices such as assigning a buddy to a new teammate, making a phone call, and including them in an onboarding schedule for two weeks.

A teammate, preferably one of our experienced friends, is selected to guide our new friend who will start a job. Buddy will be the first person she applies to in case of any questions or help.

One week before starting the job, the buddy makes a welcome phone call and provides preliminary information, receives information about whether the necessary tools have reached her, and answers the questions a new teammate wants to ask.

In the onboarding schedule, the newcomer ensures that she meets other friends in the team with whom she will work. Also, the introduction of the tools used, the team working order and culture, the meetings held, the team’s goals, and domain information are given. During this process, we encourage our friends to ask questions and get information from their buddies and other teammates.

As the Promotion team, we have rich domain information and business rules; hence it is one of the priority issues for us to explain the domain logic so newcomers can understand and have an idea of what to do.
We provide our new friends with to benefit from the domain diagrams to understand the domain information better. In addition, by doing business Q&A sessions, we refresh our knowledge and seek solutions by sharing domain-related questions.

We think that we have a stronger team and company culture when we ensure that our new teammates go through the adaptation process as smoothly as possible, with a plan.

1:1 Meetings with Colleagues and Regular Feedback Flow

Why should we do 1:1's?

1:1’s help us to establish truth-based relationships between teammates by giving and receiving feedback. Teammates learn each other’s private areas and do not point out personality as a problem source. Colleagues help each other develop their technical and non-technical skills by giving feedback. Trustworthy relationships make people happy and feel like they belong to the team.

What should we do?

Each team member should arrange 1:1 with all teammates at least once a month. Taking notes on a shared document is essential to remind previous notes. Attendees give positive and constructive feedback to each other. They should provide constructive feedback with the STAR technique. If there is no feedback, attendees can ask the following questions to start a conversation.

What am I good at?
What can I do better?

1:1 results for our team

Teammates have solid and trustworthy relationships. They feel confident in sharing their ideas, and no one is afraid to make mistakes.

GoyGoy — Gaming Hours

What are we doing?

We have goy-goy hours every two weeks. In this meeting, and sometimes outside the meeting, team members come together and spend time just for fun. We try to attend this meeting as the whole team, including product owners, developers, and QA’s. There are some games we play regularly, such as codenames, among us, vampires & villagers, gartic.io, car racing games, and so on. We chat with each other when we’re not playing games as well.

Why is it crucial?

Our workload can increase from time to time. For this reason, we take time to reduce work stress and have a good time. In this way, we aim to strengthen our communication inside our team. During the day, we spend most of our time with our teammates, so strong relationships are vital. These meetings help us to know each other better and make working more enjoyable.

The Bug / Incident Review Meetings

The Bug / Incident Review Meetings are held to understand the problems we encounter more quickly and easily with their root causes and then to offer practical and permanent solutions against them. In these meetings, team members come together to understand the problem. The root causes are examined, and a solution is specified by looking at what action could be taken to prevent this problem. These meetings allow us to investigate issues, find root causes better, and prevent possible problems that may occur in the future by selecting the most optimal solution.
When an incident occurs, we immediately meet with the team members to find the source of the problem by examining the alert details and interpreting the incoming logs; after that, we take the necessary action for a solution.
We categorize incidents according to the following;

1 ) Time Interval
2 ) Cause and Effect
3 ) Impact Size (Low / Mid / High / Very High)
4 ) How could it have been avoided (Test / Alert )
5) Category (Code Deployment Problem, Change, etc.)
6) Action Status (Fixed, Temporary Fix)

For applications with a very high number of instant users, providing an inconsistent service can cause massive problems and cause financial loss. Hence, time is vital to take action as quickly as possible for any incident. Almost all team members come together to work on a solution and manage this process with less damage demonstrating how essential teamwork is.

Pair Programming

While working on a task, we generally do pair programming, which is a common practice at Trendyol. At least our two colleagues gather at our team’s Discord server; while one is coding, the other helps and observes her and gives some feedback. This method is so helpful for developers. One developer can gain the other’s perspectives naturally. We discuss how we can complete a task effectively without leaving technical debt during pair programming. In addition, changing the turn of writing code frequently is a practice we adopt because if just one of us codes, others can lose their attention after a while. We’ve observed that if we do a task this way, it’s almost wholly done error-free, the code is cleaner, and we’re more productive. Furthermore, pair programming is helpful for our new teammates to adapt to our team, business-domain logic, and tech stack.

Lunch and Learn

What is L&L?

Lunch and learn is when a teammate makes an interactive presentation based on her previous experiences or research on a subject she is good at, curious about, or developing areas of the team. In addition to the meetups everyone can attend in the company, we make lunch and learn presentations within the team. The topic can be something other than software. The primary purpose is to enrich the knowledge of the team. It usually takes between 30–60 minutes. Typically the L&L presentation is done during lunch. However, we do it when the team is convenient.

Why should we do a Lunch and Learn presentation? What are the benefits?

It increases the spread of knowledge within the team. It supports the presenter in improving on the relevant subject. While the people who know the subject will master more, those who have yet to gain experience with it will have an idea about the topic. L&L develops the presentation and public speaking skills of the presenter as well.

Code Reading Sessions

In this session, we usually choose an external or an internal project each week and start reading the code. We aimed to learn various implementation examples from these projects and how to use these patterns in our project. For example, one week, we can choose to read the Checkout API code to see how and in which way they implement their tactical DDD patterns. The following week we can choose Golang implementation examples from external sources.

System Design Sessions

System design sessions aim to strengthen the team’s knowledge of software architecture and their ability to clarify problems and resolve conflicts. It can be designing a news feed system, google maps, a dating app, etc. The good part of these sessions is being interactive.
We are opening a board on an online board tool(like Miro, Lucidchart, etc.), and everyone is joining the board to change it. Participants consider the pros and cons of the ideas, for example, Why should we use a graph database? Is eventual consistency acceptable, or do we need strong consistency for this system?

Every session has a moderator who is responsible for managing the session. When participants ask questions to clarify a problem or resolve ambiguity, the moderator must answer these questions and define requirements. The other responsibility of the moderator is to prepare a small presentation before the session. This presentation should include topics that are related to the system we design. If we develop a chat system, the moderator can talk about pooling, long polling, and web sockets, or if we create a URL shortening, talking about hashing and encoding can be a good choice.

Thanks to MUSTAFA AKILLI, Oğuzhan Sarıçin, Kubra Cakir, Selay Arkun, Sefa Fatihhan Okumuş, Emel Serengil, Ferhaterdas, Mehmet Aran, Bilge Tekkursun for their contribution.