Guide: First Steps in Tackling a Group Project

This guide can be used to tackle other project ideas in a group setting. This guide was itself written by a collaborative team, you can find our other guides here.

Step One – Understand the Project

Assess the prompt or project requirements. What technical skillsets do you need to complete the assignment? For example, will you need UI, UX, front- and back-end, and data analysis? How advanced a skillset in each is required and how much work is there to go around? From here you’ll know who else you need to find to work with and how many of them. An in-depth understanding of the project and exactly what you need to do it can come later.

Understanding your project also means understanding what you’ll need from a team. We have a whole guide on how software development teams work (here) that we recommend reading and will refer to below, but for the time being you can just read this quick article on who does what in a dev team to get started. If you’re working on a simple project early on in your web development journey, you probably only need one teammate and a Multiplayer Repl or Codepen collab. If your project is more complex, you’ll need a more complex team structure too. For most mid-sized projects that you may do while learning, four people is probably the right team size (read this for more info), with one team lead who also codes, one UX/UI designer who also codes, someone on the front-end, and someone to cover the back-end.

Step One-Point-Five… If You’re Charting Your Own Path

Working on a project that isn’t predefined or prompted for you means that you’ll have to spend more time in step one, because you’ll need to find and define your idea and a whole lot else besides. Read this quick article for a helping hand.

If you’re working on a very complex idea in mind, like building a fully-functioning professional-quality app, you’ll need to spend even more time in the planning process. This long article is a really great resource for planning out that whole journey. Don’t forget to research using the right stack.

You can and probably should do this planning with a team, but it can also be hard to gather a team of volunteers if you aren’t sure what you want and over what timeline. One things that makes groups successful in more freeform projects like this is if they already know each other and ideally if they’ve already completed a project together before. So, our advice is to start slowly and steadily with smaller projects tailored to your skill level, so that you can build up your experience and relationships before going for an ambitious project.

Step Two – Find Your Teammates

Find collaborators! In the Pro Slack group, join and post in the #code-buddies channel to find other people looking to work on projects too. If in doubt, know that the group moderators have all tackled group projects before, so feel free to ask questions. If you aren’t in the Pro community or if you want to cast a wider net, you can also find collaborators here on the forums (post in #general), on the Facebook group, at local meetups, or in a whole host of other places.

Step Three – Build Your Team

Choose and assign roles. One of you will need to be a project manager for the assignment, someone to keep an eye on component tasks and tie it all together. This isn’t necessarily the most technically skilled member – in fact in the “real world” it’s often the opposite. Know at this stage that roles ≠ tasks.

Step Four – Do Your Research

Do your research. You all have some foundational work to do, all of which differs depending on your team roles.

Context For Everyone

First, everyone on the team who is coding should know about this guide. If your project is a very simple front-end website, you may be able to just work on a Codepen or Repl together and not use GitHub, but if you can use GitHub you should. It is highly recommended that you follow the GitHub guide completely. If you aren’t doing any coding in the team, e.g. if you’re covering UX only, you can go to the “skip steps” section.

Everyone should also watch this video on how developer teams work.

Context for the Team Lead

Overview: The team lead should read this guide to how teams work in order to have a good breadth of context and information. Your team will be relying on you to organize them, and to a large extent you’ll educate them as you go on what you learn from that guide. Pick the methodology to work with, e.g. Agile vs. Waterfall, Scrum vs. Kanban. Give your other teammates the lowdown on how their work will go. If you want to know some secrets of being a good team lead / manager where developers will love working with you, watch this.

Crash Course: The link above is a long guide, so if you’re eager to just start, want to just skip to helping your teammates set up in an Agile framework and “back fill” your knowledge from the above guide later, you can. For the purposes of group projects, go for Kanban if you’re 1) relatively new to group projects 2) not very experienced with technologies 3) have a smaller project. Alternatively go with Scrum if you’ve 1) done a small group project before 2) have some experience building projects. Once you’ve picked Scrum or Kanban, watch this on user stories, then these two resources on project and product management (roles that you’ll be doing in this team). You should also skim through the articles available to you here. After that, read/watch the following in this order in order to quickly set up in a Scrum system (1, 2, 3 4, 5) or a Kanban system (1, 2, 3, 4).

Context for the Designer

Designer – read our guide on design. You may be splitting your design team up between UX and other forms of design, in which case you can split this list accordingly.

Step Five – Organize

