Is Having Fun Important for Agile Teams?

Working in an agile team can sometimes be stressful. For instance when the needs of the customers are unclear, if there is a lot of work to be done, or when team members are having difficulties doing their work. You might ask the question if having fun could reduce the feelings of stress, increase motivation, or increase productivity? And if that is true, then what can you do to have more fun in agile teams?

In are you having fun?, Valerie Santillo explains why she thinks fun is important for agile teams:

You know you’re on a good team when you have fun being with your teammates.  To me, having fun at work is critical.  I have worked on really difficult, not-fun projects but had a great time with my team in spite of crummy work.

As a Scrum Master, it’s great to hear a team laughing and enjoying being around one another.  It’s part of their hum and single entity identity.  When people are having fun, they like being at work and will engage more.  This only makes for a better end product.  If your team isn’t having fun think of ways to get it going.  Have a happy hour together, start going on walks, look for interactive and engaging (somewhat silly) team exercises, use the Chuck Norris idea.

Having fun and celebrating success is mentioned by Alex Krause in his top 10 learning's as a product owner:

If you fill in a little bit of fun during meetings they are so much more fun, the team is a lot more motivated and they enjoy working together with you a lot more. If the meetings you are responsible for are fun to be in, people will like to attend. And do not forget to celebrate success. Bring candy to the sprint review. Champagne or beer after a major launch – depending on the team’s preferences.

Ian Mitchell describes what sprint reviews are and how you can do them in his blog post sprint reviews in practice. Bringing fun into a sprint review can help to increase the chance that teams will do them:

Have fun! Bring cookies, drinks, and other refreshments. Consider interspersing the review with short activities or breaks for games. Pub-quiz type questionnaires are popular and I've even known small prizes to be given to the winners.

Catia Oliveira wrote a blog post called Scrum Master TIP #6 – Retrospectives in which she explains why people that have worked hard to deliver results can hate it to do retrospectives: 

In retros you ask them mainly to talk about human relations and to talk and define action plans to deal with “not so successful things that happened last sprint”. And here I mean FAILURE. (…) Every time you miss the deadline or the scope, or you deliver bugs rather than software, rather it’s other’s or your own perception: it tastes like pure, smelly  Failure. Obviously that teams work their .. buttock..  out every single day, so most probably they hate to see things haven’t worked out for the best. As such do you think it’s easy or pleasant to talk about it?

The job of Scrum masters when doing a retrospective is “to make them have FUN”, as Catia states:

So make your retrospectives fun. Less embarrassing, less formal, less painful. Make it easy for them to talk about failure. Make it easier for them to have fun and grow together.

In a recent InfoQ interview about using lessons learned as a dungeon master on role-playing and games in agile coaching, Guillaume Duquesnay shared his thoughts on the importance of happiness and fun:

I'm a bit cautious with the connection between happiness, fun and productivity (i.e. delivering more value). I started the other way: being connected to a purpose and fulfilling it makes people happy. Regarding fun, I don't see it as a performance trigger. Sometimes, hard stuff has to be said before improving. (…) Responsibility is not fun, co-responsibility is no more. A safe person to person feedback should not be fun, but straight and caring.

In his blog post hyper-joyful, Bob Marshall talks about joy and joyfulness in the workplace:

I don’t see joy being the explicit focus of much attention in the world of software and product development (or in many other theatres of work either, for that matter).

I’ve given this post the title “hyper-joyful” in reaction to the concept of “hyper-productivity” which I’ve seen bandied-about more and more often recently. I can’t help but feel scornful and dismissive – and yes, sad, too – every time I hear or see the term “hyper-productive”. It’s not like Agile often lives up to that aspiration, in any case. Who, in fact, can get a feel-good feeling about hyper-productivity? (…) Personally, I’d feel much happier if more folks talked a bit more about hyper-joyfulness – and a bit less about hyper-productivity.

In the blog post can agile teams get "burned out"?, Robert Galen writes about the causes and indicators of team burn out and team refreshments. One of the burn out indicators that he mentions is a lack of humor and fun. This can happen when a team is too focused. Robert proposes several ideas to refresh and recharge team, one of them is to “Go Have Fun”:

Get out of the office and do something that the team enjoys; either as a team OR as individuals. I’ve seen some teams focus on gathering together for fun. I’ve also seen teams who realize the commitment folks make to work and go off to spend some special time with their families. And sometimes there’s a combination of the two. As an agile leader, I’ve often provided funds to the team to support whatever activity(s) they come up with. My only stipulation is for them to have fun and get some decompression time.

Working in teams with customers that do not know what they want can be frustrating, says Rudi van der Made. In his blog post Scrum is fun he describes how Scrum helps teams to deal with this:

(…) the popularity and success of Scrum is thanks to the fact that it addresses, and solves, the frustration. It actually makes complex teamwork fun, with quality and productivity as by-products.

Improved communication is a first key factor that makes Scrum more fun, for example by having developers doing daily stand-ups:

After some time you’ll see that even the developers that preferred working alone in silence, start communicating and working together. That’s a huge return on investment for just a bit of scheduled interest in each other’s work. It creates a more lively working environment, and consequently more fun.

Increased involvement of the business is the second key factor that Rudi mentioned: 

The other important fun-factor that a good Scrum implementation enforces, is continuous involvement of the Product Owner. Communicating with all stakeholders and managing the Product Backlog are very important tasks for the Product Owner, but it is equally important that the Product Owner is involved with the Development Team during the Sprint. There is simply no other way to make sure that the product is ¨potentially releasable¨ at the end of the Sprint.

Is having fun important for agile teams? What did you do to have more fun with your team, and how has that helped you?