During training courses, I often think it would be helpful to have all of Scrum and Agile summarized on one page. It’s actually not so easy! Even though the Agile Manifesto is just 4 values and 12 principles, and the Scrum Guide is 17 pages, it is still hard to summarize all that on one slide. We’ve tried anyway, and I am interested in your opinion on our efforts.
Lately I've been thinking and writing about project reviews and agile retrospectives. I explored why I think traditional lessons learned exercises are a waste, and how to improve retrospectives when you have them. This post is going to focus on how to lead a review or retrospective without pointing fingers or blaming others. We’ll look at why fear and blame are so harmful, and then specific steps you can take prior to a review and during the review to reduce or eliminate fear and blaming.
Why Fear and Blame Need to Go
Over the last few months I have been writing about how to improve team retrospectives. This has been mostly focused on Agile teams. Recently I've been asked to facilitate a "retrospective" for a traditional project. I remembered that a few years back, I wrote about why I felt that traditional lessons learned for projects were a waste of time. My thinking on this topic is still the same - I still feel like those traditional lessons learned activities are a huge waste of time.
This is part two in my series of posts about improving your retrospectives. As I mentioned in my previous post, the retrospective is a key part of the Scrum Framework. It is designed to help the team make their processes and practices more effective and enjoyable. This post focuses on the first part of the retrospective where we set the stage for the rest of the retrospective meeting.
In my last post I talked about the Scrum Retrospective meeting and how the speed of the retrospective was not the most important thing. The retrospective is critical element of the Scrum Framework. It is a continuous improvement process to help the Scrum Team become more effective and enjoyable. In this post, we are going to explore how the retrospective helps the team improve, and introduce a structure for planning retrospectives.
Most people are aware of the retrospective meeting that is part of the Scrum Framework. It is a key improvement activity used by Agile and Scrum teams at the end of each sprint or iteration. This past week I was coaching a Scrum team and I witnessed one of the fastest retrospectives ever. The entire meeting lasted 13 minutes and there were 9 participants. Fast? Hell yes! Efficient? Perhaps. Effective? Not even close!