Retrospectives: In Your Own Sweet Way
In this article — and, hopefully, it’s going to be not just one but several of them — I’m going to re-visit the practice of retrospectives in agile methodology, for the sake of all things re-, as in: repetition, revision, retrospection, reflection. Some of us have been working with the agile methodology for years, and some are new to it. Some have attended and/or run dozens of the retrospective meetings, and some have only been to a few. Revising and reflecting helps re-shape, re-group and re-configure, that’s why the re-activities — often shunned aside in today’s hectic world — may yield some surprising results. My today’s article is an ad-hoc vignette that showcases how one team — a part of which I once was — approached their retrospective meetings.
My web research on agile retrospective meetings, at the time of writing this article, revealed that a fair share of books and blog posts about retrospectives had been written — and sometimes in quite a complicated language — as what looked to me like generic recommendations cut out for hypothetical John Doe teams.
So, I’m not going to do a how-to listicle, “ordering” you to follow the techniques acclaimed as best practices. Instead, I’d like to focus on some heuristic essentials for a team to be self-sufficient with their retrospectives. When the essentials go home, the how-to’s are not a problem; they come effortlessly as your team intuitively knows what to do. That being said, I will still mention some of the techniques, questioning their practical value in a team-specific context.
A Heuristic Approach
“Heuristic” refers to:
“.. experience-based techniques for problem-solving, learning, and discovery. Examples of this method include using a rule of thumb, an educated guess, an intuitive judgement, or common sense “ (Source: Wikipedia).
So, “experience-based” here would refer to the hands-on experience of a team as they try, discover, fail, learn, and keep going.
I’m a proponent of heuristic approach to anything, agile retrospectives included, as this approach is about what delivers. Retrospectives are supposed to help fine-tune work processes for efficiency; what they are not is a standalone game which is played, and if broken, needs to be fixed. Tinkering with the retrospectives and the techniques for running them might all be well, but we gotta keep in mind that fixing the way to run a retrospective wouldn’t fix a failing development/work process. This is similar to using surgery on some body organ, instead of finding the real reasons for a disease, more deep down. E.g. the problem manifests itself in a heart malfunction, but what it gets down to are the extras of the cortisol hormone, caused by stress. So, stress is the reason, not the heart.
Anyway, common sense and critical thinking are not the only universal best practices. Trial-and-error would be a great best practice as well, but… this isn’t applicable to heart surgeries (*black humor*).
Feedback Cycles
Retrospectives are one of the best practices for any agile software development methodology with a team-centric approach. You look back, evaluate what’s been done, see what could have been done better, and make decisions about the future. Basically, a retrospective meeting can be visualized as a climax of a feedback cycle in a series of loops.
When there’s enough or more than enough feedback, it’s high-time for a retrospective. In Scrum, you can run an iteration-based or a release-based retrospective. If you do Kanban, a retrospective can be run, when a new build is released, or on a just needed basis. From what I’ve seen and read, quite often retrospectives fade out in Kanban. That was also the case with our team.
First, as we were doing XP, we used to run retrospectives by the book, for each iteration and for each release. Then we switched to Kanban and experimented with the retrospectives. Then, as we were into releasing a completely overhauled product, the dynamics shifted. We saw that the things that worked for smaller releases, didn’t work anymore as we were on our way to a major product release. And it’s then that we summoned ourselves to a retrospective (after 7 months without them). I’m using this fact to to make a point that there’s no boilerplate rule of thumb for the timeframes to be covered by retrospectives, for all this talk of “should we run retrospectives weekly, bi-weekly, monthly, etc. etc.” No one, less likely an outsider, can sense the dynamics of your team as well as you do.
The comic below represents an anti-pattern for agile retrospectives. If it happens this way in your team, it’s a sign of an illness (and, I hope to suggest some cures later):
Visualize Retrospectives
At a retrospective, you will want to create a context for discussion quickly. That’s where visuals come handy. We used screens, wall boards, colored stickers; certain colors would stand for critical-mild-urgent issues to address, etc. But there’s no need to make too big of a deal out of it. Obsessing over colors for stickers wouldn’t compensate for a lack of team spirit, so first things first.
In fact, there can be a case when the context is already in place, e.g. if a team gathers on a retrospective already aware of the problems to be discussed. All the same, visuals will display the picture, and people’s brains will be busy making conclusions about the events, not keeping in memory all the events that are the basis for their decisions.
Visuals at a retrospective (or post-retrospective) support the following 3 activities:
1. Discover problems
Historical data needs to be reviewed at a retrospective. The data will tell whether everything is going great, or whether you’ve got some problems. The trick is to spend as little time as possible on retrieving the data, and focus on the actual problem-solving.
Take a look at the cumulative flow chart below; I pulled it from a release history. It shows that there was a bottleneck at the beginning of December.
As we tracked down the bottleneck, we were able to identify its reasons. The bottleneck was caused by a rather complex user story. One developer worked for one month to implement it. Over this month we did several releases, and everything went smooth. Then this user story was QA’ed, and all the acceptance tests were passed. So we decided to merge this story to the main code line.
Unfortunately, after the merge quite many bugs were found in the build. It took more than a week to fix those bugs, and during this time we were unable to release anything, since the merge was already done, and the rollback was quite hard as well.
The lesson learned was to put more effort into testing complex user stories. This particular story affected many spots in the application and usual smoke testing was not enough. So we decided to introduce a new class of service (something like a “technically complex story” ) which would require a more in-depth testing and verification before the merge.
The cumulative flow diagram works good to identify bottlenecks. We had another chart, the timeline. It zoomed in on the details of a user story life cycle:
This chart would give answers to a number of questions, such as:
- For how many days has this User Story been in this particular state?
- Were there any delays?
- Was there any re-work?
- Who was responsible for the User Story?
- When were Bugs and Tasks added and closed?
- How much time was spent each day?
- Were there any impediments?
So, this user story was in the Open state for 25 days (that is, in the Backlog). Then it jumped right into the In Progress state. Two developers started working on it (so it was pair programming). They were working for 3 days, and then the story was moved into the Re-open state. This is quite surprising; most likely they had to switch to something else (no good). Then they returned to this user story and spent 15 days working on it. That’s way too long. Most likely there were switches as well, so this should be investigated. Starting Oct-18 the progress was very good: development went smooth, the tester found several bugs, and they were fixed in 2–3 days. Finally, the user story was released to production with no more delays.
I provided 2 simple examples of how we used our software to support the retrospectives, and I encourage everyone to be creative with the visual tools, digital or non-digital. Card rotter was another great visual.
Historical data can be visualized in many-many ways (check this article for some inspiration).
You can also go from human moods and emotions, rather than from data or technicalities, as a starting point of identifying problems at a retrospective. Here’s a simple diagnostics chart, the Happiness Radar (by Paulo Caroli):
People made some marks for the areas they’re happy, neutral or pessimistic about, and we can see that process and technology are lacking in happiness.
2. Solve Problems
As the problems are identified, you will want to consider possible reasons and solutions. Mind maps work great to visualize problem-solving. In fact, we do a mind map subconsciously whenever we discuss something and sketch our thoughts. This simple yet powerful technique can be used at retrospectives as well. One can sketch mind maps on a board, or on a screen, or just on a piece of paper.
Check out this mind map. It was used as a think pad to reflect upon the things that influenced the speed of development.
Looking at this sketch, one can make a conclusion that only two things impacted the velocity directly: fast feedback and experienced developers (while there were many waste things, such us unplanned work, interruptions, multi-tasking, rework, high coupling, and technical debt).
Visualization brings the issue of speed on a plate and breaks it down into smaller pieces:
- How to deal with the customers’ requests and reduce the unplanned work?
- What should we do with the urgent bugs?
- How can we do more training?
- How do we break work into smaller batches?
- What should we do about noise and interruptions?
When you ask questions like these at a retrospective meeting, expect answers and ideas in return. If you just ask: “How can we work faster?”, what follows would likely be a confused silence.
In the previous example, the mind map was sketched as a network and inspired the goal-oriented questions. The 5-Whys root cause analysis looks into the reasons, so the map would be sequential, going from one Why to another:
I picked this image from Sandy Mamoli, because the problem they worked on at their retrospective is quite common, and the answers to the 5 Whys are typical.
Now, in line with the Happiness Radar above, that’s how they visualized possible solutions using the “What will increase happiness?” chart with the “keep it”, “more of” and “less of” sections:
3. Follow Through on the Action Items
So, you identified the problems, pondered them, and came up with some action items after your retrospective. At the time of writing this article, I searched the web through and through, and, to my surprise, it turned out that few teams would use Kanban board as a visual tool to track their retrospective action items. It appears there’s a reason for that. With Kanban, you will want to have an opening state and a final state, because the board is intended to track straightforward one-time actions. Contrariwise, retrospectives often imply recurring actions, for which the whole team is accountable, not just one person. These are the collective ownership items.
For instance, you see that inconsistencies in user stories are discovered only at the final testing phase. You run this issue by a retrospective, and the team rules that a user story launch meeting has to be done before the start, and the inconsistencies have to be attended to at this very meeting (e.g. the specs should be discussed and approved). So, the action item here would be: 1) include writing functional specs as a satellite task to the user story AND 2) check if all the stories that are currently in progress have the specs.
Back to the problem of over-promise and under-delivery featured above (a very common problem, by the way). Now, you want to set limits to your work in progress, and you arrange for someone to write a mash-up for tracking the limits through the Kanban board. This would be a one-time actionable item.
Plus, you see that the urgent bugs deserve more attention. Someone should think over the process for such bugs.
Here’s a very basic Kanban board which includes these tasks:
At the Kanban board below, you see the limits of your WIP, and the red light turns on any time your WIP items count is exceeded. No need to keep the limits and the details in memory, because the Kanban board sends a signal about the problem: a visual follow-through on your retrospective.
Next, about the bugs. They are now tagged “urgent” and “sup”, and they should be tracked closely+comfortably=visually. On the snapshot below, the red cards indicate the “urgent” bugs, while the beige cards indicated the “sup” bugs (“sup” means “support”). This custom visualization was created with one of the mash-ups.
There was also the Team Load mash-up, which showed how much work, and which work, was in progress for every team member. Another good follow-through technique for retrospective action items. Blue stands for user stories, red stands for bugs, and.. the faces are on the pics :)
A note from the author: This article‘s headline is inspired by a music piece (time stamp 4:55) and a compilation to where it’s included.
Related:
DataViz 101: 5 Reports for Kanban
Visualization: Understated or Overrated?
Further reading:
What is a Sprint Retrospective?
Heuristic Approaches to Problem Solving
Why You Should Make Time for Self-Reflection (Even If You Hate Doing It)
This article has been revised and re-written based on an earlier story.
