Feedback Workshop 🗣️

Feedback is the foundation of effective collaboration. Both giving and receiving feedback are important communication skills to master.

Tips for Giving Feedback:

• Give feedback in the right context, being mindful of tone and its impact on the receiver.
• Give feedback in a timely fashion, be direct, and non-accusatory (assume positive intent).
• Give feedback privately.
• Sometimes it is also better to ask if someone would like feedback.

Tips for Receiving Feedback:

• Receiving feedback is crucial for measuring your progress and understanding unspoken expectations.
• Ask for feedback early and often. Asking for feedback late on a project or presentation can lead us to be less receptive to criticism.
• Not all feedback will always be positive, it is important to learn to take good and bad feedback in stride.

We will practice giving and receiving feedback today.

After the workshop today, participants will be able to:

• Choose a framework for giving clear, direct feedback depending on the scenario.
• Reflect on the impact of feedback on personal growth and team dynamics
• Apply feedback techniques to real-world situations, balancing critique with encouragement
• Apply techniques for receiving tough feedback

Set up 🌼

• Pair up into groups of 2

The Activity 🏆

First, read this article on mastering feedback in the workplace.

Read the following scenarios and role-play each. One person will be giving the feedback and one person will be receiving the feedback. After each scenario switch who is giving the feedback and who is receiving it.

For the person giving feedback, remember to:

• Be direct
• Use clear language
• Talk about behavior, not personality
• Be kind

For the person receiving feedback, remember to:

• Be available and approachable
• Accountable
• Steer clear of defensiveness
• Take a moment to reflect before responding
• Assume positive intent

Practice Giving Feedback [20 mins]

• Spend 3 mins on each of these scenarios.
• One person will be giving the feedback and one person will be receiving the feedback. After each scenario switch who is giving the feedback and who is receiving it.

1. Situation, Behavior, Impact (SBI) Framework

The SBI Framework structures feedback in the following order:

• Situation: Describe the situation
• Behavior: Describe the behavior observed
• Impact: Explain the effect of the behavior on you, your team, or the organization

Try Applying the SBI method to the following scenario: A teammate consistently misses deadlines and when they finally do deliver their tasks, they are often not of good quality tasks requiring the rest of the team to redo portions of their work.

Objective: Use the SBI framework for giving feedback. Practice addressing issues of accountability, responsibility, and time management without demotivating the person.

2. Observation, Feelings, Needs, and Request (OFNR) framework

The OFNR framework consists of four parts:

• Observation: Tell the other person the behavior you observe from them that is making you uncomfortable. “When I Observe…”
• Feelings: Explain how the person’s behavior makes you feel (happy, sad, angry, annoyed, excited, worried, scared, hurt, embarrassed, confused) “I feel…”
• Needs: Describe what you need from the other person (physiological, safety, social, esteem, self-actualization) “Because I need…”
• Request: Ask them specifically what you’d like them to do. “Would you be willing to…”

Try Applying the ONFR method to the following scenario: A team member gives an informative presentation that is too long-winded, going over an hour causing the audience to lose focus. This presentation will be used at the next client meeting which is only 1 hour long and needs to cover many other topics.

Objective: Use the (OFNR) framework to give the team member feedback. Practice providing feedback on communication skills, structuring information, and presentation techniques.

3. Actionable, Specific, Kind (ASK) framework

The ASK framework focuses on the following attributes:

• Actionable: Address the actionable issue
• Specific: Be specific in your request.
• Kind

Scenario: A colleague dominates team discussions, interrupting others or dismissing alternative ideas without considering them. His behavior is often seen as grating or rude by the team.

Objective: Use the ASK framework to give feedback. Start by addressing the actionable issue and be specific in your request. Make sure it is delivered in a kind and understanding manner. Address how their behavior affects group dynamics and encourage a more inclusive approach, allowing others to share their thoughts.

4. Goal, Reality, Options, Will (GROW) model

The Grow framework focuses on mentoring and guidance to give feedback

• Goal: Explore the individual’s goals
• Reality: Assess the current reality
• Options: Brainstorm options
• Will: Create a list of actions to commit to to achieve the goal

Scenario: A colleague is working towards a promotion to senior software engineer and has asked you for feedback on their performance. Although they have great technical proficiency you have noticed that they do not speak up during meetings unless directly asked and often wait for tasks to be assigned instead of taking initiative.

Objective: Use the GROW model to speak with your colleague.

Choose a Framework for Giving Feedback [10 mins]

We have looked at the following frameworks for giving feedback:

