Do Small Changes
Hi guys,
I have been talking a lot about retrospectives over the last few weeks.
I have been doing so mainly because of our project, “Getting Value out of Retrospectives”, but also because of my active participation in Retrospectives. Thanks to that endeavour, I have collected some insights that I want to share with all of you. Namely, I want to discuss why we should only change one thing at a time during the iteration.
During my tenure as a Scrum Master and Agile Coach, I experienced the reality that many teams tend to collect a long list of items (that need to be changed) during a retrospective. This is a common mistake spread not only in the software industry, but also throughout our society: How many of you have (or have had) a long list of “improvements” on the wall or in some excel sheet? The intention behind such lists is good, but are these really useful?
Mike Rother explains in his book, “Toyota Kata”, that “Whenever we alter any one thing in a process, we create, in effect, a new process with possibly new and different characteristics. This means that once we have implemented one or two items from an action-item list, then the rest of the items on that predefined list may no longer suit the new situation and new priorities in the process.” Taking this into consideration, is it really useful to have a long list of improvements?
There are ways to change several topics at the same time within a system (for example, by applying Design of Experiments [DoE], where multiple variables are changed at once), but few people are able to apply this technique.
We want to create organisations where everyone is involved with continuous improvement. Applying DoE means that only a few people within an organisation will be able to participate in continuous improvement efforts, and this is not what we want.
Based on the previous observations, I believe the right thing to do is simply to take one topic out of our retrospectives at a time. Select a topic, but make a proper analysis of that topic. Thoroughly understand what the root cause of the problem at hand is (you can use techniques such as the “5 Whys”).
After understanding what the root cause of the problem is, you have the necessary information to fix the problem during the next sprint.
This is my theory, but I’d love to hear what you have to say.
What did you think of this post?
Big thanks.
Early in our transformation to Agile practices we had a flavor of this problem show up. Retrospectives discovered a lot of little things here and there that the team wanted to change. After about two months a point of exhaustion to constantly changing the process was arrived at by some of the members. This led to a lack of faith in retrospectives which we are still trying to recover from today. I have tried three times now on my blog to articulate what happened but each time a different story wanted to be told. Eventually I know I will be able to share more details about this failure of our retrospectives and the slow process to restoring them. (Spoiler alert, Team Assessment Surveys are a part of it thanks to your previous post.)
Hi Adam, thanks for your comment :)
Maybe do a complete reset how to do retrospectives?
Start from beginning, chose a simple topic that team alone can solve, and I mean one single topic, truly understand the problem, I will explain this part on wednesday blog and allow team to feel confortable again with retrospectives.
How does it sound?
If you want we can have a quick skype call, maybe I can help you :) how about?
Luis
Interesting approach. I’ll try.
Did you try it Leandro? :)