In our daily standup recently one of the developers on my team mentioned that he’d scheduled a meeting with the other engineers to go over the results of a spike ticket he’d been working on. Product nerds aren’t usually included in spike meetings as they tend to be a little more technical than is relevant to us, but as it was I had a particular interest in this spike and did want to hear what the research had yielded. So I asked to be included in the meeting. Actually, I pretended (hilariously) to be hurt that I hadn’t been invited, as if it was a party I’d been left off the invite list for and not, you know, a work meeting. I’m fun.

The team obliged me, both with laughter at my histrionics and with an invite to the meeting. As it turned out I had to spend a bit of time reassuring this developer—who was a newer member of the team—that I had not actually been offended at having been initially excluded from the meeting, and that all of my antics had only been in the interest of comedy. (I have a bit of a bad habit of chasing laughter to a fault sometimes, but that is perhaps a blog post for another day…)

I thought that was the end of it, but it came up again at retro that the team wanted to do a better job of including all the right people in meetings. Assuming this was once again about my very intact feelings, I assured the team again that I had really been joking, I promise, for real, not offended. But even though they believed me (or said they did) they still thought there was genuine room for improvement here. The dev manager had also been interested in the results of the spike, and he hadn’t been initially included in the meeting, either. He was in the standup when we learned about the meeting, but had perhaps been distracted by some managerial task or other and had not requested an invite. As I gave him the highlights after the fact, he was disappointed to learn that he’d missed it (but was happy to hear that it had gone well).

Regardless, after the team discussed the item for a bit, it occurred to me that this perceived “failure” (or at least thing “to improve”) fit a particular profile I’d started to notice popping up occasionally.

That is to say, it wasn’t a failure at all. It was, in fact, a success. Stay with me.

Let’s look at what actually happened:

1. An engineer scheduled a meeting that product nerds and managers are not usually included in. He did not include the product nerd or manager.
2. The engineer gave the whole team (including product nerd and manager) a heads up about the meeting and its purpose ahead of time.
3. The product nerd heard this and asked to be included. The manager did not.
4. The engineer included the product nerd.

Where in that sequence was the team’s failure? Perhaps they’d failed to read the manager’s mind to know that he’d wanted to be included in the meeting? Or was it that they’d failed to predict the future—that I was going to want to be there?

I’m deeply skeptical of improvement items that are essentially “be more clairvoyant next time.”

A few other “failures” that fit this bill:

• A story turned out to be more effort than we estimated it to be.
• We ran into a high-severity bug and had to spend time fixing it.
• We learned halfway through working on something that someone outside the team had some particular expertise we needed, and reached out to them.

The key commonality in all of these scenarios is that the complication was unforeseen. When things don’t go as we expect them to, it can be tempting to put those experiences into the “failure” bucket. We talk a lot in Agile about inspection and improvement, and I think maybe we’ve over-primed ourselves to try to fix everything, even things that aren’t broken.

To improve:

Recognize and celebrate more successes.

Here’s another scenario (hypothetical this time): You’ve received a delivery to a package locker on the other side of your neighborhood, and you’ve got a little slice of free time, so head out to pick it up. You make it a block or so from your house and it starts to rain. You head back, retrieve your umbrella, and restart your journey. Was this a success or a failure? Your walk took a bit longer than you probably planned for. But when you encountered an unexpected complication, you dealt with it by using the tools at your disposal—in this case, an umbrella. Success!

Now, are there steps you could have taken to avoid having to go back for your umbrella after you’d left the house? Sure. You could have checked the forecast, and if you’d seen that rain was expected, you could have taken your umbrella with you. Although, you could just as easily have wound up carrying an unnecessary umbrella with you the whole way.

Even better, you could have attempted to eliminate the possibility of getting rained on, ever, by constructing a covered walkway all the way from your house to the package locker. This is a great solution! You only have to set it up once, and it benefits everyone who takes a similar route to the locker, protecting them all from any possible rain, rather than the single-person utility of an umbrella.

Except for when it inevitably needs to be repaired or maintained, or the neighbors complain that it’s ugly, or the parcel locker gets moved somewhere else… but this post isn’t about decrying complicated automated solutions to simple problems.

My point is that unexpected problems are not failures. Having to ask to be invited to a meeting you wouldn’t normally attend is not failure. Rain is not failure. They are challenges, sure. It is the way we handle those challenges that becomes a success or a failure, but we have better things to do with our time than try to prevent any scenario where we may need to improvise a bit. Instead, let’s focus on becoming better improvisers.

To be clear, I’m not saying that every scenario is actually a win as long as you learn something from it. Failures do happen, and learning from them is important. But we diminish our ability to identify and learn from real failures when we muddy the waters with stuff that’s outside our control.

We’re not going to be able to predict every obstacle that might slow us down or require us to change our approach. If we expect that level of perfection, of course we set ourselves up to “fail.” And when we put stuff like this in the “to improve” column, we face only disappointment when our psychic powers inevitably fail us again next sprint.

Instead of considering it a failure that an unexpected thing happened, let’s accept that unexpected stuff is a fact of not just work, but life in general, and focus on what worked and what didn’t about how we handle those moments. And let’s recognize and celebrate when we handle them successfully.