• Situation, Behavior, Impact (SBI) - Describe the situation, detail the specific behavior observed, and explain the impact it had.
• Actionable, Specific, Kind (ASK) - Start with an actionable issue, be specific in your request and make sure it is delivered in a kind manner.
• Observation, Feelings, Needs and Actions (OFNA) - discuss an observation, how it made you feel, what needs to happen to rectify this behavior and the actions they can take.
• Goal, Reality, Options, Will (GROW) model. Explore the individual’s goals, assess the current reality, brainstorm options, and commit to action. This model is best suited when the individual is already aware of the area to improve.

For the following scenarios, discuss with your partner which framework you think should be applied.

1. Behavioral Feedback

Scenario: A team member frequently arrives late to meetings, affecting the team’s schedule.

2. Positive Feedback for Improvement

Scenario: A colleague made significant improvements in their work, but there’s still room for further development.

3. Conflict Resolution

Scenario: Two team members have a disagreement about how to approach a project, leading to tension in meetings.

4. Performance Review

Scenario: You are giving a formal performance review to a team member whose work has been solid but lacks creativity or initiative.

5. Cross-Team Collaboration

Scenario: A team member from another department is not communicating well with your team, leading to delays and confusion.

Reflection 🧘‍♂️ [10 mins]

Come together as a group and discuss the following:

When giving feedback:

• What challenges did you face when delivering feedback?
• How did you decide which feedback framework to use? Would you choose the same framework in real life?
• Which framework do you find the most useful? Which did you struggle with the most?
• How did you balance providing constructive criticism with being supportive?
• Did the scenario feel realistic or exaggerated? How would you adapt your approach in a real-world situation?
• How do you think feedback methods can differ depending on the person or context?

When receiving feedback:

• How did the feedback make you feel? Was it easy to remain open to feedback?
• Were there any moments when you felt defensive? How did you manage those feelings? How might you manage those feelings in real-world scenarios?
• Was the feedback clear and actionable? How would you apply it to improve?
• How can you proactively seek out more feedback from your peers or mentors?

Instructions

This workshop aims to check your understanding.

Each task will explain whether or not you should run the code.

For each task, you can use Data Groups Sprint 1 prep to help you with the questions. You can also use documentation to look up any functions that are unfamiliar. Don’t use ChatGPT or any other AI tool to help you.

🧰 Setup

1. Get into pairs or groups of up to three.
2. Make sure you have a clone of the CYF-Workshops repository on your local machine

This workshop can be found here 👉 https://github.com/CodeYourFuture/CYF-Workshops/tree/main/arrays In this workshop, each file contains a different problem at a particular level.

You should start this project at Level 100 and then move through the levels in ascending order, level 200, 300 etc.

➡️ Go to Level 100

Why do we test?

How do you check if your code is working? You could test it manually, e.g.

function greet(name) {
  return `Hello ${name}`;
}

let name = "Ellie";

let result = greet(name);

console.log(`Expect ${result} to equal Hello Ellie`);
// Expect Hello Ellie to equal Hello Ellie

A simple console.log can verify that our code behaves correctly. But this approach isn’t very robust. What happens if I want to change my function?

function greet(name) {
  return `Hi ${name}`; // <-- I changed the greeting
}

let name = "Ellie";

let result = greet(name);

console.log(`Expect ${result} to equal Hello Ellie`);
// Expect Hi Ellie to equal Hello Ellie <-- I didn't change the console.log, so how do I know if my function is meant to greet with 'Hi' or 'Hello'?

Our console.log is helpful if we remember to check the output, but a testing tool, like Jest can tell us if our code works or not more clearly.

Why do we use automated tests?

• You can be more productive because you don’t have to spend the as much time manually testing the code yourself
• Tests allow you to make changes in your code quickly and safely without breaking the existing behaviour
• Tests provide documentation for what your code is actually meant to do

Why do we use test driven development?

• It helps us write better code. Code that can be easily tested tends to be cleaner and more modular
• It helps us break down the problem into smaller chunks
• It encourages us to think about edge cases (the less likely paths in our code)

Pair exercise

• Use test driven development in pairs to complete this exercise

  • person A should write a failing test
  • person B should make the test pass by implementing the code
  • person A should refactor (if necessary)
  • then start again, this time person B writes the failing test

• Write a function that

  • takes a number as an argument
  • returns a string of comma separated numbers from 1 to the number passed in
  • for every number that is divisible by 3, the number should be replaced by ‘fizz’
  • for every number that is divisible by 5, the number should be replaced by ‘buzz’
  • for every number that is divisible by both 3 and 5, the number should be replaced by ‘fizzbuzz’

Examples

Given 1, the function should return “1”.

Given 15, the function should return “1, 2, fizz, 4, buzz, fizz, 7, 8, fizz, buzz, 11, fizz, 13, 14, fizzbuzz”.

Running the tests

cd testing

npm i

npm run test