This week I embark on my second remote team project as part of the Chingu Cohorts. In doing so, I’d like to take a minute to reflect on what I learned in my first ‘Voyage’ cohort.
Working as part of a team is not something new to me. I’ve spent the past 20 years doing research in the pharmaceutical industry, all of which were spent on teams of various sizes and levels of interaction. This was, however, my first experience as a part of a development team and it provided some new challenges versus developing a project on my own.
My group was comprised of three people, all of whom had experience developing full stack applications and two of whom (not me) had experience with previous group projects through Chingu.
Of course, heading into the project, I had the usual apprehensions and nervousness about coding as part of a group, like “What if my code isn’t up to par with the others in the group?” and “What if I make a mistake and completely destroy the group’s code base?” and so on…
As usual, these kinds of apprehensions worked themselves out as we began to dig into the project and I’d like to think that I walked away a much better developer for having been part of it. I learned a lot from the other two members of the team, and I’d like to think that they were able to learn something from me in return.
As I reflect on the experience as a whole, I find there were two key elements that greatly impacted the progress and overall success of the team project that don’t come into play in individual projects, communication and workflow. As you’ll see below, these elements are very much intertwined, but I’ll address each of them individually.
When you’re working on a project by yourself you have a complete picture of the scope and state of your project at all times. If you don’t, it’s pretty safe to say your project is going to have some serious issues…
As part of a group project, however, you are dependent on your teammates to provide you with any and all changes they’ve made (and they are dependent on you for the same).
These communications can come in different forms, and we’ll get into some of them below in the workflow section, but suffice to say that if you’ve made a change to the project and have not communicated it in some way to your teammates, they are not aware of it!
Which means they will continue with their own tasks as if your change has not happened. This can lead to unnecessary headaches and many wasted hours down the road… All of which could have been prevented through good communication among the team members.
On the surface, this may sound like an obvious concept and not exactly worth writing (or reading) an entire article about. But if you are used to working alone, with all the communication happening unconsciously in your own head, this represents a critically important change in your normal process.
As such, make sure you act like a good teammate and keep everyone in the loop. This doesn’t have to be difficult or time consuming. Chances are your team has established lines of communication. Keeping everyone in the loop can be as simple as updating the status on a Trello card or dropping a quick line in a slack channel.
When in doubt, err on the side of more communication.
Meaning, if you’re not sure if something is relevant to the team, just throw a quick FYI out there to whatever channel the team is using and move on.
I doubt there are many former teams out there saying “I couldn’t do my work, there was just too much communication going on!” but there are plenty out there saying “Our team fell apart because nobody communicated…”.
Which brings us to workflow.
By workflow, I mean how your team manages the git process and if they are effectively using branches, commits, pull requests, etc.
As I said before, this was my first group development project. I had used git previously for my solo projects but I had a lot to learn when it came to using git as part of a team.
Fortunately, Francesco Agnoletto has written a series of guides that clearly outline how git should be used in a team setting. I highly recommend reading (and bookmarking for future reference) all three articles. They can be found here — part 1, part 2 and part 3.
Personally, I’ve read them each several times and our group used them as the rule for how our team would handle workflow.
I’m not going to restate what Francesco has written in his articles, as I think he covers the material very clearly, but I do want to highlight several points that he makes as it relates to this article.
First, when done effectively, good workflow enhances team communication. As I stated earlier, communication and workflow are very much intertwined, and each can enhance the other.