The Jewish New Year - a good time to think about Retrospectives


During this time on the Jewish calendar, it is traditional for us to spend time doing some deep introspection. Looking at our accomplishments and failures over the past year and building a plan to better ourselves for the coming year. In short, we do a deep personal retrospective and come up with our kaizen (Japanese for "continuous improvement") for the coming year. 

This helps to highlight the importance of introspection and having a plan for improvement. To be able to improve a team must be able to take an honest and open look at itself. There are many difficult challenges in attempting to do so. It is very important that the team space be psychologically safe. Teammates must feel free to share their thoughts and ideas with the other members of the team without worrying that they themselves, or their ideas may be considered stupid. While this is easy to say, it can be unfortunately hard to achieve in practice. 

A team that exemplifies the Scrum Values will find it easier to have an honest and open retro because they will have the courage to speak up and the respect toward each other to easily practice the Agile Prime Directive. This is important because in a retrospective we need to be able to discuss events and discover information. If everyone doesn’t assume that everyone else did the best that they could with what they knew at the time, it becomes very easy for someone to feel they are being attacked and go into fight or flight mode. It is then the team’s collective responsibility to detect that and help bring the conversation back to a productive conversation.

Out of the retrospective must come a kaizen, the next step the team is going to take to try to improve itself. Like all things in Scrum this should be a small step forward that we can then inspect and adjust. Dave Thomas co-author of The Manifesto for Agile Software Development put it very well when he said in his talk Agile is Dead that one should apply agility on all levels from naming elements in code to deciding how to deploy code. This very much includes team improvement as well.

Making sure the retrospective and the team space in general, is a psychologically safe space is, in my opinion, more important than what games are used at the retrospective. As Scrum Masters we need to not only be masters of Scrum but also, and in my opinion more importantly, masters of team building. Be careful to not fall into the trap of solely focusing on conducting the Scrum ceremonies and not on the Scrum Values and building the team. Take the time to do your own personal introspective retrospective to make sure you are focusing on the things that are important to you and your team.

Stay Agile.

Comments

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

No, this is not a post about a new band, it is about understand Scrum team growth . In my  previous post I discussed The Five Dysfunctions of a Team by Patrick Lencioni and how the dysfunctions in that book apply not only to management teams as described in the book but to Scrum teams as well. In 1965 Bruce Tuckman proposed his model of team development. While you may not be familiar with Tuckman’s name, you have probably heard of the stages of his model, forming, storming, norming and performing. Forming - The team is coming together for the first time. Team members behave independently, they are on their best behavior and very focused on themselves. To move out of this stage, team members must be willing to risk the possibility of conflict Storming - The team members are learning each others strengths and weaknesses and learning to trust each other. Some of the teams disagreements are passionate, but also can tend to lean toward personal attacks as opposed to healthy confl
Read more

How many dysfunctions does your Scrum team exhibit?

Image
If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time.  Merriam Webster defines dysfunction as  impaired or abnormal functioning or abnormal or unhealthy interpersonal behavior or interaction within a group I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well.  The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Read more