Our Team’s Dynamic — Chaotic yet Fantastic
This post is special. I’m not going to refer to here and there to seek inspiration on what to write. I’d just recall things that we have gone through as a team for the past 9 weeks, what has worked well in our team, what hasn’t, what would make our team better if we had done it earlier, and what we’ve learned so far about remote teamwork for our software project.
Before we begin, team dynamic means ‘the unconscious, psychological forces that influence the direction of a team’s behavior and performance. They are like undercurrents in the sea, which can carry boats in a different direction to the one they intend to sail.’ There are some factors that determine a team’s dynamic: teamwork, personality, the relationship amongst the people involved, and work environment.
We’re getting better in each sprint. Due to extensive communication, our eagerness to learn, and the help of the agile scrum framework, we’re progressing constantly in each sprint. This article is also acted as an appreciation for my team for the hard work everybody has put into our platform development. Although things doesn’t run smoothly all the time, we managed to get through. There are times where I feel that the teamwork is very painful, and other times so proud of our team’s progress and initiatives. How do we manage to get through and get full marks in almost all sprint reviews?
About the Project
Our university has a mandatory course named Software Engineering Project ( or IT Project ). This course taught students to work on a real project brought by clients, most of them are Small Medium Enterprises, to build software for them. This course is a big deal among students because it has one of the biggest credits amongst other individual courses, is fast-paced, and requires heavy interaction with many parties. There are at least 5 parties involved: developer team (usually consists of 4–6 people), a client with their needs, product owner who acts as a facilitator between client and dev team, scrum master that helps dev team keeps track of the works, and the lecturer who bridges between client and PO and grades us, and the TA, who help us with deployment matters and grade our codes (done both manually and automated with sonarqube and lint).
Complex, right? For around 10 weeks, we will build a product, a website in my case, and for the teamwork, we use scrum methodology. 1 sprint lasts for two weeks. At the end of week two, we’ll present our progress to the client, lecturer, TA, and PO. At the end of every first week, we also have to deploy our code which will be graded (TDD applied), and write 2 medium articles. Our team decided to hold 2 daily standups per week for the whole semester.
We worked on an arcade game marketplace — Walkiddie — developed in a Django backend and a React and Redux frontend. So either you are reading this to seek inspiration for your article (to my junior) or you are just curious about our team’s work, let’s dive right in.
Context
Our team consists of 6 people — Me, Naufal, Primo, Azhar, Mario, and Darian. And here are some facts about us:
1. We don’t personally know each other before the project
I know Naufal because we’ve worked together before, but the rest are not. We only know each other’s names.
2. We don’t get to pick our team members
This is not the normal semester to take the class, so there are only 12 people in the class. The team is determined by the lecturer.
3. Our personalities are completely different
Some of us are very quiet so it’s kinda hard to understand their personality at the beginning. Some of us are night owls while others are early birds.
4. We have other works aside from the project
They are taking full credit this semester, and some of us are also having internships simultaneously.
5. It’s a legacy project, we don’t build from scratch
Depending on the team, you might build something from scratch ( from building prototypes and choosing tech stacks ), but ours is a legacy project from the previous semester. Each has its own pros and cons.
6. New to the framework
This is a common thing. Some of us may just start learning React, Redux, Kotlin, or another tech stack during the project. This can be a nightmare or an opportunity, depending on how you see it. So did our team. Most of us never used React or Redux before. Based on my observations, we took around 2 sprints to really understand the codebase.
Our Chaotic Team Dynamic
Below I am going to point out some mistakes that we’ve done:
1. Lack of Motivation
Let’s be frank, not every team members are excited about the project and you cannot force them. It’s easy to get demotivated somewhere along the way. In our case, this is because of not understanding the benefits, lack of chemistry with the team, different vision among team members, and overwhelming tasks.
With many workloads, it is very hard not to feel pressured. As a typical software development project in Scrum, the project is fast-paced ( and graded).
2. Unhelpful Behavior
What I meant by unhelpful is delaying works that affect other members, being irresponsive, and won’t take initiative. Quoting from deakinco.com, “Some team members taking it easy at the expense of other colleagues can lead to poor group dynamics and outcomes.”
3. Inefficient Meetings
We had some meetings: standup twice a week, one progress meeting with the lecturer every two weeks, one sprint review with all stakeholders every two weeks, sprint retro every two weeks, sprint planning every two weeks, and impromptu coding meetings.
During standup meetings, many of us don’t pay attention and just focus on our own progress. In our project, which happens in most SE projects, one feature is strongly related to others. For sure, they’re features of the same platform 💁🏼 Since we split up the work based on Frontend or Backend, a person creates the API ( backend ) for the frontend to consume, and vice versa. Not paying attention to a packed 30 minutes meeting would disadvantage the person. For example, which happened quite often in our team, someone encountered errors in hours and turned out somebody had mentioned that during the meeting 😃.
4. Lack of Trust
I believe that openness/transparency is one of the keys to the team’s success. There are some cases where we don’t utilize standup to evaluate and share our progress openly, and this led to a chaotic sprint review preparation by the end of the sprint. And it annoyed everyone. Be open with your progress, share screen during standup so that everybody understands what anyone else is saying and can help to solve their problems.
5. Unequal Workload
Determining project/backlog scope in every sprint planning is mandatory. If the scope is not well-defined, some people may receive more works than others. This is not a startup, it’s a school project designed to be pretty much alike. We only have 1 scrum master, hence we cannot lay all the planning works on the scrum master/PO.
In our cases, we often just say yes during the planning and assume we understand what the scrum master/PO expects. Or the backlog owner misses out on details about the feature at the beginning thus making the latter work hard.
When I was assigned to google login backlog, I forgot to mention that our signup is not yet properly functioning. If I have mentioned that during sprint planning, I could reduce my backlogs due to the complexity of this one backlog that turned out to be bigger than expected.
What We’ve Learned to Improve our Team Dynamic
1. Allocate Time to do Planning and Evaluation Regularly
Although we skipped the team-building part, we rely on sprint planning and sprint retrospective to build strong bonds between team members. During sprint planning, we list down and assign all the tasks for the next 2 weeks, where adding more tasks during the 2-weeks span are discouraged. This is a great way to stay focused on what to do, step-by-step.
Sprint retro is another biweekly event to evaluate team performance. If I feel uneasy regarding certain behavior of a team member, I usually say it here and try to find the solutions. We usually used 5 categories — what’s already good, what’s bad about the teamwork, what should we start doing, and what must we stop doing, and lastly, a list of action items summarizing all.
2. Everything can be Learned
First, I am a believer that everything can be learned. All you need to have are first, eagerness to learn, and two, willingness to acknowledge and correct mistakes. See the project as an investment of your time to hone your skills both your technical and soft skills. Where else can you get the opportunity to do professional work in a learning environment where mistakes are very much allowed?
3. Together is Faster and More Fun
Another good habit that we have as a team is ‘coding together’ culture. This is usually done around 2- 3 times every 2 weeks, depending on how many errors we encounter😂 Even when we don’t have problems with code, just having someone in the line can make the work feel less stressful.
4. Have a Shared Purpose
We had a mistake: we skipped the team-building part and jumped right into the work, also didn’t set a shared purpose in the first place. For the first few sprints, team members are not on the same page which made the group work feel stressful.
“When a group of people works together, it is crucial that everyone is clear on what that goal is. If your team has trouble making decisions and seems to battle itself at every critical point, it’s time to do some digging to find out whether or not everyone is on the same page.” — Ryan Eudy.
That’s why deciding a shared purpose must be done at the beginning.
If you are the fire of the team, keep motivating your team.
You can also create a team charter. According to deakinco, the team charter should offer clearly defined roles, set behavioral and outcomes expectations, and anything that you think can act as a standard that the team can hold as a standard and hold underperforming members to account.
5. Interdependence and a Sense of Belonging
“Each team member should know why they are part of the team. They should understand their value and responsibility. If your onboarding is rushed or disorganized, you may miss this.” — Ryan Eudy. And that is what happened to us. Think about how much more productive your team would be if each member had the sense of ownership for the work of others as they did for their own work. Members of such a team could lean on each other for ideas and assistance. When a team is focused on fulfilling its purpose, members can work together to make it happen without keeping tabs on how much they give or take.
“If you see a team member engaging in unhelpful behavior, work to address it quickly. Speak to the team member directly and invite him or her to reflect on the behavior and how it can be changed to support the team’s goals. Conflicts can happen from time to time — even in the healthiest of teams — so encourage open discussion of the conflict and help guide team members to a resolution, allowing your team to return to a state of positive group dynamics.” — deakinco
6. Respect Others by Paying Attention
In a SE project, features of a platform are interconnected. Putting a full-focus for during a 30 minutes standup can save you hours of debugging. To avoid this, it’s better to make an agreement. Or it can start from you by being responsive to others’ progress. By being focused, everyone can avoid repeating the same questions again and again and make the sprint more efficient for themselves.
7. Honesty, Transparency, and Openness
“Team members need to feel safe to share information and ideas without fear. Trust opens the door to dialogue that can lead to better ideas and more creativity. Team members must also be able to trust that everyone will meet their deadlines, carry their weight, and do their part of the work.” — e4j
I really respect people with these three traits: Honesty, Transparency, and Openness. They can be manifested in some of these acts: articulate progress and obstacle clearly, ability to estimate work, fulfill promises, the courage to initiate calls with friends who’re more expert on a specific domain.
8. Stop Assuming — Understand your Backlog Thoroughly
You have to be detailed about the features you’re assigned to. Confirm your assumption to SM&PO. Is that what they mean by A? Unless you want your work later to be criticized and work on that twice.
Make sure all the requirements are clear at least for our own backlog. In our scenario, it is very important to be able to visualize the possible scenarios of backlog you are about to take. Be detailed on backlog’s acceptance criteria, what the PO expects, and the feature’s nitty-gritty details.
Those are our stories portraying our team dynamics. On top of all, every team member is progressing both in technical skill and communication ability. I feel that we’ve grown together as a team. Every team may have their own problems and their own way to deal with them. In the end, we want to maximize the team’s potential. Keep in mind that Individuals and interactions over processes and tools. 🙏
Reference:
