Partnership & Possibilities – Episode 5, Season 5

Friday, February 7th, 2014

Partnership & Possibilities: A Podcast on Leadership in Organizations

“Retrospectives help us define and examine a body of work, what we can learn from it, and what that tells us about going forward and then choosing those next steps to move forward.”

Running time 27:46

What would be useful for you to learn to incorporate retrospectives in your organization? Who would benefit from exploring this idea and how to do this kind of work in an effective way? How open do you think people in your organization would be to including retrospectives as a process for continuous improvement?

Leave a comment on this blog or email us at

[Intro] Defining retrospectives for the rest of us.
[03:45] There are many different methodologies focused on continuous learning for continuous improvement.
[08:36] Encouraging openness and transparency when talking about improvement.
[11:28] Important to reflect on the specific action taken and to learn from it – each learning experience may be different.
[14:18] Engaging all the relevant stakeholders in the process is key.
[15:06] Retrospectives work best when there is a specific focus vs trying to improve everything.
[19:02] How are organizations embracing the idea of learning?
[22:34] Importance of creating safe spaces for people to share freely.
[25:35] The retrospective facilitator must be capable of understanding the needs and process for a successful retrospective.

Agile Retrospectives by Diana Larsen and Esther Derby
Adaptive Action by Glenda H. Eoyang and Royce J. Holladay
Chris Argyris: theories of action, double-loop learning and organizational learning
Seeing Systems – Unlocking the Mysteries of Organizational Life by Barry Oshry
Pedagogy of the Oppressed by Paulo Freire
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition
Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth

Photo Credit: Krissy.Venosdale via Compfight cc

One Response to “Partnership & Possibilities – Episode 5, Season 5”

  1. David Whitlock Says:

    Hi, Sharon and Diana.

    It’s a weekend in March and it’s not raining which means it’s time to work in the garden and catch up on my podcasts.

    I, too, have noticed that my Management layer hasn’t effectively integrated Retrospectives or “inspect and adapt” into their regular practice. When I’ve asked them about applying Adaptive Action, the replies sound a lot like the ones that I get from Agile Teams that don’t have effective Retrospectives: “We’re too busy executing to look back and try something else.”, “We had a Retrospective after the last release, but no one ever followed through on the changes.”, and the occasional “Nothing’s wrong. What would there be to talk about?”.

    In Agile Software Development, the responsibility for facilitating Retrospectives and holding people accountable for acting on the outputs of the Retrospective clearly falls to the Scrum Master or Agile Team Lead. The roles and organizational patterns for Agile software Teams are well-defined in the literature. What I’d like to see in a “Retrospectives for the Rest of Us” book are descriptions of what an effective leadership organization looks like. What are the roles and responsibilities of the various leaders? What kinds of interactions do they have? Maybe something that talks about the Containers, Differences, and Exchanges that are in place within effective organizations. I think the Differences are very important. If everyone in the Container sees themselves as solely a manager of a project or a group of people, there may not be enough differences in role or skill sets to operate effectively.

    And I’ve also got a story to share about how I used Retrospective techniques outside of my Scrum Teams. We had just made an small organizational change to help improve communication between our development Teams and another group with particular technical expertise. This change was considered controversial because it meant that some Teams had more access to the technical experts than others. Our hypothesis was that the experts would benefit by having a “seat at the table” when it came to technical decisions, especially decisions made early in the project. I described this change as an “experiment” because I didn’t know if it was going to be “always and forever” and I wanted to set the stage for gathering feedback and adjusting our plan accordingly. I’ve also found that technical people are much more accepting of “experiments” because it sounds (and is!) scientific. Even though none of the experts were embedded on my Teams, I made sure to check in with the experts every month or so to see how things were going. These mini Retrospectives helped us keep tabs on progress, identify issues, remind everyone of why we were running this experiment (which was especially important when the group of experts got a new manager), and figure out what to do next. We’ve been experimenting with this new model for several months now and it’s going pretty well. Getting regular feedback has helped keep the experiment on track and has allowed us to react to events that we could not have predicted when we started. For me, it wasn’t the tools and mechanics of Retrospectives that made a difference. It was the scientific method behind Retrospectives that gave me a language and template for action that enabled our success.

Leave a Reply