In one of my courses this semester the second half was mostly focused on a group project. I was excited about this because I had been missing the collaboration that I had in my job before going back to school — in particular the opportunity to discuss code with other people and to learn from them. I didn’t know my two teammates very well, but from my interactions with them in class they seemed intelligent and competent so I was happy with our group. Working together proved to be much more challenging than I had anticipated though, and it taught me an important thing about teamwork: don’t make assumptions about your teammates.

I really liked the work-flow at my last job and so I went into this project hoping to recreate that to a certain extent. Nothing fancy, just what seemed to me like standard things: using issues/tickets to break up and track work, writing tests for every change, using pull-requests, and doing code reviews. It turns out though, at least among students, that not everyone is familiar with these tools and processes. By assuming that these processes would work and not fully discussing them with my team I failed to get buy-in.

This put us in a state where everyone followed their own processes: I created issues for work that needed to be done and my teammates would do the work without claiming or closing the issue; I would put up a pull-request and then merge it, un-reviewed, the next day; I wrote tests which would then get broken because my teammates weren’t used to testing. We got some of the overhead of the processes, without the benefits. It was also very frustrating to me, and I often felt like blaming my teammates for their “incompetence” even though the situation was largely my own fault.

What should I have done differently? If this had been a longer-term project I think it could have been worth enforcing these processes, but I would have needed to get buy-in from my teammates so that they could learn how to make good use of them. Since this project only lasted a few weeks though it would have been better to compromise on a level of process closer to what my teammates were used to. Either way, we should have had a more open discussion up-front and made a decision as a team.

Because of our failure to have those discussions I don’t think any of us did the best work that we could have, resulting in a final product which wasn’t as good as it could have been. Although this example may be somewhat specific to an academic program where students come from different backgrounds, it’s important for all teams to communicate about each member’s skill-set, background, and expectations.