(Not so) Stupid Question 295: What is a retrospective? (How our team does retrospectives)
I’m in Lisbon enjoying Websummit, a conference with over 53 000 attendees! Leaving the snow behind I travelled here with the majority of the Konstrukt team to pitch our startup as a part of the ALPHA program at Websummit.
I’m sad I’m missing the MVP summit this year, but this is a really important event for the Konstrukt and I want to be here for my colleagues- with my colleagues. I’ve told you a little bit about the company, but I would like to share more starting here in this longer blog post on retrospectives.
Like the majority of software companies today we like to think that we apply agile methodologies such as Scrum and LEAN. As a developer I’ve seen these methodologies applied at different levels, with sometimes divergent enthusiasm. While working as a consultant for consulting firms, often larger ones, it is common to see what is referred to as ‘scrumfall’. A waterfall implementation of scrum. Which pretty much makes it non-scrum. Non-agile. Konstrukt, the startup I’m working at as a backend developer, certainly always had agile intentions- but it wasn’t until Tobias (the third backend developer) joined the team that we got better agile practices. Slowly we have been building up an agile way of working that suits the company culture, and everybody has welcomed the changes with open arms. And for me personally it has been the first time it has felt natural and not forced (because its ‘cool’/’sells’ etc). I’ve worked at a large company that was hardcore XP (extreme programming). While it certainly had many aspects I loved, it also left me drained at the end of the day. As well as confused of with the many rules, pipelines and subsequent processes. The pressure to be ‘XP enough’ was enormous and it unquestionably never felt like second nature to me.
Hoping to inspire and encourage other teams to implement their own take I’ve decided invite you to take a part of our agile journey. And what better topic to start off with than retrospectives?
So what is a retrospective?
Mariam Webster :
Full Definition of retrospective
1a*(1)* : of, relating to, or given to retrospection (2) : based on memory <a retrospectivereport>b : being a retrospective <a retrospective exhibition>
2**:** affecting things past :retroactive <retrospective laws>
3**:** relating to or being a study (as of a disease) that starts with the present condition of a population of individuals and collects data about their past history to explain their present condition
This is a meeting that is usually held at the end of a sprint, release, process or project where you basically talk about lessons learned. You look back the sprint (sprint retrospectives is the most common) and reflect upon what went well, what went wrong, what could be improved and how everybody feels about it. We keep the retrospectives to devs and QA only, but it’s not uncommon to have the product owners join in. Everybody has to participate, nothing is off the table, and we practice listening and being supportive while defensiveness, blaming and bossiness is not welcome. We (and this is our way of doing it) also do sprint-demos afterwards, and then talk about the upcoming sprint and what we hope to achieve making it more of a planning day where retrospective is one part of it.
Sprint, feature or release?
I just have to add a side note here. We actually decided last retrospective to talk in terms of releases instead of sprints as it better fits us and the product we are building. We decide what a release should have (defined as stories on our Kanban board) and the release is ready when the stories are ready. A story is a defined task, for example my last story was to implement the backend API calls for our new configuration editor which consisted of retrieving the configurations, validating changes and persisting them. There are no set dates or set intervals, although we generally try to scope them to two-three weeks.
So how does a retrospective look like for us?
It generally takes a full day, and one part of the team travels to meet the other part in person. We are a distributed team, split between Stockholm and Gothenburg in Sweden. Our retrospectives used to be a 2-3 hour long screensharing meeting where we mostly planned the next sprint and re-evaluated stories. Sprint demos were sometimes a part of the meeting, other times it was booked as a separate meeting. Now we have a full day at our disposal, with 70% of it used for the actual retrospective and the remaining 30% for sprint demos and other. We have one person that is responsible for planning the day and the activities, and she/he also has to lead the activities and make sure we keep our times and everybody gets to contribute.
The very first thing that happens is that we walk through the schedule and confirm everybody is happy with it (or make adjustments). The next part is a creative exercise where we usually end up drawing something. Once we had to draw flowers and give one to the person on the left, with a genuine compliment, and one to a person of our own choice- again with some verbal appreciation. Last time we had to think of an animal eating that would represent how we felt about the software right now.
I drew a mouse eating from a large selection of foods at a cheaper lunch restaurant. I drew a mouse as I feel small (as a system), and the large selection of foods represented all the features we want to give our customers- somewhat at the cost of quality and early technical debt. Tobias drew a gorilla in a porcelain store, we’ve had some unexpected bugs that has made us feel like the system is fragile (we are a bit hard on ourselves though). We then talked about the drawings.
Afterwards we have an activity where we collect thoughts on the system. Once we wrote on sticky notes what made us happy, what made us sad, what we could improve. We talked about the notes as we added them and afterwards we grouped them into topics/reoccurring themes.
I remember us being pleased with the changes in the deployment pipeline, frustrated that our integration tests were breaking, and we wanted to set up live streaming from our offices so we could get a stronger team feeling while being distributed. Last retrospective Tobias drew a car ready to try to jump over a firepit using a ramp to make it to the other side where goal was- all while having heavy items attached to the car dragging behind it and slowing it down. We had to write on sticky notes what we felt was holding us back, what was helping (the ramp), what would be devastating (the firepit) if it happened, and how we could make our goals.
Support for our early adopters has been taking more time than we have, so that was holding us back. Plus our team lead is drenched in work that can’t be delegated due to his expertise in the area and therefore isn’t always available for us. We’ve had a lot of issues with database versioning as we have so many tracks and environments, that could be devastating for us if it continues. Our collaboration is really great, and we are incredible supportive of each other- a major ‘ramp’ in other words. We constantly check in on each other to make sure nobody is hitting a wall, and we use humor and lightheartedness to get over bumps and periods of intense stress. Also, frontend has been getting early feedback through UAT with our early adopters and that has helped improve UX design. We need to work more on our pipelines to make our goals, and unified logging and better database versioning and validation are top priorities.
The notes were grouped again, and what we then do is let everybody draw X- number of dots to vote on what we should discuss and for how long. Max three items though. For example, we all strongly felt that we needed to discuss how we can manage customer support better all while developing the system and dealing with unexpected features (bugs). An important solution was to make sure that in particular me and Tobias get to meet the customers and see how our system is being used to better understand the complex domain. Johan was going to setup a proper ticketing system, and we have now made a ‘give feedback/report bug’s feature that posts to GitHub issues as well as our datastorage.
After a well-deserved lunch break we do our sprint demos, and the product owner joins. This is an opportunity to show of new features and improvements, and to celebrate the evolution of our product. Naturally UX considerations tend to come up which is very valuable for us all as we otherwise are somewhat isolated from customers (less now that we have more facetime with the customers as we implement the system). After that we pull up our Kanban board and talk about our next release (or sprint), making sure we are on track with certain features that we have to have in place before a certain date. An example is smartcard reader login as one of our largest clients need that before they go live in January. Many have sprint/release planning separate to the retrospective, but we want to take advantage of us all being together and therefore we start the sprint planning after the demo’s, and then we often have a separate meeting later on to pin down the items.
To summarize the above, this is how the day goes*:
Feelgood/compliment activity
Feedback activity
Top 3 ‘issues’ discussions
Lunch
Sprint demo
Sprint/release discussions
*Everything before lunch is our retrospective
Do you do retrospectives in your team? Why/why not? If you do them, how do you do them? Looking forward to hear how others do it!
Comments
Interesting. We book about three hours on Friday afternoons to do demos, the recap (i.e. retrospective) and sprint planning. Recap structure is fairly similar to yours--what went right, what went wrong (kvajebajer according to our Danish teammate), and what could be improved. Sometimes we speed through it and sometimes we spend a lot of time hashing stuff out. We don't really have activities as we're all (well, mostly) distributed. It can be tough sometimes to maintain the human connection. But we persevere and also try to find humour everywhere (in the Slack channels, the daily videoconferences, etc.). I'm actually curious about your Kanban board, how easy is it to quickly add issues on it? We use JIRA....
Last modified on 2016-11-08