The Launch is the first of many products you will build in teams. To achieve this, you will need all your learnings from the year of the professional development competencies: communication, teamwork, problem-solving, time management and confidence. So make sure you go through the points you know you might need an extra reminder for and read them.

But to get you and your team ready for The Launch, there are other things you need to do, too, and this prep work will walk you through them.

Get ready to Launch your career!

Working in teams is one of the hardest things in our professional lives. This is because we are all different and have our opinions, values, and knowledge. Knowing how to work and respect each other is key to being a successful professional in tech.

This exercise will explain your team formation and give tips on what you should define from the start to reduce conflicts.

Your team will have:

• 3 or 4 Developers: these will be other trainees you might know.

• 1 Tech Lead: a volunteer who will support your team with the architecture and design of your product

• 1 Product Manager: a volunteer who will work with you to detail the scope and define the user stories

You might also have the following members if a trainee focuses on this career.

• QA (Tester)

• UI/UX Designer

You might have a Business Owner representing the charity or organisation you are doing this briefing for. They will give your team insight into the users’ needs and the value the product will deliver.

What do you need to do?

Arrange a team meeting to go through the following agenda. You can use Exercises 1 and 2 of this Miro board. (Exercise 3 is for the class)

1. Clarify roles and responsibilities: review the roles and ensure everyone on the team understands what they are doing and how they will contribute.

2. Get to know each other: everyone should say 1 thing/action they like and one they don’t like so that you get to know each other’s ways of working. For example, I do not like having meetings early in the morning because it is my focus time. I like meetings to have a clear agenda so I can prepare beforehand.

3. Write a team agreement: you will all respect these rules as a team. For example, I will let the team know if I cannot make a meeting.; I will prepare for the meetings beforehand.; I will commit my code to production whenever it has been approved and tested

4. Define your team’s name: you can just be called Team 3, but if you want to create an identity, you have all the freedom. Or it could be the name of the organisation the briefing is for.

5. Create your Slack channel and add the relevant participants.

You will continue working in sprints but with some extra meetings to ensure the team is aligned and on the same page.

1. Daily Stand-up:

• What? A daily update to your team and from your team to you about your workload. You will post a message every day and read all others, too.

• Why? Ensure everyone knows who is working on what or who is blocked and needs help.

• How? The easiest way is setting up a workflow/bot on Slack and everyone replying on the thread.

2. Mid-week check-in

• What? An online meeting during the week which all participants of the team can attend

• Why? Review delivery, go into detail on anything that could not be worked out via Slack or pair programming, re-plan if needed

• How? You can use Google Calendar and Google Meets or even have a workflow on Slack and use the huddle

3. Saturday meet-ups

In-person meeting with the following agenda:

• Demo: show what you have worked on this week

• Retrospective: review last week, celebrate and action

• Sprint planning/Backlog Refinement: refine the user stories that will come next and which ones you will tackle in the coming week

• Pair-programming: work together on the stories

These contributions are expected from the trainees on the team:

1. Roughly equal pull requests (PR): The team members should have roughly equal numbers of Pull requests each. We do not expect everyone to open the same number of PRs or commit the same number of lines of code, but we expect features to be fairly evenly shared. As a quick guide, in a group of four, no one commits more than 33% of the features, and no one commits less than 20%. These contributions will be measured with a tracker similar to this template.

2. Full-stack developer = front and back-end work: A full-stack developer must deliver features that touch each stack part. This means that, at minimum, you must build a component of UI that interacts with the database and configure and manage that entire process. At best, this means multiple features across different parts of the stack.

3. Know how to do these: create your feature branch, do a good code review, scope down your PRs, mob your paired commits, resolve merge conflicts, and merge your Pull requests (PR).

Make sure the whole team understand the exit criteria. We know it isn’t perfect, but it’s the best way to measure everyone’s input so far.

Find the template for your Launch group and add your team data.

If the template hasn’t been set up, do it yourself and share it with the wider teams.

The briefing is a document that describes the product you should build. You will be given a briefing on Slack. It might be from a new partner, or it might be from CYF.

You can read over likely projects on /briefings

What you must do:

  1. Read it by yourself

  2. Discuss it with your team

  3. Raise any questions before the start of the first week

  4. Clarify the questions with the team

If you have one, the Business Owner can help you with this guidance. If not, you as a team will decide. Validate your decisions by asking clarifying questions in Slack to check you are still achieving the goal of the briefing.

1. Create a GitHub repository.

• Pick one member to own the repo
• Everyone else should be invited as a collaborator
• You can fork a starter kit for a basic project
• Make sure you have the extension for Paired and Mobbed PRs

2. Create a copy of this Project Board to manage your work - Project Board on GitHub

• Agree on which columns you need (Backlog, Ready for Dev, Code Review, etc).

• Link your repo to your project board so you can easily create user stories.