Smart way of choosing Retrospective Technique

There are many retrospective techniques available and its a widely discussed topic too. But every sprint and release is different with respect to outcomes and learnings. The Scrum Master need to have the expertise to chose what technique or Agile game for Retrospective event so that it opens up healthy discussion and best learnings from the time boxed event. Example, Speed Boat is a great Retrospective technique, but may not be the best during the first or second sprint. Similarly, in case of release retrospective, where relatively large number of audience are present, there are multiple things to consider while chosing the format of Retrospective, like do you have a distributed audience, the number of audience, to what extent was their work co-ordination needed during the release, etc.

Hence, chosing the right Retrospective Technique is an art, and in this session we will discuss practical situations and what retrospective technique works best in those situations. I will discuss the tried and proven techniques based on my experience. I will share what retrospective technique worked when the team was newly formed, when the Scrum Master was new to an old team, when the team was continuously unable to meet sprint commitment, and a few practical ways of effectively facilitating the event for large audience.

 
15 favorite thumb_down thumb_up 9 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Presentation

Introduction - 2 mins

What type of Retrospective techniques to use based on Sprint Outcome? - 20 mins

  • Real time examples of Sprint Outcomes
  • Retrospective Technique chosen
  • What were the learnings?

Effective Retrospective for large audience (30+) - 10 mins

  • Real time Release Outcomes
  • Retrospective Technique chosen
  • What were the learnings?

Question & Answers - 8 mins

Learning Outcome

At the end of the session, audience would be able to think of innovative and interesting ways of doing retrospectives. They would understand what technique/game to chose based on their sprint/release outcome. They would be able to understand how to facilitate retrospective event effectively for large audience (30+).

Target Audience

Scrum Masters, Developers, Agile Coaches

Prerequisites for Attendees

Basics of Agile & Scrum

