As usual, the time that it takes me from home to the office is quite productive, I often think about retrospective models I could use depending on different situations, let me show you the following situation and the retrospective model I created for it.
Imagine that there is a team who has been working quite hard to achieve a deadline, life is not often that beautiful and sometimes due things out of our control we do have deadlines to satisfy. The consequence of having deadlines is that as close you are to the deadline you start not giving enough importance to topics that might not seem that relevant for the deadline, but those topics are imporant(Imporant but Not Urgent).
Those topics can be things like not having enough test coverage, or not using a particular framework as we should because it requires more mastery, or functionalities that are not critical at the moment, technical debt might be also created, there are a lot of things that might be forgotten or not given them enough importance as close as we are to the deadline, because what matters is to have the software ready for a particular range of dates, often quite tight.
Now imagine that the team has delivered what they promise, but the consequence is that topics like the ones I mentioned have been left as we got closer to the date.
We could argue that what we need is to try to make some changes so this doesn’t happen again, I agree but at least this an starting point where we can highligh big concerns of the team, topics they have accepted to sacrifice entirely or partially because of the deadline, the retrospective I will show has as a goal to highlight all the topics that the team is concerned about, topics we should tackle as soon as possible, because yes, the team has delivered something but with some consequences, let me show you The Highway
The first thing you will do as a facilitator is to explain the analogy of The Highway, so, do you see a car right? the car represents our product, and the car has been going through a journey(the highway) so the team has been building the product over the time, and now that we have delivered what we promise, there is going to be a before and after the date, this is why you see the stop signal, the stop signal represents the deadline date, and this is why the car is stopped.
After the stop we have a nice representation of the planet earth, which is the “real world”, we have been building a car and now we will expose it to the world, the team has been working with certain users and getting their feedback, but now is the first time that we will expose the product to everyone, will the car work as expected? and with this question we will kick off the retro!
First things first
Ask the team, from 1 to 1o how confident they are with the product they have built, will the product work as expected and won’t be giving problems to the users once it’s available for them? with this you can see the level of concern, we always have persons more confident than others, and this is why we want to see the different confidence perception of the team. With the different scores you can already have some conversations.
As you can see we have different panels across the highway, this represents the different warnings and informative signals we see in highways, so each team member will have to write down the topics they are concerned about, topics where they did not have time to work on due the deadline, normally they will refer to intangible things for the user, things that don’t have short-term cost, but long-term cost.
Type of topics that could be raised:
- Not enough unit test coverage
- Not enough automation
- Not real replication of the live environment to perform tests
- Old version of the framework “x”, we need to upgrade as soon as possible to enjoy latest features.
- We have been working with some bad practices in the framework “y” because was easier and faster to use, we should re-think and check the current architecture.
- Reduce technical debt.
- Epics A and epic B that are not critical should be started as some users are expecting different features from those epics.
I think you get the point with the following examples, whatever raises a concern to any of the team members.
Given all the topics raised, the team will have to talk about, it’s perfect that we don’t have only developers in the retro, we have product people, and with the help of the facilitator the team will have to think in certain actions points for the upcoming weeks, because as I said there is always a before and after a deadline, and it’s always a good time to reflect and approach different topics with a different points of view.