Skip to content

Latest commit

 

History

History
288 lines (203 loc) · 18.2 KB

learning_to_pair.md

File metadata and controls

288 lines (203 loc) · 18.2 KB

Learning to Pair: How to Define the Relationship and Hold Each Other Accountable

Slides for the Session

Facilitator Instructions

There are facilitator notes throughout this markdown to divide up responsibilities in the session, assuming there are 2 instructors (1 BE and 1 FE) in the session. Please read through this markdown ahead of the session, decide who is going to be Facilitator #1 and who will be Facilitator #2, and let Allison know if you have any questions.

Session Structure

Length: 60 mins

Facilitator #1: Using slide #2-6, go through the following:

Slide #2:

  • Opening (why, objectives, and turn & talk): 5 mins
  • Types of Pair Programming & Intro to DTR: 5 mins
  • Relating Styles: 15 mins
  • Journal: Define Your Expectations: 5 mins
  • Compromising & Accountability: 5 mins
  • Crucial Conversations: 10 mins
  • Practice: 5 mins
  • Debrief & Closing: 5 mins

Objectives:

Slide #4:

  • Identify various forms of pair programming
  • Understand what DTR is and how to hold a DTR conversation
  • Understand how your Relating Style causes you to interact with others
  • Define your own expectations in a working relationship
  • Apply strategies to hold your partners accountable
  • Demonstrate how to address broken expectations

Deliverable:

  • Complete a DTR memo for at least one project using this template and submit it here by 5pm on Monday of Week 2

Opening

Slide #5:

Pairing with other programmers is an essential practice, and building your pairing skills will help you be successful in projects at Turing and in the workplace. Pairing effectively comes down to establishing a relationship with the person you’re working with. This starts with breaking down communication barriers and building trust within the working relationship.

Turn & Talk

Slide #6:

Turn and talk with the person next to you to share:

  • In the past when you've worked in teams, what has it been successful?
  • What has it been unsuccessful?

You'll often find similar experiences happen in pair programming. This session will help you discover tools to navigate this relationship in a way that it's a great learning experience for you both.

Facilitator #2: Using slides #8-10, go through the following and call on students to discuss what's helpful in each style of pair programming and when they might want to try out different styles:

Types of pair programming

Slide #8:

Pair programming can take many forms, and here are some suggestions of how you can approach pairing at Turing:

  • Driver-Navigator: Driver has control of the keyboard while the Navigator guides the Driver towards the end goal.

    Roles: Driver types and hones muscle memory through minute-to-minute typing while the Navigator pays attention to the code being written

    Tips: Switch these roles up throughout a work session!

    Potential pitfall: The Navigator stops paying attention, and the Driver starts doing their own thing. Active participation and constant communication is crucial for this pairing to be successful.

  • Ping Pong pairing: This looks like side-by-side pairing and could include 2 mice and 2 keyboards.

    Roles: Ping pong pairing is especially effective when writing tests. Team Member 1 can write a test while Team Member 2 can make the test green. Or the responsibility for making the test pass can switch back and forth (or ping pong, if you will) -- Team Member 1 could write test, Team Member 2 makes it green and then writes another test, Team Member 1 then makes that test green and so on.

    Tips: Control can be passed back and forth frequently here, but in order to target what each person needs in their learning, it requires communication. If one member has more expertise in a certain area, this is both a great way for that person to exercise that knowledge and directly give feedback to the person who is learning to get better in that area.

    Potential pitfall: Not setting expectations ahead of time could make it more difficult to decide who is doing what.

  • Distributed Pairing (Remote Pairing):

    Roles: You can incorporate either Driver-Navigator or Ping Pong during a remote pairing

    Tips: Invest in a good headset; Experiment with Slack calls where you share your screen to build your comfort with using it; Spend longer on the DTR (covered next) to get to know each other; Be more vocal about when to switch Driver and Navigator roles

    Potential pitfall: Technical issues when pairing remotely are common, so test your tools ahead of time!

Defining the Relationship (DTR)

Slide #9:

DTR refers to a conversation each student has with group partner(s) before launching into a project. During this conversation, group members set expectations for how to work together. Use this DTR Guiding Questions & Memo template to guide the conversation.

Note to Facilitator #2: Share the DTR guidelines & memo template in the cohorts' channels and cold call a few students to discuss the follow questions:

Discussion Questions:

  • What do you notice about these guiding questions?
  • What would you need to keep in mind when answering these questions with your partner?
  • How can you use this template to make your project successful?

Establishing a relationship with your mentor should also include a DTR. Here’s a cheatsheet for planning that conversation.

Facilitator #1: Using slides #12-16, discuss the following information on communication and relating styles:

How We Communicate:

Slide #12:

