Retrospective in agile methodology
One of the cornerstones of the agile methodology is team communication. To make this communication fluent and effective different actions are performed, for instance, trying to make the team “be together” in the same physical space for as long as possible, or by holding different meetings along days and weeks. From all those meetings, the one I consider the most relevant is the retrospective meeting, the “retro” for friends.
The retro is the instance within a project that allows us to improve as a team, as professionals and as people as well. It is about the time that the organization provides us in order to do some introspection and analyze what worked out and what did not.
Course of action to be taken by some team member can very well come up from a retro. It is also useful to communicate the status in which the team is. A team with problems will surely have very negative retro’s. On this article, we will not concentrate on this type of retro’s, many have already written and very well about this before.
We have a project in intive-FDV which we are managing within the frame Kanban, although it is adapted to the reality of the client and the team. Within our process we decided to always have a retro after every time we are out for production, and since this is a large scale project – with 4 mobile applications, a backend and a backoffice, being out is frequent. Once a week has been the most adequate pace we have found to deliver new features. So, according to the process we thought about initially, we are out for production once a week and we should consequently have a retro once a week.
The problems started when we realized that if we held a retro on a weekly basis not many topics actually came up to be dealt with. Also, since they were too many, we could not allocate so much time to them, and because of that we had been devoting just an hour to each of them. They ended up being short retro’s during which we could not be inclined to really long plans.
One of the best ways to assess and improve any given performance in intive-FDV is the “Keep, Fix, Try”. We apply this to the coexistence in intive-FDV, to the organization of events, and obviously to projects. It is a great dynamic for short retro’s, since course of action and very specific “things” are proposed, and that is why we started using it for the project I am telling you about. The dynamic is made up of 3 elements.
- The Keep’s are to keep on with a habit or good practice. For instance, a Keep could be to “continue writing automatic tests”.
- The Fix’s are to sort out or solve a situation which is not working in the project at the moment. For example, a Fix could be “to arrive on time for daily meetings”.
- The Try’s work when we want to implement an improvement or a new methodology. For instance, a Try would be “let us try the pomodoro technique on this project”.
Very interesting things can come up from the dynamic of the “Keep, Fix, Try” or “KFT”. But in our work team and for this project in particular, the technique was becoming increasingly less effective. The thing is that teams become accustomed, they shape their thinking in lines with what they have in front and new ideas stop flowing. Consequently we noticed that the Keep’s of approval were being repeated, and also the Fix’s which sought to work out the change of priorities from the client while the work was taking place.
The solution – Retro with the fat man dynamic
Seeking to implement new improvements and staying within the time limits available, we thought about looking for variants to the “KFT” we do weekly, trying to keep it simple but also making our brain cells wake up. Trying to make us leave aside our structure of thinking which was shaped for the “KFT”.
The option we went for to work in the next retro was the dynamic of the fat man. It works more or less like this:
A wide circle is drawn which is divided into 5 sectors, just like pizza slices, identified as: “start, stop, continue, more and less”. From the divisions of this circle, feet, hands and a head come out from our fat man, as it can be seen in the next illustration:
The results from this dynamic (at least for us), have been actually interesting. Proposals have come up for those who have to take on the role of educator of a client, and to change the Scrum framework with super short sprints. We also visualized the need for a break to relax after we are out for production, since the pace of the project is really accelerated.
Another insight which came up, and that we could only saw thanks to this dynamic, is that the team is highly motivated by other practices which help improve the quality of the code we are delivering, such as code review meetings with measurable actions and the setup of continuous integration. Anyway, we will talk about that later.
The dynamic of the fat man was a breath of fresh air for the team. Although it is actually pretty similar to the KFT we had been doing, it forced us to think of new elements for new empty fields. With little effort, we could remove from the dynamic which had already been conditioning our answers.
The next retro’s can be held with this very same dynamic. But we must be careful. As soon as we notice that these insights no longer generate useful information to enhance the team and the process, we must look for alternatives. It can be a new dynamic, or we might always fall back on our beloved “Keep, Fix, Try”.