Agile Retrospectives based on Continuous Process Improvement

Agile Retrospectives are talked about and practiced my many teams, at varying levels across the globe. But more often than not, while these retrospectives are carried out with great fervor, teams often struggle on following up. This struggle is greater when teams begin to follow Agile.

Effective Retrospectives create learning teams and helps aid continuous process improvement.

In this talk, we'll walk you though a technique that applies continuous process improvement practices to help you many your retrospectives effective, easy to follow-up and measure your progress over the course of time.

In the 45 minutes of this interactive Talk, you will learn a very useful technique to interacting with teams and effectively communicating with "management" and other key internal stakeholders on the roadmap to continuous improvement.

1 favorite thumb_down thumb_up 3 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session


    • Quick 5-minute Introduction
    • What is Continuous Process Improvment?
    • How can Continuous Process Improvement help Agile teams?
    • What are retrospectives?
    • How are Agile Retrospectives practiced and what is the gap?
    • How is this different from Agile Retrospectives practiced today?
    • How to gain mindshare for practicing Continuous Process Improvement in Agile teams
    • How are goals important? What are they?
    • How to plan for one?
    • Learn the technique
    • How to effectively practice this technique beyond your retrospectives?
    • How can this technique benefit your organization?
  5. WRAP-UP


Learning Outcome


  • Understand how to plan for effective agile retrospectives
  • Learn the tools and techniques to continuous improvement
  • Understand "continuous process improvement" and its benefits
  • Apply "continuous process improvement" practices to other aspects of Agile Project Management / practices
  • Conduct Agile Retrospectives based on Continuous Improvement models
  • Learn how to gain mindshare from key stakeholders to introduce this practice by presenting the business benefits of doing this


Target Audience

Product Owners, Scrum Masters / Project Managers, Portfolio Managers, Founders / CEOs, Developers

schedule Submitted 5 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Ellen Grove
    By Ellen Grove  ~  5 years ago
    reply Reply

    I'm intrigued.  The topic is interesting, and I can see that you've thought through the process for your talk.  I went to your blog and couldn't find anything about retrospectives or your technique - might you share a little bit more about what the secret sauce is?  I'm also curious to know whether this will really fit into 45 min - have you delivered this talk previously?

    • Karthik Vijayakumar
      By Karthik Vijayakumar  ~  5 years ago
      reply Reply

      Sure, I understand that was a little vague. Let me quickly explain.

      I've liked the approach described by Ester Derby and Diana Larsen in Agile Retrospectives and have followed that for a many retrospectives. I've found it work very well in getting the teams to collaborate and interact to identify the good / bad in people / process. That said, I've seen that people have had a challenge in effectively following up on the retrospective based on the 2 or 3 goals we choose to achieve during the course of a sprint or a release.

      I tried to modify the process a little bit. Instead of trying to dot-vote on the ideas for improvement, I introduced 4 stages:

      1. Identify goals

      - Some goals in a release retrospective could be "Process Improvement", "Realistic Release Goals", "Improve Design and Review Process", "No Weekend Working", "Manage Doing Spikes Better", etc.

      2. Identify ideas to achieve those goals

      3. Create a Goal-Impact cascade - The idea here is that no goal is independent of the other.

      - In other words, this explains that any action you take towards addressing one goal, has an impact on the others (this can also be looked as a goal-breakdown approach. Edward de Bono refers to this as a "Concept Fan" approach to thinking)

      4. Shared Ownership of Goals - This is a stage whereby the teams work together to own one or more of the goals.

      - This is a stage where I involve external stakeholders. In organizations that are in the Agile-adoption stage and in organizations which are top-heavy, I involve relavant people from management / Center of Excellence (for trainings, IT infrastructure, budget sanctions, etc)

      While we do "close the retrospective", I recommend the teams keep the Goal-Impact cascade in a big paper chart and follow-up during the following sprint retrospectives. This Goal-Impact Cascade is a great way to visualize and measure progress because -

      -- It is a great visual tool to see how goals are interrelated

      -- The tool, when shared and discussed with all stakeholders, establishes shared-ownership - I usually recommend a "I Own My Goals" chart here (as described above)

      -- It helps in measuring progress as a whole, and not about "local optimums" - It's not good if the organization has "Realistic Release Goals" or "Well Planned Releases" when teams are "Work all Weekends" or "Code and Review Process is bad".

      -- The technique helps teams gain newer insights into various aspects of the process and related areas

      Can this be done in 45mins? - I chose to go with 45minutes as I've done this session for a couple of teams in the past in roughly about that time. I will not spend much time going in-depth into Agile Retrospectives in this session. It will be great if there was a 60minute slot as that will allow for extra time for Q & A.

      Apologies for the bad formatting. The editor doesn't seem to support bulleting well.

    • Karthik Vijayakumar
      By Karthik Vijayakumar  ~  5 years ago
      reply Reply

      Hope my Private Message did offer some insight into this topic. Please let me know if that doesn't work.

  • Liked Vinodhini

    Vinodhini / Thushara Wijewardena - Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile

    20 Mins
    Experience Report

    Here is a case study of how agile outsourcing can be practically applied even when the business domain is very complex and alien to offshore teams.
    The example is a project in which Exilesoft provided for a leading Norwegian producer of Robotic warehousing solutions. The project involved transforming their legacy application, produced using multiple suppliers and methods, into a newly cast application solution. This project also had its own share of typical challenges.

    • Lacked definitive and reliable documentation,
    • Domain knowledge was limited to a few very busy individuals,
    • Development and redeployment could not interrupt attention to current customers,
    • Complexity was high and design was fragmented, and
    • Focus heavily invested on current product and customer support

    These limitations along with the lack of understanding of agile methods strongly suggested the use of a method adaptive in nature, and not heavily vested in large inflexible legacy elements.
    We commenced the engagement with two pivotal elements; client awareness (agile orientation) and a roadmap of committed involvement. To lay credibility this had to be backed up with proven result delivery in the very early stages. It allowed for flexible adaption, and the creation of an atmosphere that fostered client interest.

    During this session, we will take the audience through a small video clipping of such a warehouse. We will elaborate how the customer and offshore developers worked together using agile in a highly integrated team collaboration model to achieve success within a very short time frame.

    The session will cover the following key areas:

    How such projects can be initiated

    - What type of team model and contract type we used

    - How we did the agile transformation with the customer

    - How the roles were assigned between offshore and onshore team members

    - To improve remote collaboration the tools and techniques we used

    - Techniues learned to get teams up to speed with the new domain

    - As we go along, the process changes we identified and implemented to make things work better.

    - Agile engineering practices and team dynamics that helps in such situations