We kept having retrospectives, but nothing changed. A year-and-a-half of retrospectives gone by. Each one about the same problem that never gets fixed. Dates are missed, morale is low, and we’re ready to throw in the towel.
I was a software engineer fed up with all my hard work amounting to work that wasn’t shipping. I was at a conference when a lightbulb went off. The talk was about lean manufacturing and put me on a path of learning about work-in-progress limits and experimental learning. At the heart of this inspiration was a phrase I had read, “If you understand the problem well enough, the solution is obvious.”
I wanted to change our retrospectives. I wanted us to focus on only one problem until it was fixed. I wanted our retrospectives to focus on learning and experimentation instead of doing action items. I wanted us to focus on fixing our problem for real instead of guessing.
I brought these ideas to the scrum master. Eventually, the ideas took hold and our retrospectives changed. As they did we began to learn about the root of our problem.
After three months we found the source of our problem. We found the one line of code that had crippled the team’s ability to ship safely or on time.
Through this story, I’ll teach you how I influenced our team and scrum master to change how they used retrospectives. I’ll tell you about the retrospectives that we used to focus on one problem and how we came up with experiments instead of action items.
