Do you remember the last sprint or project where you faced terrible issues? E.g ; Production servers crashed after delivery, few features were shipped or requirements were not clearly understood.
This kind of situations are caommon and lead to a lot of frustration. Most of the time, you could be surprised by how fast things went wrong and felt disappointed in front of that big mess. Then, you try your best to fix the delivery. That's all good but, once you put the situation back to normal, another problem arises: how do you disable conflicts that were raised by that chaos?
At Cozy, we had similar problems. We are all nice people with the will to make the company successful, but it doesn't prevent us from bad times. In 2015, we notably had to deal with two hard situations:
- We had to quickly ship a working product for a strategic partner without knowing if we could do it on time.
- We redesigned the onboarding experience of Cozy but no-one had the same vision of the delivery.
For these two situations, we succeeded in delivering something good but as you might have guessed everyone finished tensed and frustrated. At the time, the reasons didn't appear clearly to us. We were under the impression that this sprint was no different from any other and we didn't understand how we got to the point where everyone was mad at each other. Which was why we decided to experiment with a tool called Timeline Retrospective.
To understand what a timeline retrospective is, first let me start by explaining to you what is a retrospective. The retrospective is an agile concept. At the end of each sprint (bits of tasks done on a given time span), the team discusses what was good and what could be improved. From information collected you take actions to improve your process. Timeline retrospective follows the same concept while adding notions of history and emotion.
Timeline retrospective is a concept introduced a long time ago by agile methods practitioners. The oldest article I found is written by Martin Fowler, an agile expert. 12 years ago, He talked about something similar called Sticky Timeline.
Allow me to explain how to run it:
- Choose a facilitator who will lead the execution of the process. It's better to have someone who is not involved in the conflict.
- Start by reminding everyone that whatever will be said, you all share the same goal: to make the project a success.
- Draw a timeline where each day of the sprint is represented.
- Write facts that happened during that sprint on sticky notes and put it on each corresponding day (stick to the facts, don't add emotion above them).
- Chose four to six emotional states and link each of them to a different color e.g happy/green, confident/yellow, neutral/blue, worried/orange, angry/red
- Have everyone put colored sticky notes to the timeline above facts. No name is required, you just have to know that at least one person felt happy, angry or worried at that time.
- Once done, follow the timeline from the beginning and ask people to explain their feelings. This part is tricky, the facilitator will have to manage the distribution of time for each person and ensure everyone can say what they feel.
- Find the root of the identified problems. See what could be improved in your process to avoid another similar situation. Don't take the decision that relies on good will, but think about preventive rules e.g. refine your process, change communication tools, decide that important stuff should be written.
The 7th step is by far the hardest to handle. Remind the participants, that the goal is not to blame anyone. What timeline retrospective shows is that everyone has their part of the responsibility. They will understand that they made mistakes. When a mistake is obvious, make sure the person responsible is conscious of what happened but don't fall into the blame game, jump quickly to the next fact.
In regards to facts, it's important to write them without adding any emotion. The goal is to dissociate emotions from what happened. This way people will understand better how they reach an emotional state and how the other stakeholders feel.
The timeline retrospective is an activity that requires time. You can count from 2 to 3 hours for 5 persons involved. You can handle it online or offline. Our first timeline retrospective was done with Trello and Skype. The second one was done in front of a whiteboard. Of course, it's better if you can do it face to face because communication is greatly improved.
I don't have any pictures of our own retrospective dashboard. But here is a similar one. The authors didn't use colored sticky notes for emotion, they use it for facts. What they prefer to do is to draw a mood graph below the facts. It's different, but it follows the same principle:
At Cozy, we noticed great results from timeline retrospective. After our discussion, we decided to write our requirements more clearly and make our product owners more accountable. Most of our problems were related to poor communication (with a mix of ego). That was easy to fix. More importantly, the fact that everyone was able to express their feeling cleared up a lot of frustration.
This technic can be used to any size of a project. It has been used at a large scale by Spotify and worked well for our team of 5.
To sum up, Timeline Retrospective is a great tool to handle sprint or projects that might bring chaos into a team. It allows anyone to associate on facts that happened and express their feeling about them. Finally, it improves your team communication and building process.
To dig further in the Agile retrospective, in general, I recommend you to check out these slides about the whole retrospective process. They will give you a wider view of the concept of a retrospective. If you are only interested in timeline retrospective, you will find alternative too in the followings links 1, 2 and 3
Now that you know everything about timeline retrospective, blow away any conflict that doesn't deserve to be there in the first place!
