Setup

Grab a list of common interview questions from somewhere like Coursera.

Game 15 minutes ⏱

1. Interviewer: Cold call a random person and ask them an interview question. Choose an ordinary question.

2. Interviewee: You must give a terrible answer to this question (keep it clean, please!). Then cold call another person to be the interviewer.

3. Interviewer: Give absolutely straight-faced feedback. If you laugh, you’re out and must nominate another player to complete your feedback and return the game to step 1.

Motivation

We have a lot of first-time volunteers helping at the Launch, so it is always good to ensure both volunteers and trainees understand what the module is about.

Discuss the following questions as a cohort (trainees and volunteers):

1. What have the trainees learned before joining the Launch module? Think about Tech Ed and Professional Development (PD) learnings.

2. What will be the main challenges for the trainees?

3. What will be the main challenges for the volunteers?

4. Why do we do the Launch module?

5. What should we make sure we don’t do at the Launch module?

6. What are we doing on the Saturday sessions?

7. How many mid-week check-ins should each team have?

8. What are the common mistakes made by teams?

9. How will you deal with the conflicts below?

   • Safeguarding: someone is at risk, and you don’t know what to do.
   • Abusive behaviour: could include code of conduct violation.
   • Disengagement: a trainee or volunteer not participating
   • Poor technical contributions: The trainee is contributing, but the code is not good enough or actively bad; the team cannot deliver weekly releases

10. Would you hire this trainee? Why is this question important for trainees and volunteers to have in mind? And if you would not hire them, what should you do?

A quick break of fifteen minutes so we can all concentrate on the next piece of work.

The goal of this first meeting is to define what you will deliver as a team. When product teams work together, planning and preparation gets everyone on the same page. It means you might not be coding very much today, but will help you code more effectively over the weeks ahead.

Learning how to do this work will make you a better software developer and ensure you develop features that have value to your users.

Discuss and agree on the points below with your product team. Set a timer for 15 minutes ⏱ minutes.

Minimum Viable Product (MVP)

1. What is an MVP (Minimum Viable Product)?

2. How can you avoid increasing scope?

3. How do we define what should be part of the MVP?

Functions

1. What does it mean for your website to be interactive?

2. The product must be completed in four weeks of work. How can we make sure the scope is the right size?

3. Be well-defined: what artefacts 🧶 🧶 artefacts Readmes, docs, diagrams, kanbans, user stories… Artefacts are documents produced during software builds that describe and illustrate its functions. can we use to ensure all functions are well-defined?

4. Visual design complexity: how can we avoid making our user interface too complicated?

5. Answers to questions: trainees are learning, so how can we, as a team, learn without giving each other just the answers - or expecting immediate answers from your peers?

Define your product and features

To ensure we can keep the scope lean and everyone understands the product, briefing and features the same way, follow these steps:

Work on this Lean UX Canvas on this Miro board

1. Do a user story mapping (an example is on the same Miro board, Exercise 3.2)

2. Define the features that will be included in your MVP.

Hello, World!

What use are plans without delivery? The most common cause of failure in the Launch is not deploying our code.

We need to deploy our project to a live environment as soon as possible. It is better to have something than nothing. It is better to have a simple version of your project in use than a complex plan that is only a slideshow.

Build the simplest thing you can. Deploy it. Get feedback. Improve it. Repeat.

As a team, you should deploy your project to a live environment at least once a day. This is the best way to ensure that you are making progress in manageable steps.

Deploy your project to a live environment now. It can (and should!) just say “Hello, World!”.

Every Saturday we cook and eat together. We share our food and our stories. We learn about each other and the world. We build community.

This is everyone’s responsibility, so help with what is needed to make this happen, for example, organising the food, setting up the table, washing up, tidying up, etc. You can do something different every week. You don’t need to be constantly responsible for the same task.

When designing and defining mock-ups as a team, we bring to life our ideas. We discuss which one is the best and then define how we want to move forward.

With mockups, we can show stakeholders what the product might look like. Simple mockups keep it open for them to suggest changes in layout, images, colour, styles, etc.

1. Work on the exercise 3.3 on this Miro board
2. Validate your mock-up with stakeholders, business owners or any available user

When planning your work, you have two important aspects: 1) understanding the implementation constraints and opportunities and 2) writing your user stories.

Implementation details

Define the implementation details for your product. Discuss your implementation details. During the discussion, clarify the technical jargon so everyone can understand and be part of the discussion.

1. What information will we need and/or provide to do that? For example, what pages could you have, and which endpoints must you use?

2. What entities/resources/data will we have in the system?

3. What information do we need to store to achieve the goals? Define the collections in the database.

4. What are we going to need to expose to the React app? Examples:

5. 1. Are you going to have an endpoint for a resource?
   2. Do you need calculation or aggregation between the database and the frontend?
   3. What will the REST API look like?

6. We sketched out the page previously. Do we need to review it? How could we decompose them into separate components to work on?

7. Identify the “edges” between different tasks (e.g. you have to agree on an API so that the backend and frontend match up or on the props passed between a parent component and a child component)

Please feel comfortable and welcome to pray at this time if this is part of your religion.

If you are breastfeeding and would like a private space, please let us know.

AS A [role], I WANT [action], SO THAT [outcome]

Set a timer for 15 minutes ⏱ and write user stories for the planning session. When raising your tickets, you can have two types of tickets:

• a user story, which is focused on business value (Format: AS A [role], I WANT [action], SO THAT [outcome] + acceptance criteria [rules/scenarios])

• a technical ticket, which is a step in the direction of a user story (Background [why], acceptance criteria [rules/scenarios]

1. 5 minutes ⏱ Discuss and agree on the first 5 or 6 user stories that need to be done. Just use titles to identify them.

2. 5 minutes ⏱ Work on 1 user story and 1 technical ticket together as a team.

3. 5 minutes ⏱ Now, each team member chooses one ticket and writes it. Think about clarity so that anyone outside the team can understand it, too. They will be discussed in the next session.

Agile software teams often work in ‘sprints’: specific chunks of time where we commit to a development goal.

Goal: Get the homepage working.

We set a single goal and focus on reaching it together as a team.

This helps us work on the most important thing. We’ll have lots of ideas for different things we can build, and we don’t want to get distracted. And it should encourage us to work together as a team.

For this project, we’ll be doing 1 week sprints. So, we should plan and start a new sprint at the start of each week.

Sprint planning is the process of planning our week, specifically focused on our development backlog and picking which user stories to include. exercises:

Plan the sprint

1. As a group, review the Backlog of user stories on your Project Board

2. Discuss the user stories - make sure they all have a detailed description of what you need to build and check that everyone in the team understands them. You can check this by asking everyone - would you feel comfortable implementing this yourself? (if no, check why not and add more information)

3. Arrange the user stories in priority order - put the most important ones first. These stories should help us reach our MVP and solve customer problems faster.

4. Start moving the user stories from your Backlog column to the Prioritised column. Keep going until you have enough for a week of work - this is your ‘sprint’. Estimating how much you can do in a week might be tricky. Tip: not enough is better than too much. We can always add more later.

5. Describe your week of work as a goal in a single sentence. Keep it focused on your product, not the technology. For example, “Goal: Get the homepage working” is better than “Goal: Setup the SQL database.”

6. Post your goal to the class Slack channel, e.g. “This week’s sprint goal for the Amazing Coderz team is: Get the homepage working!”