Let’s look at the 3 ego-states from Eric Berne’s Transactional Analysis:

  • Parent: Our taught concept of life; shown by a need to control or nurture. We demonstrate this through behaviors, thoughts, and feelings copied from parents or parent figures.

  • Adult: Our thought concept of life; shown through using reason and maturity. We demonstrate this through behaviors, thoughts, and feelings that are direct responses to the here and now.

  • Child: Our felt concept of life; shown through how easily we can adapt to new situations or desire to rebel & exercise freedom. We demonstrate this through behaviors, thoughts, and feelings replayed from childhood.

This blog post gives an excellent breakdown of these different ego-states in action.

Our Ideal Communication vs. What Often Happens

Slides #13-14:

When working and communicating with others, we all ideally hope that we are utilizing our Adult ego state, reflected in reason, maturity, and connecting to the present moment, and we hope that we are aligned with our teammates.

However, in reality, we are often accessing our Parent and Child roles or using ego states that are misaligned with others:

  • Complimentary: This occurs when communication styles line up; either shown by Adult-Adult or Parent-Child. It is easier to communicate when these styles complement each other since we are not at cross-purposes, and there will be less of a chance of misunderstanding.
  • Cross: This occurs when our communication styles do not line up. We might pose a question from an Adult ego state, but the person receiving it reacts from a Parent or Child ego state. When this happens, misunderstandings are frequent.
  • Ulterior: This involves unspoken and inferred communication. Communication is spoken, but the person receiving it hears a different intent.

A lot of this misaligned communication comes down to a mismatch of intent and impact, which we'll talk about more in-depth during the Feedback I session next week.

Want to know more? Pairin measures this!

Slide #15:

Pairin breaks down these 3 ego states into 5 Relating Styles:

  • Parent: Correcting Others or Enriching Others
    • Needing to control vs. needing to nurture
  • Adult: Responsibility
    • Using reason and maturity
  • Child: Approval Seeking or Playfulness
    • How easily we can adapt to new situations vs. desire to rebel & exercise freedom

Note: your Relating Style is not listed in your Top 4 qualities; ask Allison to create a report for you on this if you want to know more.

Pairin Example: Facilitator #1: Cold call 1-2 people: Using the chart on Slide #16 which shows the relating styles of the Parent Ego state across both cohorts:

  • What do you notice about your cohorts?
  • How could people work together across opposite sides of this spectrum?
  • What should these people be aware of to keep from having cross purposes when communicating?

Facilitator #2: Using Slides #17-19, go through the following:

Journal Reflection

Slide #17:

Define your own expectations by reflecting on the following questions in your journals:

  • Define your strengths
  • How do you work best?
    • Where do you land on the introvert/extrovert spectrum?
    • What do you need your partner to know about working with you?
  • Describe how you want to work with someone else
    • How do you relate to others when collaborating?
  • How do you appreciate communication?
  • What does Git workflow look like for you?
  • Imagine that you might be working with someone with a very different personality than yours
    • How can you communicate your expectations so that you’re on the same page?

Compromising with Each Others’ Expectations

Facilitator #2 says: How many of you are early birds? Now, how many of you are night owls? Let's say the early birds and the night owls get paired up, how could they worked together successfully?

  • Solicit answers from the cohort on strategies for working together.

Slide 18:

  • Beware of the Paired Project Fallacy:
    • My partner is better than I am OR My partner is holding me back.
  • Why is this a fallacy?
    • This is a fallacy because it discounts all the important skills you both bring to your partnership.
    • If you don’t feel as strong in your technical skills, what are your strengths? How do your strengths balance out your partner’s? How can you contribute to the project management? What do you want to learn during this project to improve your technical skills?
    • If you feel like you have stronger technical skills, teaching your partner will help you solidify these skills. Alternatively, what can you learn from your partner?
    • Beware of the "Developer's Ego"; learning to ask questions is an important skill for the workplace.
  • Bottom line: Paired project code is owned by the entire team. There is no room (and no time, considering your tight deadlines) for egos -- you are here to support each other.

Holding Each Other Accountable

Slide #19:

  • Memo: Documenting your DTR in a memo will provide you with a record of what you discussed to reference as the project goes on. Make it into a gist so that everyone from the group has it.
  • Stand Up: Start each work session discussing what you are each working on that day and what goals you hope to accomplish at the end of the work session.
  • Retro: Hold regular retros to discuss what’s going well, what’s not going well, and what you should change as a group to make your project and team more successful.
    • We'll talk about retros a little more in week 4.
  • Re-DTR: In longer projects, review and readjust expectations midway through the project.

Facilitator #1: Using Slides #21-25, go through the following:

Using Crucial Conversations

On Slide 21, Facilitator #1 says: Consider this scenario -- you ask a friend to pick you up from the doctor's office and take you to school. This is a really good friend, one you've relied on often. And right now, they're late. What's going through your mind?

  • Solicit 1-2 responses from the cohort.

Then say: Ok, actually this friend is not that reliable. They've been late before. Sometimes they don't return your messages. And now, they're late, and you're going to be late to class. Now, what's going through your mind?

  • Solicit 1-2 responses from the cohort.

