Hi guys; in my last post I explained why I think we should take a single item out from each retrospective. This post received some interesting feedback. One example of this feedback is: “If a team is big or if items are small, there is no point taking just one item.”
My opinion is still the same: We should stick to one item at a time. We all work in complex systems, and therefore when we solve any one problem within them, there is a significant possibility that the whole system will change. This will force us to take a step back and reassess what is wrong with the new system. If we had several topics to solve, it’s likely those topics became obsolete within the new system.
If you read the book “Toyota Kata” written by author Mike Rother, you will find exactly the same comment. People think that choosing one single topic for improvement will make a company really slow. But in reality, Toyota improved much faster than any other car company. So, how is this possible?
The trick was that Toyota did not wait long to analyse if the change had any effect. They did not wait for the next weekly meeting. As soon as they implemented the change, they immediately verified if it caused any impact or not. So, my question is: Why not do the same with our software development process? Why do we wait for the end of a sprint or the end of a project to do a retrospective?
If we start to do small retrospectives on a daily basis, we will be able to understand much better what the impact of our actions is. If we do short and quick retrospectives, the speed of our learning will be unbelievably fast.
Let me give you an example; some time ago, I went for a coffee with a colleague of mine, Marcos Garrido. He told me that few years ago he had a difficult team. That team could not deliver anything for two years, so he thought deeply about how he could help them. He took a drastic approach and started with the basics of agile. He started with sprints of a day—Yes, exactly that: ONE SINGLE day.
A working day looked like this: Planning around 8:00AM, the daily after lunch, and a Demo and Retrospective before leaving for home. Do you know what happened? In 4 weeks, they delivered more value than during the whole two previous years. Marcos received awesome feedback, and the team felt that their speed of learning was something great.
In conclusion, I want to say this: Choose one single topic to improve, implement changes, see how the system reacts to the new changes, and if needed, choose a new topic—without the need for waiting for the next retrospective. Retrospectives are actions that should be triggered on daily basis; we should start analyzing what we do more frequently. I truly believe that all of us just “do stuff” without really thinking enough about why and how we are doing it.
In case you are interested in Agile Retrospectives I am at the moment preparing an AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.