Beyond “YES, AND”: What Product Development Teams Can Learn from Improv

What do Tina Fey, Amy Poehler, and Daniel Vacanti have in common?  They are great agilists.

Think about it. All three listen, observe, and react creatively to unfamiliar scenarios. Each of them enjoy testing new moves quickly and pivoting based on feedback. Improv and product development are quite similar: at their finest, they rely on trust, communication, and collaboration. Done well, both deliver top performance.

Before your next sprint, consider taking a page from improv’s book to strengthen your team’s flexibility on the fly:

YES, AND…Now What?

Perhaps the most fundamental and well known tenet of improv is “yes, and”. For those unfamiliar, here’s how “yes, and” works: to make a great show, troupe mates actively listen to one another, agree to the last thing said (“yes”) and build upon that reality (“and”). “Yes, we are both farmers, and I’m going to propose to you with a ring made of corn”.  In a product development environment, “yes, and” can look like “yes, I understand the value of this functionality and think X functionality would be great too” or “yes, I found this bug, and I understand the priority of when I should fix it”.

Now let’s say you and your team have “yes, and” down like pros. Everyone’s jazzed that the lights are up and the sprint has started. You kick off your stories. You deploy new functionality. But then… you find a bug. You miss a deadline. The client is not happy about what is deployed even though it’s meeting the requirements they defined. The “yes, and”s revert back to full stop “no”s.  “No, that payload is wrong”.  “No, I can’t take this hotfix”. “No, the story is 13 points, not the estimated two”.

What went wrong?  You and your team “yes, and”ed… until you didn’t.

“Yes, and” is the starting point for a great show, however, it’s not the only point needed for a team to be prepared for all the unexpected things that can (and will) happen during development. Let’s dive into other fundamental rules in improv that can help your team deliver a sprint they can be proud of together.

Define Your Character

Nothing is more jarring in an improv show than incongruence. Imagine: one troupe member steps on stage, saying “I’m the doctor you called, I’m here to fix your leg” and a fellow troupe mate responds, “You’re not a doctor, you’re an astronaut! We’re about to land on Mars!” The audience is confused. Are they watching a surgery or a space scene? The first performer is thrown off, too, and probably irritated that the other troupe mate negated their clear declaration of purpose.

In product development, how many times have you heard “Oh, I thought you were going to do XYZ because you’re the “[insert role here]?”  How many times have you said “Oh, I thought you were going to do XYZ because you’re the [insert role here]?”

Maybe you’re a quality engineer with experience in test automation suites but the client expects you to be the scrum master across four pods. Or perhaps you’re an engineer who assumes the quality engineer is going to test functionality in development first, but the quality engineer is expecting you to test first. Or consider this scenario: it’s thirty minutes into a virtual kickoff and no one hit record… because whose responsibility is that anyway?

Whether you’re working with a brand new or familiar team, or rolling on as a lead or a contributor, it is important to define your role and skill set so your team has a clear idea of what they can or cannot expect from you. It is equally important to avoid defining other people’s skill sets as you could be incorrectly defining their abilities.

Consider doing accountability and responsibility exercises with your team early and often so gaps in responsibilities aren’t masked with assumptions. Avoid using a template of responsibilities from another team or online – have each person (yourself included) on the team define what skills they bring to the table. Revisit responsibilities when new team members roll on or off, or when shifting gears between engagements, to confirm the “doctor” is still a “doctor” and not an “astronaut”.

“I got your back”

Before improv performers step on stage, they convene in the green room, where it’s common to see performers making eye contact with one another while patting one another on the back, saying “I’ve got your back.” It is both a physical and audible reassurance of camaraderie and trust in fellow troupe members that remind them no matter how amazing or terrible the show is, “I’ve got your back”. Taking that first step into a new scene not knowing what you’re going to say is not nearly as scary if you know your team is going to support the heck out of you.

When was the last time you said the words, “I got your back”—or at least some flavor of the phrase—to your product development team?  When a deadline was missed, when the acceptance criteria was missed, or when a hotfix merge broke something in production, what was your first team-facing reaction?

There will always be “lessons learned” when developing a new product. Make your first response when things go awry some version of an audible “I got your back” to give your team the psychological safety to address the problem.

The success of a project is always going to look different on day 90 than it did on day one. We know that whenever ‘the unknown’ starts becoming known, scope and complexity shoots through the roof. Setting the expectation—and saying it out loud— that we’re facing that challenge together, primes the team to embrace impact and react together.

The API you thought could use is missing key information, cool.  Your PO has your back and starts to communicate the impact to stakeholders.  The functionality you just finished is missing some of the acceptance criteria, no worries. Your teammate suggested for you to include the changes in a PR review.  You accidentally trip when you enter a scene, perfect.  You helped established you and your family live in a town where everyone trips.

The show will end… and you’ll be better for it.

Regardless of whether the show was a rough time or the best performance ever, the lights go out and each performer exits the stage. They will live to do another show, and in that next show, they will rehash the moves that got the applause and avoid ones that led to crickets.

Has a team member ever gotten sick during a critical release, making the rest of the team scramble to cover their work? How often have you felt like your team is working on more stories than when the sprint started? Have you ever had a sprint that went off the rails and thought it would never end?

Retrospectives are an excellent tool to symbolize we are all still in one piece, together, regardless if we have hit the sprint goal or not. Retrospectives are also a key tool to celebrate wins to carry over to the next sprint or acknowledge and identify the heartaches from which the team can learn and grow. At the close of each sprint, retrospectives serve as a reminder that you are not the same team as you were at kickoff.  For the next sprint, let’s identify who’s responsible for what when a team member is down.  Let’s find ways we can hold ourselves accountable when taking on new work.  Let’s figure out how to keep each other focused when things get out of hand.

Step off the stage, shake it off, reflect, re-group, do the show, repeat. That’s The Improv Equation (not yet trademarked).

And that’s a wrap

Similar to improv, working in product development and in an agile environment to build working software is complex. But it doesn’t have to feel chaotic. Conditioning yourself and the team to define your ability, communicate through thick and thin, and understand the time box of a sprint will always expire, sets you and your team up for success. As with all things, it takes time and practice to create a show—or product—worth applauding.

Key Takeaways

• It’s important to define your role and skill set so your team has a clear idea of what they can or cannot expect from you.
• It is equally important to avoid defining other people’s skill sets as you could be incorrectly defining their abilities.
• Consider doing accountability and responsibility exercises with your team early and often so gaps in responsibilities aren’t masked with assumptions.
• Have each person (yourself included) on the team define what skills they bring to the table.
• Expect that there will always be “lessons learned” when developing a new product.
• Setting the expectation—and saying it out loud— that we’re facing that challenge together, primes the team to embrace impact and react together.
• Retrospectives are an excellent tool to symbolize that we are all still in one piece, regardless of whether we have hit the sprint goal. Retrospectives are also a key tool to celebrate wins and to identify heartaches from which the team can learn and grow.