The retrospective experience — Scrum Series I
I met the agile manifesto early in my career as a software developer, and since then I became an enthusiast. Over time I was able to work in companies that used frameworks like Scrum, and see how those practices could actually improve the performance of development teams. These opportunities stimulated me to study Scrum, and to achieve a better understanding of the tool. At the same time, they brought me the willingness to work with the improvement of development teams.
Here, at SumOne I work as a FullStack Developer on a development team that used a bit of Scrum stuff along with other agile methodologies. In this scenario I had the opportunity to structure the processes for us to actually use Scrum. As part of this task, I will start this series of posts telling my experience as a ‘Scrum Master’ in order to help me understand the framework and prepare myself for PSM.
I remember listening to a podcast that said the first step in implementing Scrum on a team was to use retrospectives. Of course, at this point we were already used to do daily meetings, sprint plannings and reviews / retrospectives, but in a particular way different from what Scrum was. So the first post in the series is going to be about how it was planning and executing the sprint retrospectives on my agile team.
The downside of our process was using Scrum only as a way to organize ourselves, losing the main purpose of the tool. I once read from the book ‘Scrum: The Art of Doing Twice the Work in Half the Time’ that one of the pillars of Scrum was inspection and adaptation. So I decided I would use some tools to inspect our routines during the sprint and create enough material to do a sprint retrospective focused on improvement.
After the inspection phase, it was time to finally plan and execute the sprint retrospective meeting. This meeting purpose is providing a process of continuous improvement to the team. We do that by identifying and discussing together what went well in the sprint, what could have been better and what we could have done to improve the next sprints. What improvement can we immediately make to improve our team?
My first retrospective went very well. I planned it using retromat.org, a tool that generates dynamics to be used in the meeting, which made the process lighter and more useful. I planned it in order that everyone could talk about the sprint in a less formal way making participants more comfortable and reducing obstacles such as fear or shyness and getting as much information as possible.
We have achieved some improvement points and a factual and immediate action plan in our sprint retrospective, which is a great result. But despite the positive feedback, I was able to note the first mistakes I made when planning a sprint retrospective meeting. Continuous improvement is achieved, amongst other ways, by teams composed of happy and satisfied people, and my first mistake was not invest some time of the meeting to collect measures of happiness.
This was our first step to start using and understanding Scrum for real. Curiously the first rock on our journey this new practice revealed was something we already knew, but we had no idea of how much time this was delaying us and we were not moving to solve this problem.
After that first meeting, I started improving my perception of the team and we started to reap the results of an approach focused on upgrading our processes — which is the main focus of Scrum. Currently I have been thinking of ways to use retrospective so the team can help me to improve as a scrum master and consequently ripening our Scrum processes.
