“Alone we can do so little; together we can do so much.” – Helen Keller
Team Dynamics
Whenever there is a huge task that needs to be done, it is usually not delegated to a single person. That particular task may be assigned to a team, or a team may be built specifically to do that task. How can the team make sure that they are at their best every single moment? The answer is to make sure that the team dynamics is good every single time. But what is team dynamics?
Team dynamics is an unseen psychological ‘push’ that affects the behavior and performance of the of the team. It is not necessarily good, as it depends on many external and internal factors that the team has, which is different for each team. But generally, if the team yields good results, it means that the team dynamics is good, and if the team fails to reach its goals or is heading to failure then the team dynamics at that time is bad.
“It is literally true that you can succeed best and quickest by helping others to succeed.” – Napolean Hill
Servant Leader
When working as a team, I am introduced to the concept of a “Servant Leader” a concept that I haven’t heard of. It basically turns the leader responsibilities upside down, in that:
- The purpose of the leader is not to lead explicitly, but to serve.
- The leader shares power and puts the needs of the teammates first.
- Helps teammates be the best that they can be.
The next few paragraphs will describe me applying the servant leader concepts (unconsciously) in practice.
My experience in helping improve team dynamics and being a servant leader
In sprint two, I experienced a lot of setbacks. One of my teammates went away without informing the rest of the team, and one has issues back at home that prevents him to work for the week. Meanwhile, the boilerplate app was not initialized correctly and nobody bothers to fix it, the QA application has not been integrated to the CI/CD process of the app and nobody but me knows how to integrate it, the code base was improperly branched, and there are a multitude of tasks to be done related to the PBI that I took for the sprint. Most people would panic when faced with that situation. But I persevered, and I will now tell you how.
From the story that I told you before, you may conclude that my team has poor team dynamics, and you are right. But this is not something that could not be improved.
First, I look at whatever it is that is happening at that time, and try to find solutions to the problems that occurs. One of my teammates, Dimas, was gone for good, and Nicky, the one that had issues back home, can still work, but may not work efficiently. Both have taken tasks to do. Therefore, what I did is to ask someone that is closest to the one that can still work (this happened to be Aloy) to help him finish his task, and delegated the tasks that are taken by the one teammate that was gone for good to people that are able to take them. I was going to delegate them all to me, but one of my teammates (again, Aloy) was willing to take part in it once I said that I will delegate them all to me. Therefore, after he assured that he could do it, I delegated some of it to him instead. The rest of the problems (Fixing the branches, setting up the QA and the CI/CD process) will be solved by me. Problem solved? Yes, but only for the problem that happened at that particular time. If you think that it would go without a hitch after that, you’re wrong. There’s always something that could go wrong, so you must notice.
A few days after doing that, I opened the group chat of my team on my phone and looked at the messages. Somebody (Yosua) needed help since he had just implemented his test cases, did not know whether or not it is correct and did not know what to do next. Since I was busy implementing the QA stage in the CI/CD (which was surprisingly hard to implement, but that is for another blog post) in addition to working on my tasks, I went on and asked somebody to help him. But since Nicky and Yosua had troubles, Aloy is the only person that I could ask, and he was happy to help. This later resulted in Yosua finishing his tasks first. Another problem solved, but there are still more problems along the way.
A few days later and I found out that I was the one having problems. The implementation of the QA stage did not finish as quickly as it should. Because of that, I struggle to find the time needed to implement the task that I took from Dimas. I immediately asked for someone to take that particular task over. Nicky responded, saying that he can now help finish the task that I took. In an instant I changed the assignee of that task to Nicky.
These things were some of the many adjustments that I helped catalyzed and amazingly, this made us one of the only few teams that had the sprint review in the same day as us to have all of the PBIs that were taken to be accepted. This pleases me greatly because our team used to be clueless about a lot of the stuff and it is a confirmation that all our hard work had paid off in spades. The sprint began with a massive hitch in addition to the problems that none of the other teams had (in the form of one teammate leaving) and ended in us having fixed most of it. Sure there are still some problems e.g. the code coverage for my teammates’ code is not 100% yet (I reminded them every day to fix this but it has not been done yet), and the development team is permanently down to four, but at the very least our team is better than where it was before.
Bringing out the best in your team by letting them do the tasks that they can do best.
From sprint two, I realized that all of the members of my team have different skills. One of them, Nicky, is skilled at coding at the backend and in creating custom algorithms to solve specific problems. Yosua, on the other hand, struggles to do frontend and backend, but struggles with the backend less. Meanwhile Aloy and I, can do both. In the most recent sprint that I did, which is sprint three, I figured I should delegate the tasks according to their strengths and weaknesses.
First, I delegated Nicky to do the algorithms at the backend, which is actually the brunt of the functionality of the app. The algorithm generates a valid schedule when given a json object which contains the data from two excel files: one of them containing the details of the courses and one containing the rooms which are used for midterms and final tests. He accepted this happily and told me that this is the task that I have been waiting for. So far, he’s done great. However, due to how excited he was, he did parts of the algorithm that were supposed to be done on a different sprint (we did not take the PBI that involves a certain portion of the algorithm for sprint three). I reminded him to focus on the task at hand, and just develop the needed algorithms for the PBI that we took this sprint.
For Yosua, I delegated him to do the relatively easy parts of the backend. Our app has the functionality to upload two excel files, checks whether or not those files are in the correct format, then creates a json object out of them so that it can either be sent to the front end, as a prompt, or to another function of the backend which is the algorithm to create the schedule. He is assigned, along with Aloy to assist him, to do this task.
The front end portion of the app is done by me and Aloy. I also assigned Aloy to do this since he has the ability to do both frontend and backend. The work that he has put out as of now has been consistently good, which is a good indicator that I have put him at the best spot that he can be in. I originally wanted to do the algorithms portion of the app as well, but seeing that no one else can do the front end other than me and Aloy, I have to do this.
Sacrificing the things that you want to do does not feel good, but it is better than us not finishing the app as fast as possible because I am selfish and put my team members in situations where they cannot perform the best. Also, it is nice to see that my teammates are comfortable with their roles, it makes them more inclined to do their work. If you see your team not performing well, try evaluating their roles and switching them so that they are on the roles where they can perform their best. I can guarantee you that this will yield a significant improvement to the performance of your team.
Update: Delegating is not the way to do things
When your team does not know what they can do, delegating them might be the best option. However, it is best for any individual to choose their task themselves. Because of the sprint failure I decide to ask, what it is that they are comfortable with doing. The answer that I got is that one of my friend (Aloy) wants to continue to do the algorithm, while I want to do the firebase portion. Two of my other friends are confused on what they can do for the team. I suggested for one of them (Yosua) to improve the react portion of the app (frontend). He became worried that he cannot finish it in time. I said to try first, and if he fails, I can take over after I’ve finished the firebase portion of the app. Meanwhile the other one became very hard to communicate to. He did not reply in chat, he did not participate in any major sprint actions (review, retrospective and daily scrum) and there is also no contribution that he made in the past sprint. I told my team that we should work regardless of whether or not he works, and we should not wait for him to wake up and do his task while still trying to maintain any connection with him.
In the end he did came back, but he was very adamant of using his algorithm instead of the one that has already been presented to the assistant teachers. I told him that we can’t do that since the algorithm that Aloy made is already good and well tested and suggested him to help Aloy. He won’t do that and said that he wants to improve his own algorithm. I asked what I can do to the TAs that were assigned to me. They did not know what to do with him as well. In this case I prioritized sprint goals over this one guy, and I think I made the right choice because if I don’t do that, we would’ve failed a second time.
Catatan sehari hari 