Hasso-Plattner-Institut
Prof. Dr. h.c. mult. Hasso Plattner
 
Image by clement127 on flickr: https://www.flickr.com/photos/clement127/16141122160/ (CC BY-NC-ND 2.0)

Tips for New Scrum Coaches & Student Tutors

These notes represent some of the learnings and best practices of teaching teams of multiple iterations of undergraduate software engineering courses. They summarize some team antipatterns and pitfalls to keep an eye our for and hopefully help those new in the role of Scrum coach and tutor.

Preparation

In Scrum Meetings

  • Clarify expectations of team members regarding your involvement and role in this session
  • Be an active observer and take notes during meetings
    • The more specific notes, the better, concrete examples help in remembering the context later
    • Use + and - to tag your individual notes, to gain a better overview of the entirety of the meeting at the end
  • Observe  team dynamics
    • Is a team member being left behind? Is someone always taking a leadership role (possibly overriding others)?
    • Pay special attention to the relationship between the Product Owner (PO) and the rest of the team. Antipatterns to especially look out for:
      • The PO is perceived as a manager or the task master. Is the team exhibiting "working for the PO"-syndrome?
      • The POs see themselves mainly as a separate team, not as part of their own teams. Is the PO expressing an “Us (POs) vs them (devs)” attitude?
  • Give feedback to participants after the meeting, possibly without being prompted, especially in the beginning of the project
    • Give personal feedback concerning individual participants highlighting positives (and noticed opportunities for improvement, if you feel that is appropriate)
    • Try to limit or avoid negative personal feedback. Point out general concepts or improvement ideas instead, team members are usually aware of the issues.
    • Notify the team’s Scrum Master of identified issues and problems, if appropriate. Maybe they should intervene instead
    • Focus your feedback on the process in a team, not on the code/features that were produced in an iteration
  • In Sprint review meetings
    • Highlight the goal of the Sprint review as a celebration of completed functionality
    • Recommendation: All User Stories are already known and appraised by the team’s Product Owner at the start of the meeting
    • Reviews in individual meetings between team members that worked on a feature and the Product Owner
  • In Retrospective meetings
    • Keep the Retrospective Prime Directive in mind: https://retrospectivewiki.org/index.php?title=The_Prime_Directive
    • Focus on few items to be improved, maybe even just a single one in the beginning
    • Remind meeting participants to evaluate and track the progress of the action items identified in previous Retrospectives
    • If meetings become stale/unproductive, encourage the Scrum Master to include a Retrospective game

General

  • Be more of an ally to the team, be less of an (evaluating) teaching team member
  • Get to know the team you are coaching
    • Share a personal story or your experiences of working in Scrum teams 
    • Check into other teams to gain understanding of relative performance
  • Dealing with uncertainty or complex situations and questions
    • It’s okay not to have the answer immediately and to postpone: "Sorry, I don't know, I'll inquire"
    • Ensure everyone’s voice is heard regarding complex team issues: "This is a team decision", open up the question to the entire team: "What do you think?"

Acknowledgements

Special thanks to Frederike Ramin for kickstarting this collection!

 

Last updated 2020-12-18