I learned a lot in college that is applicable to my life and career…and some of it was even in my classes. Nowhere was that more true than with my time doing comedy improvisation. At the beginning of my sophomore year in college, I tried out for an improv group called the Rice Pilaf Players. If you picture Whose Line Is It Anyway?, you’ve got a good picture of what it was like.
Comedy improv taught me to be better at public speaking, thinking on my feet, and reading people. I also learned what people think is funny and how to be a better conversationalist by listening carefully and asking good questions.
But perhaps the most important lesson I learned–one that I’ve found very applicable to business and software teams–is also known as the first rule comedy improv: “yes, and…”

The “Yes, And…” Rule

There are lots of tricks and rules in comedy improve, but the most important is known as “yes, and“. The “yes” suggests that an improviser should always accept whatever another participant offers. The “and” says that they should add something more, building on top of what was already given.
For example, imagine two players are beginning a scene together. Like in all improv sketches, these two have had no time to talk or prepare, and they do not yet know what the other person is thinking or what story they will end up telling together. Now imagine that as soon as the lights come up, player one starts swinging an imaginary ax and wiping her brow. If player two is following the “yes, and” rule, he will see that and accept it. He should not do something completely different, like walk up to her and say, “The doctor will see you now.” That would be like saying “no” to her offer.
If he’s really good, player two will add something valuable to the offer already made by player one. He might start swinging his own ax and say something like, “I sure could go for some pancakes right about now.” This takes player one’s ax swinging suggestion and turns it up a notch by suggesting they are lumberjacks, giving the first player something new to react to.
This scene is now a true collaboration between the two players. They’re now a team.

“Yes, And” for Software Teams

“Yes, and…” doesn’t only work in improv. Over my years in the software industry, I’ve also noticed how applicable it is to teams working on software projects. When a team member suggests a new process improvement, her team members have a choice. Will they say “yes” or “no”, and if they choose “yes”, will they simply sit back and let her do all the work, or will they collaborate with her by adding something to the idea to improve it.
Too many software teams rely on the “rock star” or “hero” mentality, in spite of a lot of evidence that teamwork can have a “1 + 1 = 3″ effect on output. Your team may rely too much on a”hero” if there’s just one person who is the go-to person for most things or if only one person is doing the innovating.
Of course, there is a place for “no” on software projects. Sometimes team leaders have to reign in an effort that is going in the wrong direction, and there are certain personal behaviors like harassment or bullying which require a strong “no” from management. However, even on a healthy team, people can get stuck on their own ideas or “the way it’s always been done”, so a shift toward “yes, and…” style thinking can be very beneficial to any team.

Antipattern: No Instead of Yes

Engineers have a tendency to fall in love with their own creations and ideas. Sometimes this predisposition can prevent them from being open to new ideas, especially from an outsider like a new team member or contractor.
This behavior amounts to saying “no” to teamwork, and even one person on the team doing acting this way can prevent collaboration from taking place. Everyone has to be trying their hardest to say “yes, and…” to make the team a safe place to try new things.

Antipattern: Yes Without the And

Of course, saying just “yes” without adding anything isn’t that helpful either. This can result in letting just one person on the team make all the decisions, and it misses out on the contributions of all of the other team members.
This may be happening on a team because one team member is more experienced, more domineering, or just because the other team members don’t value their own contributions as much as they should. Making others’ suggestions your own by building on them is how a team spirals upward.

Antipattern: But Instead of And

All ideas have at least one problems that make them imperfect solutions. It’s tempting for engineers to jump straight to the list of problems with a “but”. Instead, reserve your judgment until you have an idea to add that will solve your own objection, and then suggest it. This is offering an “and” instead of a “but” to the original idea.

Summary

There are many ways to think about the “yes, and…” rule that can revolutionize teamwork and collaboration on software projects. What rules and practices do you use to help you and your teams say “yes, and…”? Please share them in the comments section below, and offer your “and” to this blog post.