Tips & Tricks for Running Great Retrospectives

Setting out to write a series of articles on agile retrospectives, I looked at some of the sources currently available on the subject. It turned out that most of the books, articles and blog posts have been written by external facilitators or agile coaches, and sometimes in quite a complicated language.  I somehow got an impression that – at least in their writings – they prefer to go with the generic recommendations cut out for hypothetical dummy John Doe teams.

 

So, I’m not going to list someone else’s how-to’s, telling you to blindly 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.

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” (a quote from Wikipedia). Let me reiterate that “experience-based”  does not refer to the experience of external facilitators, but to the hands-on experience of a team as they try, discover, fail, learn and move forward. Maybe I’m a bit biased, as we’ve never hired an external consultant or facilitator at TargetProcess. It’s always been our own trial-and-error, common sense and intuitive judgement.

I’m a fierce proponent of heuristic approach to anything, agile retrospectives included, as this approach is about what delivers. No facilitator will do the job for a team, if their goal is to facilitate good retrospectives only. This is similar to using surgery on some body organ, instead of finding the real reasons for a disease, more deep down. Like, the problem manifests itself in the heart malfunctions, 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 is a great best practice as well, but it does not apply to the 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 for 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, then 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’s also been 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. Now, as we’re about to deliver the completely new TP3, the dynamics has shifted. We’ve seen that the things that used to work for smaller releases, don’t work now as we’re on our way to the new product. So we’ve called ourselves on a retrospective, although we haven’t done one in about 7 months. I’m using this as an example to make a point that there’s no boilerplate rule of thumb for retrospectives. No one, less likely an outsider, can sense the dynamics of your team as well as you do.

The following visual is an anti-pattern for agile retrospectives. If it happens this way in your team, it’s a sign of a serious disease. I’ll cover possible reasons and cures in the next part of the series.

 

Visualize Retrospectives

When at a retrospective, you need to create a context for discussion quickly. That’s where visuals come in handy. We  use screens, wall boards, colored stickers; certain colors may 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 will not compensate the lack of team spirit, so first things first.

In fact, there can be a case when the context is already in place, e.g. a team comes to a retrospective already aware of the problems they should discuss. 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 can tell that everything is going great, or that 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 more fully.

Take a look at the cumulative flow chart below, I’ve pulled it from our previous 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 one month to implement it.   During this month we did several releases, and everything went smooth. Then this user story was QAed, 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 is to put more effort into testing complex user stories. This particular story affected many places 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’ve got another chart, the timeline. It zooms in on the details of a user story life cycle.

This chart gives 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 (Alla and Vladimir) started working on it (so it was pair programming). They’d been 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 got back and spent 15 days working on this user story. That’s way too long. Most likely there were switches as well,  so this should be investigated. Starting from 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’ve given 2 simple examples of how we use TargetProcess to support retrospectives. Another great visual we’re using is TargetProcess card rotter.

Historical data can be visualized in many-many ways ( check this article for some  inspiration).

You can also go from human moods and emotions to discover problems at a retrospective. Here’s a very 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 clearly lack happiness.

2. Solve Problems

As the problems are identified, you need to think about the solutions.  Mind maps work great to visualize problem solving. In fact, we do a mind map subconsciously whenever we discuss something and sketch the thoughts on a piece of paper. This simple yet powerful technique can be used at retrospectives as well, and that’s what we’ve been doing. Mind maps can be drawn on a board, or on a screen, or just on a piece of paper.

Check out this mind map. It has been used to think about the problems and activities that influence the speed of development.

