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.

 
 

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 1 year ago

Public Feedback


    • 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 year 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)

      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.