Agile 4 ALL: RETROSPECT to EVOLVE how you work

All teams can take advantage of Agile principles and practices to reap benefits. Even non-Agile teams can Retrospectives to Evolve how  they work.

WHAT is a Retrospective in Agile?

A retrospective is a method through which teams constantly overcome challenges and evolve how they work together. The team collaboratively engage in a positive discourse and identify specific ways to they plan to improve. This typically occurs within a pre-define cadence of sprints / iterations.

Here is a great video by Mark Grove that explains the format in more detail:

It is critical that the purpose of the session is “Continuous Team Improvement” (also referred to as Kaizen), not venting or blaming. Comments provided have to relevant, expressed in a professional manner, and only to accomplish this point.

 

WHY is it used?

There are many benefits to retrospecting for teams:

  • Identification of ongoing product issues as well as opportunities
  • Improvement in team productivity and efficiency
  • Everyone’s voice and ideas counts resulting in empowerment and engagement
  • Higher level of team issue ownership and resolution (instead of simply escalating them to management)
  • Critical team interaction that typically results in increased team trust

 

HOW to take advantage of it?

Many other frameworks already have project reviews or postmortems. This however is a team-level retrospecting. Here are some recommended steps on how to incorporate it into your teams (including PMI / Waterfall / SDLC / Prince2 teams):

  • Proactively create a cadence for these meetings (e.g. once a month) by booking them well ahead.
  • Invite a specific team (5-20 people). Nor larger teams, break into few separate meeting with people that work closely together, then consolidate and share finding.
  • Allow people to enter comments and ideas ahead of time. This will make your sessions more efficient allowing more time for identifying action items and their owners.
  • For complex issues, perform root-cause analysis using fish-bone diagram or another method.
  • If team members are concerned about sharing certain information (e.g. backlash from management) then allow people to submit comments anonymously (e.g. survey, google docs, retrospective tools).
  • Future meetings start with review of which action items were completed.

 

WHO should facilitate it?

  • Ideally you want a person that does NOT have any answers. Avoid using Team Managers, Product Owners, or Project Managers directly involved. You will get more unfiltered comments, ideas, and action items.
  • Ideally use an independent trusted impartial third party that knows how to navigate difficult topics and group dynamics (e.g. Manager of another team). You will get healthier team dynamics and less finger-pointing.
  • If you do use agile frameworks in other teams, use their Scrum Masters / Chief Scrum Masters.

 

Please Note: Obviously, benefits are more substantial and even cumulative if your team is actually using a complete Agile framework like Scrum or Scaled Agile (recommended). But whether your team is just experimenting, in process of transition, or simply trying to learn… I hope this article helps you on your way.

 

Image credit: ScrumShortCuts.com

Leave a comment