In the launch, you will build a fully working product in a team.

To achieve this, you will need all your 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.

Your product must work. (Along with your business owner) you can choose the scope of your product, but what you produce must work. Remember: It’s better to build something small that works well, than lots of things that don’t quite work.

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:

• 2-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 even number and size of features: The team members should contribute roughly the same proportion of features to the project. Someone may make one bigger feature, and someone else two smaller ones. But someone should be able to look at the team and say “Yes, they contributed similar amounts”. Because, regardless of feature size, you should be making frequent small pull requests, your number of pull requests should be similar. 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.

2. Work on things you want to work on in your job: If you want to be a frontend developer, you probably want to focus on the frontend. If you don’t want to limit your job opportunities, you should work on the whole stack of the project. Most people should work on the whole stack (which can be within a feature, or in different features). The kinds of skills you show in your project will influence what jobs CYF can recommend you for.

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.

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

You will get instructions about what tracker you should be using to track progress on your project. If you haven’t received this yet, ask for it on Slack. Make sure you fill it in.

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.

If you don’t have your brief yet, while you’re waiting, you can read over example briefings to get a feel for them.

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.

Create a GitHub repository

• Pick one member to own the repo
• Everyone else should be invited as a collaborator
• Make sure you have the extension for Paired and Mobbed PRs

Make a project board for your team

If you want, you can create a copy of this template project board on GitHub, or you can make your own.

• 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.