I’m a huge believer in learning from the past; as Yogi Berra might have said some of my best mistakes are in the past. There’s a lot we can learn by reflecting on both what went well and what didn’t work out at the end of a project, an Agile sprint, a meeting, or a workout.  Learning rarely comes without effort, and doing the work of collective reflection on an experience can help a team gain valuable insights.

Working on product development in an Agile environment, I am regularly glad that we practice the discipline of a sprint retrospective at the end of each two-week development cycle.  One key goal of Agile is to promote continual improvement for the team and the practice of retrospectives plays a valuable role in that steady growth.  I’ve written about retrospectives before as part of my series on Agile planning, but I wanted to say a few words again because I was struck by the importance of this practice recently.

We just finished our most recent sprint and so I helped facilitate retrospectives for the two scrum teams I am working with.  One team came together fairly recently for a specific project and we keep our retrospectives simple with just two questions: What went well this sprint and What do we want to change heading into next sprint?  Our retrospective gave us the chance to celebrate the strong collaboration we are already exhibiting and to praise the work of a couple folks on the team who have clearly stepped it up lately.  It also highlighted two key things for us to work on going forward – particularly because several people in the retrospective brought up the same areas for change: two many items were dumped on to a single person to test near the end of the sprint (instead other developers can carry more of the manual and automated testing), and one aspect of the project is going so well that we can reallocate team members to work on different things more quickly than expected (a great problem to have if you can recognize it early enough to act on it).

The second scrum team I work with has been together for years working on our flagship product.  We periodically change up how we run the retrospectives so they don’t get stale, and currently we ask three questions: What should we keep, what should we stop, and what should we try?  These questions force us to acknowledge both the good practices we have adopted (coders and testers working in tandem for example) and the impediments that tripped us up (there are several things we want to try that ought to improve collaboration with our globally distributed team members.  Because this team has been working together for so long we can also discern patterns in our retrospectives and if the same theme shows up regularly under our “stop” or “try” question then we know we need to give it focused attention.

As I said above, part of the key value of Agile is that it promotes and supports the continual improvement of the team and its work processes.  Regular retrospectives are one important support for that effort of strengthening the team.  We see real value in regularly reflecting on both the good and the bad aspects of our work together, and our team is clearly stronger for it.  We still run into problems and find new ways we want to learn and grow because in truth it’s not that simple.

[Note: image here is from this site: https://studiojoslizen.files.wordpress.com/2013/09/chants-field-mirror-4-by-alex-baker-photography.jpg]