Do We Need Negativity In Retrospectives
Okay, spoiler alert: My answer is no. But this is true for a fairly specific definition of “negativity”, and you may have your own definition that doesn’t fit. So bear that in mind as you read, when I say “negativity”, I have something in mind, and you may have some other thing in mind.
Negativity is, according to the dictionary, an adjective that implies resistance, negation, opposition, something that is “lacking in positive features”. When I think of negativity, these are the terms I think in. Phrases that might be associated with negativity during a retro include “You screwed up”, “You did a poor job”, “We can’t change that”, “Management screwed us” and other things like that. The same ideas can be expressed differently: “We didn’t anticipate that problem”, “I did not understand the problem”, “We need to communicate our situation to management” and so forth.
To some, this sounds like double speak, like I’m engaging in an elaborate code or simple pronoun substitution to avoid saying what I mean. But I hope that the opposite is true: I’m trying to use language more precisely to avoid saying what I don’t mean. I rarely think that someone screwed up on purpose, but “you screwed up” has that ring to it. “We did not anticipate that problem” doesn’t. And if the person who made the mistake, the party most responsible for the thing that happened, did not act maliciously, then what else happened here? We did not anticipate the problem, that’s what happened. As team lead, more precisely, I did not understand the problem, and I did not put my teammate into a position to win. I failed him or her, not the other way around. We win and lose as a team, though, and I rely on the rest of the team to know things that I don’t know, so we did not understand the problem, which is a situation that we can attempt to solve. Our lack of understanding is a situation we can do something about. It has positive features. You screwing up does not have positive features, and it’s inaccurate besides.
Actually, we don’t even need to use phrases like “We didn’t understand the problem” to address the problem, although it helps. We can be overwhelmingly positive, and say “We can do a better job anticipating problems like this in the future”.
You may want to object that by bringing up “problems”, I’m already venturing into negativity. My definition of negativity doesn’t really go that far, but if yours does, that’s fine. We don’t need to talk about problems. We can talk about things that happened. One of my favorite colleagues from ThoughtWorks would say that sometimes: “Okay, that was a thing that happened. Why did it happen, and do we want to have things like that happen in the future.” Now it isn’t even a problem, it’s just something that happened. We don’t actually have to judge the badness of the thing at all, we just have to decide whether we want future things to happen in the same way, or in some other way that we think will be better. And again, this is about accuracy, effectiveness, and attention to detail, not sparing people’s feelings in any way. The dropping of the database? That’s a thing that happened. As a result, many things had to be done. Money was lost. How can we not drop the database in the future?
Having one person to blame for that? Doesn’t help. Focusing on how “bad” that was? Doesn’t help. We should have had a postmortem about that, anyway, because it was a big thing that happened. This is retrospective, and what we want to do is improve our process. Focusing on how bad the database dropping problem was doesn’t help us do that. Knowing who did it doesn’t help us do that. Knowing exactly what happened, how it happened, and how to prevent it from ever happening again? That helps us.
Maybe the answer is improved training. If improving training is the solution, it might help to identify the people who need the training. It is obvious that the person who dropped the database needs the training–actually, they may no longer need the training, having learned the hard way–but less obvious who else might need the training. That leads us to ask “How do we identify individuals who might need more training on devops?”
Note that this is a place that we want to get to in our retrospective. We want to get to the place where we are asking questions that don’t obviously flow from the events of the iteration. And the key thing is that we don’t even need to know who dropped the database to get here. In fact, highlighting who was the proximate cause of the problem leads us away from this very valuable place. Thinking about how bad the situation was doesn’t help us to get here either. All we needed to know was that there was a thing that happened, and we’d be better able to focus on our story work if things like that thing didn’t happen, and ask how we can make that happen. And in that context, I don’t actually care who did what, because that’s a distraction. I don’t want to focus on the person who should have warned them about the dangers of logging into the production server, because that is a distraction. What I care about now is “How do we identify individuals who might need more training?”, or possibly “What training do we need to put in place?” or “What safeguards can we put in place in case we think we’re logged into QA but we’re actually in Production?”
Heck, I don’t even have to acknowledge that dropping the production database was a “bad” thing at all. I could claim it was a good thing, but that not dropping it would be an even better thing. For example, “The production database was dropped, which gave us a much needed chance to practice our disaster recovery skills. I believe this was a valuable learning experience for the team. In the future, I believe we can simulate dropping the database in order to hone our disaster recovery skills, which will allow us to more effectively plan when we want to practice disaster recovery. To that end, I’d like to discuss measures we can take to prevent us from dropping the production database in the future.”
Okay, I wouldn’t say that, mostly because I couldn’t do it with a straight face and I don’t talk like that, but it is a perfectly viable way to look at the situation. We don’t need any negativity at all in retrospective in order to identify areas of improvement. Besides, it was a valuable experience in disaster recovery, and maybe we learned that we do see a value in running realistic drills. Why not acknowledge the good?
Retrospective is not one-on-one feedback. It isn’t the time to point out the shortcomings or mistakes of any individual. There are other times to do that sort of thing. There are other times to offer constructive criticism to an individual. Retrospective is about making a good team, your team, better. And you can do that without any negativity at all.
Originally published at www.johnpdaigle.com on July 27, 2014.