schedule Submitted 3 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Sanjay Kumar
    By Sanjay Kumar  ~  2 months ago
    reply Reply

    Hi Satya,

    Good topic! Curious to know how many retrospective formats do you plan to share, and if you don't mind, which ones?

    thanks!

    • Satya Jyoti Yellapantula
      By Satya Jyoti Yellapantula  ~  2 months ago
      reply Reply

      I would want to start with how to set the retrospective mood, through simple games, so that the most important things get the right focus. Example,

      Situation 1: During the sprint, development team did not swarm on stories, and continued to work all stories in parallel, and ended up not with incomplete stories during the end. 

      In this situation I recommend to use a simple game called "Pictionary", where we divide the the team into groups of two each. One is given a picture, and asked to describe it using geometrical figures, and the other is supposed to draw it. In time box, the team of two need to draw as many things as possible from the picture given. From this game, I will try to bring the importance of "Stop Starting, and Start Finishing". And then open the room for retrospective using any technique - Stop, Start, Continue, or something similar.

       

      Situation 2: During code review, there were a couple of inputs given by the team, but the team member working on that part of the code, missed to implement one of the review comments, and confirmed all the suggested changes are made. On the last day of the sprint, the team discovers that the most critical change was missed, and every member gets a feeling that the story remained incomplete because of this one team member. 

      In this situation, I will make the team play a small game with paper (fold and tear by blind folding everyone and giving a series of instructions). Through this game, I would want to bring the understanding to the team that what we hear could be same, but how it is understood by each individual is different. There is nothing wrong in this, and no one would want to do a mistake intentionally. After this I will start the retrospective with "Six Thinking Hats"

      I would discuss around 8 different practical situations, and what retrospective technique/game worked best as per my experience for each of these situations. One of two of these situations would discuss how to facilitate this event for distributed team, and for large audience (Ex. Release Retrospective) Please let me know if this answers your question.

      • Sanjay Kumar
        By Sanjay Kumar  ~  2 months ago
        reply Reply

        Hi Satya,

        Thanks for sharing details.

        It looks good. My only concern is time. Will you be able to cover all this in 35 min and leave some time for questions? It is fine if you are confident, else you may consider running one activity (six thinking hats?), followed by theoretical description of some additional formats.

        Just a suggestion... you should know better.  :-)

        • Satya Jyoti Yellapantula
          By Satya Jyoti Yellapantula  ~  2 months ago
          reply Reply

          Thanks for the inputs Sanjay. I would re-think and try to limit the scenarios to 5, with an activity for one of the techniques in detail. Would rehearse and see how much time it takes :)

          • Madeeha Khan
            By Madeeha Khan  ~  2 months ago
            reply Reply

            Hi Satya, based on your above comments, can you please update the proposal. Also, you may finalize if there will be 5 scenarios and given time is manageable.

            Further, can you please share links for previous talks/video/ slides. Thanks.

            • Satya Jyoti Yellapantula
              By Satya Jyoti Yellapantula  ~  2 months ago
              reply Reply

              Sorry for the delay on this Madeeha, I will upload the deck by Sunday.

              • Satya Jyoti Yellapantula
                By Satya Jyoti Yellapantula  ~  1 month ago
                reply Reply

                Uploaded the first draft of the presentation. Please let me know your inputs.

                • Madeeha Khan
                  By Madeeha Khan  ~  1 month ago
                  reply Reply

                  Thanks Satya. If we need further input, we will inform you. Meanwhile,the team will review it.Thanks.

  • Chandan
    By Chandan  ~  2 months ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • Interesting topic

    I think the submission could be improved by:

    • In a 2 week sprint cycle, monthly there are 2 retrospective meeting, where team asks 3 questions as prescribed by Scrum Guide. In a year team does approx 20 retrospective meetings. For scrum master to run all these 20 retro meeting effectively, will you share tips on how to engage a team with various retro techniques for complex technical projects where teams are geographically distributed? Many Scrum masters will be very happy as it will make their life easy

  • Liked Bhanu Golconda
    keyboard_arrow_down

    Bhanu Golconda - Agile - An era of "Asking" (with insights from a survey)

    Bhanu Golconda
    Bhanu Golconda
    Scrum master
    Pega Systems
    schedule 1 month ago
    Sold Out!
    45 Mins
    Presentation
    Intermediate

    One of the prime goals of successful Agile transformation is creating self-organised teams. Teams become more self-organised by simply questioning Who will do What, Why, How and by When? While this sounds simple, just like Agile transformation, it is not easy. With small steps, incrementally, we can improve Team's asking skills.

    This presentation highlights the importance of "Asking" and lays its foundation on a survey, which I conducted recently. The results of the survey clearly show that teams, which did more asking, have witnessed effective value delivery more often. In the process, the presentation also introduces two new measures called "Team asking quotient" and "Value Delivery quotient" which is derived from 7 important areas that determine the overall asking maturity of a team.

  • Liked Vamsi Krishna Kakkireni
    keyboard_arrow_down

    Vamsi Krishna Kakkireni - Agile for Customer Delight – It's neither B2B nor C2C, it's H2H (Human to Human)

    Vamsi Krishna Kakkireni
    Vamsi Krishna Kakkireni
    Scrum Master
    Pegasystems
    schedule 2 months ago
    Sold Out!
    45 Mins
    Presentation
    Intermediate

    Surveys say that 87% of consumers would pay more to a company that provides a better overall customer experience. We can anticipate the customer needs better only by having a deeper relationship with customers. With that we can react faster to changes in the market than the market laggards.

    • What is customer delight?
    • Where do we stand w.r.t. customer experience?
    • How to assess the maturity of our Agile processes?
    • How Agile helps us in driving customer delight?

    This session answers all the above questions by proposing the following:

    • Assess your customer experience by calculating Customer Experience Maturity Index (CXMI)
    • Assess the maturity of Agile process by calculating Agile Maturity Index (AMI)
    • Hardening Index (HI) and Happiness Index (HI)
    • Model drive customer delight.

    This presentation will provide calculators, experiences and suggestions in achieving customer delight.

  • Liked Sivakanth
    keyboard_arrow_down

    Sivakanth - Can Velocity be an indicator of a Scrum Team's Maturity?

    45 Mins
    Presentation
    Advanced

    First things first, why "Velocity" alone, when there are many other factors (requirements, estimations, defects, automation etc) which would help arrive at a Team's maturity? So, with so many other factors in the ambit, why does this session emphasizes on "Velocity" alone, while I could have just easily entitled this session as "Various factors influencing a Team's Maturity"?

    Let me start with the statement that "The more the velocity, the more the more productive the team is and hence more matured". It sounds fairly correct right? A team with more velocity is more likely capable and productive and hence more matured. Isn't it?
    But wait, consider this!
    > What if the team has shown significant "progress" in increasing their velocity but at the cost of team's burnout?
    > What if the team has increased their average velocity by X percent but has compromised their quality?
    > What if the team has padded their product backlog with the list of stories which are more of "non-functional" in nature which don't necessarily add any business value?
    > What if the team has "bloated" their velocity unusually by sometimes(or many-a-time probably) by projecting simple tasks as stories-with-a-business-value?

    Can the team be branded a matured?

    And the reason as to why the team resort to such anti-patters to "save their velocity" is because "Velocity" which is ought to be the primary measure of a Team's progress, has metamorphosed into a "performance metric" leading to the teams (their leadership hierarchy too) becoming conscious or (rather "obsessed" in many cases) with Velocity so much so, that in order to "preserve" or "increase" their velocity, teams can resort to anti-practices such as extending the sprints, bloating the story points, add stories that don't add value only to "maintain" velocity.

    Having said that, while its true that Velocity is certainly a critical indicator to measure of the amount of work a Team can accomplish in a sprint, it should also be seen in the context of the team's ability to maintain a consistency in achieving the velocity and at the same time, take a closer look at the team's definition of velocity itself.

    Notwithstanding the above points and considering that a team gets them all right, can we then say that Velocity drives a team's maturity? To an extent, Yes. Velocity can be an indicator of a Team's Maturity but it cannot be the ONLY factor determining it. Among other factors, Maturity can also encompass how effectively the team tackles the dimensions such as "planning", "quality", "practices", "communication and collaboration" etc. (the list is exhaustive).

    It is in this context that this session aims to throw some light on what "Maturity" and how "True Velocity" can contribute to a Team's maturity and discuss about numerous other factors that contribute to a team's maturity, such as a team's ability to break the silos and "self-organize" themselves, adhere to "practices", learn to cultivate "mutual Trust", "team commitment","collective ownership" and many more.

  • Liked Sivakanth
    keyboard_arrow_down

    Sivakanth - Being a Scrum Master ain't an "extended" responsibility. It's a role in itself.

    20 Mins
    Talk
    Intermediate

    The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.

    As defined in the Scrum Guide, the role of a Scrum Master is responsible for promoting and supporting Scrum, by helping everyone understand Scrum theory, practices, rules, and values.

    But in practice, we often see this important role as an "extended" role, an "additional" responsibility, usually played by project managers or any of the senior member of the team who is expected to "make things work". This role is often pushed into a dilemma between the "expectations" (to solve every other problem that the team faces) and "reality" (to take a step back and let the team get empowered to solve their own problems).

    While the role includes facilitating a conducive work environment for the Scrum Team, guiding and teaching Scrum practices to everyone involved in the project and clearing impediments for the team, it also includes facing resistence from the teams, management, stakeholders and sometimes, probably of all them put together. The challenges could vary from "Time-boxing the Daily Scrum Meeting to 15 minutes" to "the extent of owing the team's deliverables on a whole".

    This session aims to take a realistic look at the usual challenges (and probably any unusual ones too) that the Scrum Masters face and try to understand some best practices centered around this role as an outcome of the discussion.