We’d recommend everyone on the team reading the below so they know more about why and how the project is being structured, but only the team lead needs to read the below.

  • Tracking: Team lead should set up task tracking and reporting so everyone knows what work is being done by whom and how it all comes together. I’d recommend using a Trello board to track tasks as it’s simple and free. See guides for using Trello with Scrum here and with Kanban here. If you prefer another tool, like if you really want to get Jira experience before using it at work, that’s totally fine too.
  • Communication: You should all agree on where you should chat and check in! You can start a private channel on the Pro Slack (easiest), open your own free Slack workspace, start a Discord server, whatever you’d like.
  • Time Commitments: Some people can commit a lot of time, some can’t. Understand early what people can and should commit to for this project, when they will be online and working, and set expectations early.
  • Deadlines: It’s hard to do work without them. Always remember that your teammates are volunteers, so it’s important to get everyone’s input and assent for deadlines, so that they agree to the things they’ll be held accountable for. Read more about how to set deadlines the right way here.
  • Syncing: Make sure that you and your team agree to a regular schedule of checking in with one another and on the project. Though most of these check-ins can be done asynchronously or via chat, you should try to meet on a group call when possible too. You don’t have to have do it daily, but the standup framework should help you (read this for more info).
  • Product Specifications & Implementing User Stories: Your team can work together to figure out exactly what needs to be done in order to build your product based on user stories provided (if you’re doing your own project and need to make your user stories, read “extra credit” below). Have a meeting and walk through the user stories, discussing what you’d need to do to make it happen. You can also divide up those stories between people to research what it’ll take to complete them to save on meeting time.
  • Pull Requests and Merging: You’re all going to be working on different parts of the same project, and they’ll eventually all need to come together. Decide on a system of pull requests, approvals, and merging. For example, one contributor will ask to make a pull request, and then they’ll need to have at least one thumbs up from someone who has reviewed their PR before merging. Make sure everyone is clear on how this system works and who approves what, when.
  • Group Learning: Finally, and this is vital, you’re all taking part in this project to learn with one another. Even on the job as a professional, continued learning, mentorship, and education is a vital part of a developer’s work and job satisfaction. Make sure that you’re taking the time to review one-another’s code not just for whether it should be merged or not, but how it can be better. Take the time to walk each other through concepts – after all, studies show that this is one of the best ways to cement your learning (fact!). Consider having one teammate do a screenshare of something tricky for the others. Talk through things and overcommunicate. If you all just work silently, you’ll only get a fraction of the value. This doesn’t mean everyone leaning on the most skilled people in the group or expecting to be taught, talk about it among yourselves and set expectations.

Extra Credit:

  • User Stories: Some projects for learners will already come with a series of user stories that you need to work through. If you are working on a project of your own, then you’ll need to make them. User stories are part of the team lead and designer’s reading list, but multiple team members can and should be involved. You can quickly learn how to craft your own user stories here. Adding more user stories is another great way to build your skills and keep practicing without continually having to build projects from scratch. You can easily just put yourself into the mind of the user and ask yourself… what would I as a consumer want from this website or software? From there, the sky’s the limit.
  • Pointing or sizing: User stories have varying levels of complexity and may take different amounts of time to complete. When development teams estimate the time and effort it will take to accomplish a task, it is usually called pointing or sizing. This is important for being able to equitably divide work and to meet deadlines. You can learn about how to size projects in this quick blog post, and it’s best to do this in a group conversation if possible as it will be a very productive way to reframe and apply what you’ve been learning in coding.

Step Six – Get to Work

Get to it! Have a kick-off meeting, ideally on Skype or another video call system, so you can all meet one another and discuss the project.

Remember that if and when you get stuck, you can and should lean on each-other in order to get through problems. In the real world, developers troubleshoot their own work first with tried and true methods, but they aren’t shy to ask teammates for help too. If your teammates can’t help either, reach out here on the forums or in the Pro Slack community.

Sometimes, s**t happens. Maybe a teammate has an emergency and needs to leave or just goes AWOL. Everyone’s volunteering for these groups and has other things in life to do, and we should be understanding of this fact. Even in the “real world” workplace, people get sick and things too. If someone leaves your group and you need a replacement, post in the Pro Slack and the community will try to help you out.

Step Seven – Share!

Post your project in #project-feedback and share it with the other Pro learners on Slack! Getting feedback is a vital part of the development process and in growing your skills. Remember to give back to other people wanting feedback or guidance, not just because it’s a good thing to do but because you’ll benefit yourself when other people are there to help you too.

If you’re feeling generous, don’t just share your work but share your insights and guidance for the next team tackling something similar. Paying it forward and giving back is how the developer world works – entire languages have been built this way.

1 Like