Tina Fey’s Four Rules of Improv, as applied to Scrum

Driving home for Christmas, I listened to the audiobook version of Tina Fey’s Bossypants.* Listening to her read the chapter Rules of Improvisation That Will Change Your Life and Reduce Belly Fat, it struck me that the four rules of improv that she describes translate well to the spirit of Scrum projects.

1. The first rule of improvisation is AGREE. Always agree and SAY YES.

This rule for me is about openness and the willingness to engage with new ideas and new practices. As Fey explains it:

When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt.

The blue screen of death moment is any meeting is when you hear someone say ‘We can’t do that’, or ‘We tried that before and it didn’t work’ or ‘The IT team won’t let us do that’. That moment sucks away at your enthusiasm for the project and if it happens enough, drains your will to work.

A recent Scrum project I worked on had a brand new team working to create a prototype for a mobile app in six two-week sprints. At the beginning of the project, the team’s most common reaction to the Product Owner’s stories was ‘We can’t do that, because…’. This resistance was a real downer for the Product Owner. By the last sprint, the team was saying ‘We can do that by ….’,  explaining what the potential issues were, and suggesting how to overcome them. The Product Owner told me this was one of the most satisfying aspects of the whole project for them.

2. The second rule of improvisation is not only to say yes, but YES, AND.

If your reply to “Freeze, I have a gun” is “Yes, you have a gun”, that doesn’t do much to advance the scene. YES, AND for Fey means not being afraid to contribute – in fact, seeing contributing as your responsibility.

When I heard this, I thought about things from the Scrum Master’s point of view. At the start of a project, when you’re the Scrum Master, you sometimes find yourself trying to coax quieter team members into joining discussions. You don’t want to have to do this for much more than a sprint or two. A team that needs the Scrum Master to help them talk about stories or solutions isn’t self-organising. The Scrum Master can however help create an environment where no-one feels afraid to contribute, and coach people to see contribution as part of their role on the team.

3. The next rule is MAKE STATEMENTS.

Fey writes:

This is a positive way of saying “Don’t ask questions all the time.” If we’re in a scene and I say, “Who are you? Where are we? What are we doing here? What’s in that box?” I’m putting pressure on you to come up with all the answers.

In other words: Whatever the problem, be part of the solution. Don’t just sit around raising questions and pointing out obstacles. We’ve all worked with that person. That person is a drag.

I took two things out of this. One was that MAKE STATEMENTS would be a handy poster to put up next to a Scrum board if your team has a tendency to turn a 15 minute stand-up into a 45 minute philosophical discussion.

The other thing was a reminder of how much I love the way Scrum lowers the threat level of decisions. When you’re responsible for a project, making decisions can be scary. Signing off the final design in a waterfall project, for example, means acknowledging that any changes you want to make further down the line will almost certainly be difficult and expensive. If making decisions is stressful, one natural reaction is to delay or obfuscate. However, when you’re a Product Owner on a Scrum project, you’re making decisions all the time. You get used to making the best decision for the moment, and understanding that if you need something to change in the future, you’ll just write another story. This lowers the threat level of decisions considerably, and helps your team a lot: making decisions is a lot like making statements.

4. THERE ARE NO MISTAKES, only opportunities.

If I start a scene as what I think is very clearly a cop riding a bicycle, but you think I am a hamster in a hamster wheel, guess what? Now I’m a hamster in a hamster wheel. I’m not going to stop everything to explain that it was really supposed to be a bike.

The lesson here for Fey is that some of the world’s greatest discoveries have been happy accidents (think Viagra). There’s a useful lesson here about being open to suggestions and discussions, rather than clinging to your original set of assumption and opinions. This is why user stories are written in terms of what and why, rather than how.

In conclusion

Firstly, Bossypants is a great read (or, if you like audio books, a great listen).

Secondly. Improv is the act of working together to build something new from a bunch of quickly generated ideas, pruning off things that don’t work and building on the things that do along the way. The more an improv team works together, the more they trust each other, and the better they know each others’ strengths and how to use them. A lot like Scrum projects, over all.

*I was recounting this to a friend over the weekend, who flummoxed me by asking who Tina Fey is. So just in case – ladies and gentlemen, Tina Fey.

Related Posts:

Post Tags

6 Comments

  1. PM Hut
    Jan 12, 2012 @ 00:59:13

    Hi,

    Who’s Tina Fey?

    In any case, what Tina is saying is ideally right, but practically wrong. You have to say no to many things. In every meeting you have over a dozen crazy requests and it’s impossible to say yes to all of them. Even for the non-crazy requests, you have to say no for most of them, otherwise, you will derail the project.

  2. Vin D'Amico
    Jan 12, 2012 @ 02:25:41

    Love this! Many people like to throw up roadblocks. They make an extra effort to come up with reasons why something won’t work. Okay, fine, there are always risks and challenges. However, it’s far more productive and valuable to suggest ideas for getting to done. Stimulate a conversation around a successful outcome and the team will find a way to make it work.

  3. courtney courtney
    Jan 12, 2012 @ 08:54:32

    @Vin – totally agree.

    @PM Hut – It sounds like you’re talking more about waterfall projects and problems with scope creep (or poorly articulated feature requests) than Agile projects. What I took from Fey’s “say yes” was more metaphorical than literal: it’s about starting every conversation with an open rather than a closed attitude. Sounds a bit like hippie bullshit, I know – but it’s a much more satisfying way to work.

  4. Breccan
    Jan 12, 2012 @ 14:07:54

    I’m in the middle of writing a very similar post although more focussed on improv and innovation. I just did an 8 week improv course at the end of last year and it was excellent.

    Also, there is a bunch of stuff you just don’t do in improv if you want your scenes to be successful. It’s just that if it happens on stage you try and work with it and then address the issue afterwards. Which is probably worth pointing out to those who think these ideas are permission to go too wild.

    Pixar is very into improv as an inspiration – Peter Sims’ little bets talks a bit about how they use its tenets.

  5. courtney courtney
    Jan 12, 2012 @ 15:35:16

    Hey Breccan

    Nice to hear from you! Please come back and leave a link to your post when you’re done :)

    And yeah – I think it might be possible to read this post as a “Woo-hoo! Go nuts! No rules! Say yes! Do it all! Right now!” endorsement. What I maybe should have emphasised is that Scrum (like improvisation) provides a structure that allows you to channel what to the outside might look like crazy energy and chaos. It’s approaching what you do with an anything-is-possible attitude that links the two practices together for me.

  6. Chelsea
    Jan 17, 2012 @ 13:21:22

    Great post Courtney. I can totally see the connection between Scrum and improv, and I think the fundamentals of improv can apply to many aspects of our professional and personal lives.

    In addition to the four you’ve outlined, I’d add two more improv fundamentals that might be useful to think about when you’re working with scrum, especially relating to teamwork:

    1. Trust each other. On stage, you have to trust that your fellow actors are there for you. This is perhaps more important in improv than in scripted theatre because you rely so heavily on being present in the moment with your fellow actors. This applies quite well to Scrum, where decisions about focus and direction are being made frequently and quickly.

    2. Stay positive. This is probably just another way of expressing the ‘Say yes’ principle, but it’s important to stay positive, especially in team environments where low moral can be very contagious.

Leave a Comment

*