Now say: We often go from thinking about external circumstances influencing someone's behavior to starting to make assumptions about that person. That's called the Fundamental Attribution Error.

Now, let's say your friend gets here finally. You get in the car, and your friend is giving all sorts of excuses ("Sorry, I had to take my dog to the vet, and then I had to call my grandma, and then there was a ton of construction so I had to take a detour..."), and you just say, "it's fine." What have you just done?

  • Solicit 1-2 responses from the cohort.

You've reacted with silence; also known as passive aggression or enabling. You have not addressed the issue.

Let's say, you get in the car, they give you their excuses, and you really let them have it, yelling at them about what a bad friend they are! What have you just done?

  • Solicit 1-2 responses from the cohort.

You've reacted with violence; also known as aggression. You also have not addressed the issue and maybe have ruined a relationship over it.

Addressing Broken Expectations

Slide #22: When a partner is not following through on expectations, the first step is to work on yourself:

  • How are you reacting?
    • Silence (avoiding the situation; passive aggression; using sarcasm). By not addressing the situation, it looks like you actually approve of what the other person did.
    • Violence (yelling; personal attacks). By reacting this way, it looks like you are hard to work with and are abusive when things don’t go your way.
    • Fundamental Attribution Error. This error comes from an assumption that others are doing contrary things because it’s part of their makeup or that they don’t care rather than considering other potential motivational forces

Slide #23:

  • How to fix these reactions:
    • Humanize the situation: analyze why the other person could have broken these social norms
    • Consider the 6 Sources of Influence:
      • Personal:
        • Motivation (does the person want/not want to do this?)
        • Ability (does the person have the ability to do this or not?)
      • Social:
        • Motivation (peer pressure -- from teammates, instructors, etc.)
        • Ability (what help does your partner need from others?)
          • Think about how you’re contributing to the social aspect as well: pay attention to body language, tone of voice, etc.
      • Structural:
        • Motivation (deadlines, grades, etc.)
        • Ability (What is structurally holding you back? Do you need a better organizational system? Trello, waffle.io, etc.)

Facilitating the Conversation

Slide #24: Now that you’ve identified a motivation behind your partner’s behavior, how do you conduct a conversation to change that behavior?

  • Establish safety: you’re about to address something sensitive with another person and they may feel threatened in one way or another.
    • Mutual Respect: People feel unsafe when they don’t feel mutual respect
      • Fix: calm tone of voice, facial expressions, and using respectful language
      • Ask for permission to speak with your partner
      • Speak in private
    • Mutual Purpose: People feel unsafe when they don’t feel that there is a mutual purpose for resolving the problem
      • Fix: Phrase your conversation around the goals of the project instead of you vs. your partner
  • Use Contrasting: “Don’t/Do Statement”
    • Example: “I don’t want you to think that I don’t value your ideas. You’ve contributed a lot of great ideas to the project. I do want to talk about how we could discuss ideas as a group before making a decision.”
  • Describe what’s happened:
    • Start with Facts. What exactly happened? Be careful of NOT inserting your opinion of what happened.
      • “We agreed that we would make big decisions together, but during the check-in, you told our instructor that you had already decided to implement that new feature before you discussed it with me.”
    • Describe how the incident made you feel:
      • “When you said that, it made me feel frustrated because I didn't think you valued my input and you weren’t taking our expectations seriously.”
    • Ask for the other person’s side:
      • “What is your take on this?”

Slide #25:

  • Following up after stating your side:
    • Listen to the other person’s side
    • Analyze the response & go back to the 6 sources of influence:
      • Is the problem due to motivation or ability?
      • Discuss consequences related to your mutual purpose:
        • “If we don’t make decisions together, our project will suffer.”
      • Discuss new expectations if the issue is motivation:
        • “It sounds like you made that the decision because you felt pressure from the instructor to have a new idea in place at the check-in. Let’s redefine our goals for each check-in.”
      • Discuss finding resources if the issue is ability:
        • “You made the decision because you couldn’t reach me. Let’s find 3 mutual times we can check in throughout the day.”
      • Create action steps:
        • Re-DTR: who will do what and when?

Facilitator #2: Using Slides #27 & 28, go through the following:

Practice

Slide #27:

Scenario: During DTR, Partner A and Partner B decided that you would have an end of day retro to debrief how the worktime went. But at the end of the first day, Partner A left abruptly right after class and didn’t meet with Partner B for their retro. Then in day two, Partner A doesn’t have a task finished that was promised to be done. Partner B is worried about time and how to proceed when Partner A seems unreliable.

  • Decide who Partner A is and who Partner B is and use the ideas we’ve discussed to have a conversation to address the issue and reset expectations
  • What assumptions need to be addressed?
  • How will you conduct the conversation?

Debrief by calling on 1-2 people: what was easy or difficult about having this conversation?

Closing

Slide #28:

Share out takeaways:

  • What is DTR?
  • How do you hold each other accountable to expectations?
  • What will you do if expectations broken?
  • What steps will you take to have that conversation?