My project team consists of eight people. Six of them are developers/developer leads and the other two are QA. We interact with each other daily during our scrum meetings and often throughout the day either in person or through email or slack. The scrum meetings are effective because we are able to talk through the problems we are having, if there are any blockers and see if anyone else has the solution to the problem instead of asking just one person. The problem with the team is that some of the team members are in Santa Clara so it’s harder to interact with them on a consistent basis inside the office.
It’s hard to say what a big or small team is, but generally, the more people there are the harder it is to communicate well with everyone on the team. With a bigger team, it is harder to coordinate times to meet or when one person is in the office or not so often times, someone gets left out. Some ways to overcome them is using kanban boards or documentation sites like JIRA and Confluence. These tools really help to get other team members up to speed.
The thing about working in a team is that you have to start considering the limitations or boundaries of other people. Some people work effectively in intervals and some people work more effectively doing 3 or 4 hours code sprints. To me, it’s all about finding what is comfortable for everyone and to not overstep boundaries (like emailing members about work during after-hours).
In this last week, we started up a new sprint. I was assigned a few tasks that I am pretty excited to be working on. My first task is to build a persistent warm DB instance on one of our pipeline builds using Jenkins and groovy scripting. The challenge here is learning about the whole build process my company uses in its continuous integration environment to find the best place to insert this warm DB script while also learning about various command line tools like cURL, psexec and groovy scripting.
Along with this main task, I was also assigned to start fixing defects in the backlog and refactor code to be more efficient and readable. With all these tasks, my days at work seem to be more jam-packed with issues.
The work from my internship and the work at UC San Diego have so far been different, but my approaches to the problems seem to remain the same. Other than that, about the topic, I feel that it is very important to be a part of the team and actually contribute in order to get the most out of the team. More often than not, when I ask the team for help, they seem to always know the right direction to go, especially when handling the warm DB project or the build process. Before, I was afraid of asking questions for fear of seeming like I don’t know enough, but really, that is what the internship is for.