Looking at this sketch, you can make a conclusion that only two things can improve the velocity directly: fast feedback and experienced developers (while there are 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 customer requests and reduce 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?

If you ask questions like these at a retrospective meeting, you can expect  many good ideas. If you just ask:  “How can we work faster?”,  the answer might be silence and confusion.

In the previous example, the mind map is built as a network and inspires 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 up this image from Sandy Mamoli, as the problem they’ve been working 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

You’ve identified the problems, pondered over them and come up with some action items after a retrospective.  I’ve searched the web through and through, but to my surprise, it seems that very few teams are using kanban board as a visual tool to track their retrospective action items. It appears there’s a reason for that. With kanban, you need to have an opening state and a final state, it’s for straightforward one-time actions.  Contrariwise, retrospectives often reveal the need for recurring actions, of which not a single person is accountable, but the whole team. 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 you decide that a user story launch meeting should be done before the start, and the inconsistencies should be taken care of at this very meeting (e.g. the specs should be discussed and approved). So, the action item here would be to include writing functional specs as a task for a user story AND 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 decided to set limits to your work in progress. Someone needs to write mash-ups so the limits can be tracked easily on the kanban board. This is a one-time actionable item.

You also decided that urgent bugs deserve more attention. Someone should think over the process for such bugs.

Here’s a very basic kanban board with these tasks:

On the kanban board below, you clearly see the limits of your WIP, and the red light turns on any time when your WIP rules are violated. No need to keep the limits and the details in memory, the kanban board would send a visual signal about the problem  – a helpful follow-through for 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 stand for  the “urgent” bugs and the salmon cards for the “sup” bugs (“sup”  means “support”). This custom visualization has been done with one of our mash-ups.

 

 

There’s also the Team Load mash-up, that shows how much work, and which work, is in progress for every team member. Another good follow-through technique for  retrospective action items. Blue stands for user stories, red stands for bugs, team members are on the pics (including Voltaire 🙂

Maturity and the culture of trust

A team has to be mature enough to hold retrospectives. One of the common pitfalls is when teams are eager to run retrospectives just for the sake of running retrospectives. They know that if they are supposed to be agile, they need to do retrospectives. But it’s not as simple as following a guideline. The need has to come from within. The team has to develop this intrinsic feeling of power to solve their problems and – even more important – to accept the responsibility.

So how would you know if a team is mature enough to run meaningful retrospectives? If it’s not, how do you go about nurturing such a team? Do you have to bother at all?

First and most, it’s about the no-blame culture. Well, it’s better in the positive, not in the negative, so let’s put it like that: no-blame culture is the culture of trust. Let me mention here  that  trust is one of the signature values in our company.

The culture of trust emerges from a dozen of subtle ingredients. There’s no exact recipe as to how much of each ingredient you should take and in which proportion. It’s not a cocktail, for better or for worse, but it does bear some resemblance to a cocktail, as oftentimes you’ve got to stir, or even shake it well before enjoying!

 

Communication: tell me who you are, and I’ll tell you who I am

Following the lines of cocktail making, communication appears to be the basic ingredient of the culture of trust.  I completely agree with the point of this article that “lack of communication” is an umbrella term for all kinds of hidden conflicts and unresolved issues.  It represents an antithesis of the culture of trust.

So, if in your company “lack of communication” is light-heartedly referred to as the common excuse for troublesome issues, that’s when the red lights should go flashing, better yet with the fire alarm sound.  When people don’t talk, or misunderstand each other’s messages, or are reluctant to spend time explaining their point of view– this is the surface skim of what can be a severe turmoil of contradicting values, assumptions and beliefs.

For a certain time, this turmoil might simmer as a dormant volcano, but the eruption can come at a bad time, when everyone assumes the volcano is asleep for good.  At a retrospective meeting, for example, in the form of finger pointing:

Finger-pointing, it seems, falls short among the other consequences of the notorious lack of communication. Look, if tons of paper and web pages have been wasted to research/discuss this problem through and through, but it still persists — it means that avid readers are missing the point in their own organizations, being either short-sighted or far-sighted, or sometimes even both.  It also means that some essential things are left off from those writings, as for some reason people fail to fix the glitches once and for all. That’s because they don’t get to the bottom line.

For now, I’ll take just one  cultural pitfall related to retrospectives and meticulously dissect it, tissue by tissue (surgical metaphors seem to fit better here than cocktail recipes).

The pitfall: no one wants to attend retrospectives

All right, about this one. Some common tipsy-tricksy symptomatic cures and surface reasons for this pitfall I’ve seen in some books include:

• people don’t want to spend too much time on a retrospective, that’s why they rather stay away, so let’s set a time limit of 1 hr (insert 0.5 hr etc.), and this will fix it
• no one wants to attend because it’s soo boring, so let’s make retrospectives fun! Let’s go somewhere outside and invite some clowns so they entertain us, or let’s have gourmet chefs cook delicious food for us. Only then a retrospective will work.
• people don’t feel relaxed enough. They’re shy to speak up, they experience social awkwardness, so let’s do a group therapy session with a set of relaxation exercises.

How does that sound? Shallow, at least. So, I’ll run the chain of whys to find the underlying deep reasons (see the first part for another example of the whys technique).

No one wants to attend retrospectives. Why?

They believe this is a waste of their time. Why?

They decided to take some actions at the previous retrospective, but it didn’t work. Why?

Everyone seems to be fine with the current setup. Why?

… and so on. Most typically, the chain of whys will uncover one and the same issue: a retrospective is not a meaningful activity. Sometimes, a retrospective is just a ritual the team leader or the CEO is following to do agile by the book, while in reality they’re well aware of all the problems, and already have some solution in mind. So, a retrospective in this case is more of an opinion-check meeting to sense the atmosphere in the team, and to see if the leader’s decision is aligned with the expectations of the team or not. Of course, it’s not all black and white. The authoritarian leadership style is hardly viable anymore, but some annoying breadcrumbs of this style can cause cultural itching. Nor an utterly team-based ruling will make it work ultimately.

A report from the trenches

I’ve already mentioned briefly that we’re now working on the new version of our product, and we’re back to doing  retrospectives. Recently we’ve had an intense 16-day span called Subbotnik to come up with what turned up to be a private pre-beta (not even a beta so far).

So, there was a retrospective, and the team along with the Scrum Master decided that we’re now doing it in a milder mode, with good old 2-week iterations, and even with a burndown chart. Also, there appeared to be a deadline (something unheard of in our company for several years), so people somehow decided that we need to suspend the IDP (Individual Development Program) until we release for the deadline.

A side note: we have an individual development program, similar to Google’s famous 20% time, and this is one of our signature practices based on the essential company values. Maybe the Scrum Master was too rigorous in propelling his methods to reach the desired outcome, or the team believed that this deadline is indeed a matter of life and death, either way, they decided they’d suspend the IDP until that deadline. There were signs of the latent simmering, and after some get-to-the-bottom-of-it discussions it’s been finally made clear that we are NOT actually chasing any particular deadline, we just need to do it as fast as we can, until it comes out good (in short), and we will not sacrifice the IDP practice to this deadline.

This is a very characteristic example, a perfect specimen of “the lack of communication”. If the team and the Scrum Master were aware that there’s no deadline actually, they wouldn’t have opted for holding off on the IDP, as much as it means to our company. So, the lack of clear communication caused a slight shake to the cultural foundations, which later on might have developed into the subdued discontentment.

The core of this deadline/no deadline problem lies in something personal. It’s about the desire to come up FASTER with a great new version of our software, the software that is so incredibly helpful indeed.  If speed becomes an obsession, it can backfire with the unpredictable side-effects. Anyhow, in our case, the urge to deliver fast collided with the higher values, besides, we’ve learned that deadlines might only work for Subbotnik (the development practice we’re using to clean up residual bugs).

More analysis: we’re a company with the culture of trust. So, the issue of finger pointing hasn’t been affecting us much, from what I see.  But at times some communication glitches occur. Even with trust established as the core value, lack of communication might produce the effect of hidden blame placement. Generally speaking, for any production work, the people that one wants to criticize most are those who do not deliver enough information in the context of  tasks done together. This non-delivery of information, I think, is not an intentional evil act, it happens inadvertently. If someone is obsessed with speed, it wouldn’t occur to them that by keeping the latest update or idea to themselves they’re doing anything wrong. This is the case of too narrow focus, or maybe being too far-sighted, letting people out of the mutual loop.

You might ask: so what, what’s the solution? Is it just one more story about the lack of communication? Is there any real cure to it, other than the recipes fit for kids daycare? Note, that we’re still talking about agile retrospectives based on our IDP non-suspension case. The real cure is to get the point through to people who set the outer culture and the inner culture. Lack of communication would continue to be referred to as an all-forgiving excuse, until someone who is in charge truly gets that the side-effects violate company values AND in the long run slow things down,  not speed them up. That’s a paradox, very well known from the story of the turtle and the hare: Festina lente OR “Hurry up by being slow”, as translated from Latin. Things will not happen faster if you save those few seconds on not mentioning an important update to people who work all together, especially in a location that high.

To put it in other words, no cultural attitudes are shifted by a compulsory decision to follow some prescribed “shoulds”. The attitude might only change if an established behavior pattern is violating some higher meaningful values. I’m not giving any “how to make bad patterns change” advice intentionally, nor saying what those higher values could be. There’s no universal answer and recipe. Every organization has their own secret nuts and bolts, and in the end it all gets down to people, their personalities and interactions. Forgive me, my dear techies, but it’s about psyche and emotions, not about stats, graphs and calculations.  Binary thinking with its universal “wrong/right” -“good/bad” rhetoric has no answer. There’re countless subtleties and nuances. The point is to be able to identify the prevailing idea or sentiment or value, and go from there.

Here’s a simple life-based example, not related to software development or project management, just to show how “need” or “can’t stand this anymore” beats “should”. For my tennis practice, I have a set of balls, usually about 60 or so. They last for about half a year, sometimes longer, and then they need to be replaced with a new set. My latest set of tennis balls has been alive for almost incredible 12 months, and it suited me OK, because I’m practicing on the fast surface, and while old balls don’t bounce as fast as new balls (well, there’re different varieties, but this particular set had exactly that aging pattern), it’s almost like the imitation of the slow clay where you have more time to get to the ball and to make a good move. The fast bounce has some disadvantages, to cut it short, and it’s not what I’m focusing on at the moment.

So, my coach kept reminding me that the balls should be replaced, that they’re old and they bounce slowly. I kept dragging, finding excuses not to replace the balls, although, of course, I should have had them replaced weeks ago. Guess what did the trick to me? The sound.  Old tennis balls produce this particular “rotten” sound, and with my sensitive musical hearing, there came a time when I finally couldn’t stand it anymore, and took care of the replacement without further lingering. So, you can see that the “should” didn’t work, not until a higher value was challenged.

Single-Digit Teams and Mainstream Advice on Retrospectives

The closest I can get to a “how-to” style is as far as saying that a single-digit group (<10 people) is less likely to have communication problems, and more likely to act sensibly as a team, at retrospectives as well.  But again, organizations change and grow, and what has started as a small start-up becomes a mid-sized well-established business.

Back to the tips and tricks I’ve mentioned above. I can’t say that they’re good for nothing at all. Quite often, in a larger organization, there’s no real lever to influence culture shifts for people assigned to run retrospectives. If someone is confined in a certain space, like, a singled out task of doing a retrospective – then they would look for the ways to create some ado around this ritual, and operate in the limits for which they’re accountable. Role play, shuffling moderators, allocating fixed times, inviting clowns etc. — such advice is tailored to this very audience.

But I hope the awareness is there. The rituals do not set in motion the really powerful driving forces in a company. That’s what I’ve tried to outline in this part.