When you’re in a coding bootcamp, you’ll most likely find yourself working in a team at some point. You may be someone who would rather work alone, but the reality is that software development in a professional setting is usually done in teams. Working with others is an important skill and I wanted to share some of the things I’ve encountered from my undergraduate days and my current involvement in the DigitalCrafts bootcamp that led to a pleasant group project experience.
What Make a Group Work Well Together?
A group that works well together has these characteristics:
Agreement on the End Goal
The team understands the requirements from the instructor and determine together what to build that satisfies the baseline. There’s no problem going above and beyond the baseline but it’s a recipe for disaster to dive into the work phase when there’s disagreement on the end goal of the project.
Open Communication
I define communication as being able to say what’s on your mind without making people feel attacked. Sharing what’s on your mind in a respectful manner goes a long way in making progress.
The team should have access to a shared resource of work related materials to stay in sync. Tools like Trello, Google Drive, and Github work well. Also, the group should have a chat with only the members of that team. I’ve used tools like Slack, GroupMe, etc., that help with this. This helps keep messages segmented and makes it easier to look up information at a later time.
Mutual Respect
Being civil and courteous to your teammates and not gossiping helps cohesion. Imagine trying to get work done in a group where different points of view are shut down in an unprofessional manner. You don’t really need to work with people that you are best friends with but people who are dependable, contribute, and don’t cause unnecessary drama.
Project Phases
A team project is usually broken down into three phases. The first stage is the brainstorming phase where ideas flow to determine what to create. The second stage is the work phase where you build and collaborate on the final product. And lastly, the presentation stage where you show off your work to your cohort.
Brainstorming Phase
In this phase, you’re trying to figure out what to create. It’s important to not ever attack the person behind the idea but to constructively criticize the idea itself. Don’t be too quick to shoot an idea down because you can contribute to it and make it stronger that what was initially proposed. People are generally happier when their contributions are heard and included in the discussion.
At the same time, don’t get too invested in an idea you propose because the rest of the team may be able to spot potential downfalls that you may not see. That’s one of the positives of working in a team. Ideas can be stress tested and improved. Conflict around ideas is not bad and is what should happen when brainstorming.
It’s important in this phase to also speak up when you feel that the team is going in a direction you think is not good. It’s much easier to change course in this phase as the momentum hasn’t picked up yet. The longer you wait in speaking up, the higher the chance you may find yourself in a situation where you’re begrudgingly working on a project that you don’t care about. It’s more fun when everyone has buy-in and the project is a reflection of each of the team members’ contributions. Speak up and make yourself heard. No one can advocate for your positions besides yourself.
Now on the other hand, you don’t need to be 100% bought-in on an idea in order to give 100% effort. The purpose of the project is to apply lecture material in order to learn. Flexibility and compromise are essential to keep moving forward.
Lastly, if you really want to be efficient, already have an idea saved and propose that to your team. Sometimes your group will just go for it and jump straight into the work phase as it saves the time and consternation of first coming up with an idea in the first place!
Work Phase
This is where the rubber meets the road. You’ve already figured out what to build but now you’re concerned with how to build it. This phase is all about collaboration, coordination, and completing tasks.
In the previous phase, you should have determined what your “dream” product looks like and all the cool features that it contains. Now, strip it down to the bare essentials and build the smallest subset of functionality that gives people a rough idea of what the final product will do. You do not have time to build a fully-featured application as most projects are less than one week.
When you have a slimmed down version, sometimes called a Minimum Viable Product (MVP), structure your work around getting those features built and implemented by the project deadline. It’s not a bad idea here to also make sure your MVP satisfies the baseline requirements for the project.
I’ve had a lot of success on group projects using a Trello or Github Projects Board with four columns:
MVP Backlog: Work that needs to be completed by the deadline
In Progress: Work actively in development
Done: Completed work
Stretch Goals: A place to store the “nice-to-have” features. They’re not mission critical but would be cool to have in the product by deadline.
Try and get a rough MVP done and working a day before the deadline to decrease stress before attempting stretch features.
In a small team, there is no excuse for poor communication. When all of the group can easily fit in a small room, everyone should be kept on the same page. One pattern I’ve used in several projects is in the morning, prioritize which tasks are the most important, discuss any blockers, break out and work individually, and then circle back at the end of the day to sync up individual work. It’s important to have a goal set for the day for what you want completed. At the end of the day, discuss what needs to be done by the start of the new day and repeat the cycle until the due date.
If you’re done with a task and looking for things to do, communicate that with your team before starting on your next task to insure you’re not overstepping on someone else’s work or making changes without notifying your team.
Don’t be afraid to reach out to your team when stuck. Try and solve your problem on your own for 30 minutes to an hour but if it’s taking you longer than that, reach out to your teammates and/or instructor as there’s a good chance they’ve experienced a similar problem before. Having an extra set of eyes on your issue can help get you unstuck.
I strongly believe that team members need to have individual tasks that they are accountable for. This will make the presentation phase easier and decreases the likelihood of work not getting done.
Lastly, I don’t think members of the group should be siloed to just the HTML and CSS. We all have our strengths and weaknesses but I think everyone in the team should have the opportunity to contribute to all aspects of the project. Obviously, this decision will be made by your team and not myself. I’ve noticed that there can be a tendency to “protect” your part of the project but that behavior is unnecessary and unrealistic as your primary objective is to learn how to collaborate and apply information you’ve learned. If you’re not happy with how the project turns out, you can always fork the repository and do it your own way.
Presentation Phase
Your group will most likely get the opportunity to present the project to the rest of your cohort and the instructor will probably make each individual speak. Getting up in front of a room of people and presenting your work can be uncomfortable and downright scary but this is great practice for communicating in a professional environment. The classroom is really practice for the workplace; it’s important to get your speaking reps in now when the stakes are low.
Make sure to either jot down or make a mental note of your individual contributions as well as the struggles you faced and how you overcame them. This will help avoid the last minute scramble of trying to figure out what to present.
Being able to deliver this information to your cohort is essentially the same situation you’ll be facing when you’re sitting at the interview table with an employer and they’re asking you about your previous work and project history.
Conclusion
At the end of the day, people have different personalities which can lead to conflict. However, I believe you can work together with almost anyone if there is agreement on the end goal, open communication, and mutual respect amongst teammates. The point of a group project is for you to learn and apply new skills together. It’s better to contribute good work to an idea that you’re not 100% on board with than to contribute bad code to your own idea.
Editor's note: This post was written by student Nep Orshiso. An original version of this post appeared on his blog.
