Guess which of these two retros was for the super smooth project?

Say Hello to the Edge Case Bash

The younger, better looking cousin of the Bug Bash.

A couple of my projects wrapped up recently—one project had gone incredibly smoothly, the other… not as much.

But in both project retros, nearly everyone pointed out what a delight the Edge Case Bash had been and how much time and heartache it saved us.

Cool, so what is it exactly?

It’s a meeting.

Ugh… I know, a PM writing a thought piece on Medium about how you should add another meeting to your project cycle. Ha. 😩🔫

Except, it’s amazing.

Suspend your disbelief for a moment and imagine you’re ramping up on a new project.

QA schedules a bash for a day or two after the project kickoff—once the engineers have had a moment to sort through everything, but before any substantial work has started.

Everyone comes:

• Design
• Research
• Analytics
• Engineering
• Quality Assurance
• … Everyone

The QA lead splashes the deck up on the big screen and you chat through it, slide by slide.

On every slide is something that has gone terribly wrong in some previous project at Yammer:

“Blocked Users: Ok, what about blocked users.. how could this be an issue in our project?”

Or

“Real-time! How will real-time mess up this project? And how could our project mess up real-time?”

And

“Languages with Foreign Characters! How will that come and bite us here?”

Etc, etc. etc.

At every slide we brainstorm as a team about different failures our feature could introduce here. Everyone brings a different historical knowledge, and different perspectives that make for quite colorful conversations.

And what’s the output?

At the end of the meeting, the QA engineer will have notes on the 40–50 ways your project could open the fiery pits and summon End Times for your product.

We’ve found that documenting ALL of them in a work tracking tool is super helpful for the team. From there you can prioritize which you’ll take into account during development, which you’ll explicitly ignore, which need automated test cases, and which need additional logging… etc.

Nothing like nipping ambiguity in the bud!

Bonus: Your QA team can use the edge cases as the basis for what to check in the bug bash!

and

Double bonus: At the end of the project, your team gets to add slides to the script for any new edge cases you uncovered!

To be clear, this is not a “pre-mortem”

Pre-mortems prompt open-ended discussion designed to uncover risks. Yes, some of the risks discussed will be engineering-related, but a lot of it is more high level, more focused on outside contingencies and the like.

A pre-mortem is a chance to lift your head out of the deep trenches of “we’re-doing-this-project” and look for any reasons why you shouldn’t do it.

An edge case bash is a chance to dig even further into the trench and look at all the gotchas that are hiding under rocks so you can have a better, faster, stronger, smoother execution cycle.

Why does it work so well?

Obviously, uncovering break points before they become an issue is a giant win for the project team, but this meeting is also a lot of fun.

It boils down to two elements:

1. Creative thinking—Everyone in the room puts on their wildest creative thinking cap and dreams up as many extremes as possible. That’s fun!
2. With constraints—Trying to be creative with indefinite parameters is really hard! And hard things are uncomfortable. In contrast, this meeting is really well defined: 34 slides, each with one type of edge case to consider. It offers enough of a prompt and enough of a constraint to get our juices flowing. You need both.

The QA team introduced this concept to our product development process a few short months ago. After a hot second of playing around with the format, this delightful touch point has spread like wildfire through the org.

Almost every Yammer project team ramps up with an Edge Case Bash and winds down with reflections on how helpful it was to have that in our process.

MAJOR hat tip to Donnie Karns and the whole QA/QE team at Yammer for instituting and guiding this process!

I’m always on the lookout for new, better ways to run a project team. If you have any similarly helpful tips or tricks, please share them below!