Ways To Boost Software Development Teams
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.
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.
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.
Business Q&A Sessions
As a team, we organize one-hour business Q&A meetings once a week. The purpose of this meeting is to refresh our knowledge of this domain which includes a large amount of business logic.
How did this meeting benefit us?
First of all, the initial purpose of this meeting was to make the adaptation of our new teammates easier so they don’t get lost in our complex domain. We did this by preparing some questions on an excel document before the meeting and talking about the answers to these questions in a conversational style, and we aimed to make the information permanent and to be easier to remember.
After a while, we realized that this meeting was beneficial not only to our new teammates but also to our experienced teammates by reminding us of some detailed information. Also, these questions and discussions helped us find some improvement points in our domain.
How does the meeting start and go?
We usually start with a simple question and then jump to different points in the question to try to complete the big picture. By doing this and completing each other’s shortcomings, we aim to keep the knowledge level of everyone on the team equal and complete.
At the same time, we discuss the exciting cases faced by our colleagues who give support that week, and we pass on a good experience to our next observer friends.
Book Reading
We believe that technical and non-technical books in the industry expand our knowledge and enable us to work more efficiently in our working life.
Also, it’s not deniable that now it’s quite easy to reach the desired information from the internet. Still, we need books in order to gain in-depth knowledge of technology and to have information on the topics that interest us.
We also think that being able to learn from the knowledge and experience of experts who have worked in the industry for years is invaluable.
As a team, we take the chapters of our technical or soft skill-oriented books, which we have determined as one per month.
Once a week, the person responsible for the chapter tells the team about the subject.
领英推荐
While talking about our chapters, we try to ask questions such as “Can we use this method?”, “Should we also do this?”, “Do we think the defended idea is correct, and what are the sides we disagree with?” to contribute to our own development not only theoretically, but also practically.
Below you can find a few examples of books on our list.
With this practice, we improve as a team by sharing knowledge, getting new ideas, and realizing what we need to change and what points we lack. We become more conscious of what we do, why, and how, and consistently improve our technique.
OKRs (Objectives and Key Results)
Every quarter of the year, we set objectives according to the OKR methodology. OKR helps us to embrace shared goals.
Some objectives we define this quarter:
While defining the goals, one of the questions we ask first is that “Which side of the team will be stronger if we accomplish this goal?“ so that our objectives are clear and we are sure that the objectives support us to improve our technology, culture, or business value.
Chasing common goals in the team will strengthen the sense of being a team, so it would better remind us that these goals should belong to the team, not individuals. We meet weekly to prioritize our objectives and include them in the sprint. We also arrange a meeting to review our progress on the objectives at the end of every month.
Supporting Taking Courses
In Trendyol Tech, developers are supported to take courses and attend conferences related to their interests. Taking external courses helps the team to increase technical knowledge. In addition, those taking the courses are encouraged to present what they learn in the classes to their teammates. These presentations make spreading knowledge within the team easier and quickly.
Rotation Across Teams
Rotation is a process that allows developers to change their teams. Someone being a part of a team for a while can rotate to another team if they want. The new team the one will rotate to is usually a team that does different things from the one they were previously in. Furthermore, It is optional to stay in the same position; For example, you can change from the backend developer to the frontend developer, etc.
Why should we rotate? What are the benefits?
In Trendyol, teams have various tech stacks and challenges. When people develop all the muscles in their bodies equally, their appearance improves. The rotation allows us to strengthen different muscles in different teams. Even more, changing the team gives us an experience like changing the company we are part of, so the one who rotates has a chance to learn different tech stacks and domains. On the other hand, they can meet new people and spread knowledge across the teams by sharing their experience from their previous team.
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.
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.
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.
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.
Retro Meetings
A retrospective is a crucial part of Agile because it’s where we gather feedback from the team and understand their feelings about the process, thereby improving future sprints. A good retrospective must be engaging and actionable. Our retrospective meetings consist of 3 important things:
When we kick off the retrospective, our first step is to try to break the ice. Because we want to hear one by one all comments and feedback. So what are we doing about it? We start with a small warm chat or ask some funny virtual icebreaker questions. In this way, the team starts to feel comfy and confident.
In order to make retrospective meetings more engaged and action items embraced by the whole team, we have a recurring system for leading the meeting. Each retrospective is led by a different team member.
The primary goal at the end of the retrospective is to produce an actionable list of items that the team can do to increase productivity. We gamify the retrospective meetings by using different online retrospective templates. We set a timer counting down from 2 minutes to give time to team members to write feedback. Columns of the templates help the team to be more focused and ease the process of gathering feedback to improve the process. And then, we read every feedback and discuss whether it’s an action list. An action list either can be assigned to a team member or the whole team. Assignees ensure the execution of the action list.
Mob Programming
Mob programming is a significant activity for development teams. It is the next step of pair programming. Using this technique to solve problems helps us to share business and technological knowledge with teammates. Mob programming improves team collaboration and, using it for core and complex changes, expands knowledge of critical logic. This knowledge helps us to solve critical bugs.
We use mob programming when we need to change a critical part of the domain or when we need to implement a complex business process. Also, we use this practice when there is a need to fix a production bug immediately.
Deciding solution is more important than writing code so that any teammate can write code in mob programming sessions. All product participants (Dev, QA, PO) can join mob sessions. Especially when fixing production bugs, QA and PO involvement is critical.
Thanks to? Mustafa Ak?ll? , O?uzhan S. , Kübra ?ak?r , Selay Arkun Kalafat , Sefa Okumu? , Emel Serengil , Ferhat Erda? , Mehmet Aran , Bilge Tekkursun for their contribution.