Bringing Fun to Team room

I am big believer of encouraging teams to laugh and have fun together. In my mind it builds team's resilience.

Is it easy! NO WAY!!! It is the most difficult think to achieve when you are around bunch of engineers. I have been part of mora than 30+ teams so far and half of my team member appreciated being left alone to code. 

I never give up and have lots of different post standup.  I have few categories

Sheer Fun:

• Trivia after standup -  Pick a topic or theme for a week and ask one  trivia question after standup. Provide team all the details along with the answer. This way team is learning and having fun. Great for co-located and distributed teams. 
• One Urban Dictionary word of the day - Open the webpage and ask the team to put hands together. Read the word and meaning together and say the word loudly at the end. Like sports team does. Distributed Team members can do the same as well. 
• 15 seconds warmup - Pick any song with steps from youtube and jam together. Perfect for all teams.
• Shake up - There are lots of games on PlanningForFailure website. These are a minute long and perfect for teams
• Lifting weight: Start with 5lbs weight as standup token and then increase the weight slowly every iteration by 2 or 5 lbs. This will make your team strong every day and will not let them talk longer as well. 

Games for Late comers but can also be played on regular basis:

• Sing a song in local language or some funny song
• Tell a chuck norris joke 
• Bring some sort of treats (donuts or cookies or fruits) 
• Sit on a broken chair or wear a kind of hat entire day. 
• 5 Sit-ups or push-up for every minute you are late
• Facilitate the scrum next day

These are the few things which I have tried in my teams. Let me know if you have done something interesting and fun :).

Enjoy!

Manisha

Extrasss: I play games before Demo and Retrospective all the times as well. I get my ideas from http://www.funretrospectives.com/ and http://plans-for-retrospectives.com/?id=3-86-26-61-40 and tasty cupcakes site. 

What to make big and visible in team room?

In our world metric plays a very important role in enabling us to answer questions and solve problems. A good metric would always provide valuable information to the team. There are good and bad reasons to gather metrics.

Good Reasons
------------------

• To understand one's own progress
• To solve a problem with the data

Bad Reasons

----------------

• To facilitate competition between teams
• To motivate a team to do better (Motivation should come within the team. It should not be extrinsic.) 
• To have control over a team
• To set a goal or incentive for a team 

A good metric should set a mood at a glance from across the room. By looking at it, you should be able to say a trend or behavior over time. A metric should either make you feel good or make you feel bad, depending upon what you see. It's aim should be to generate right behavior and discussion in the team room.

Example of few team room metrics:

1) Total # Backlog items by week

By looking at this graph you can say week 6 lots of requirement got added. How so many new requirements got discovered? what are those new functionality?  It will definitely going to make few people think about them and would make team look deeper into these new requirements. 

2) Commitment vs. Capacity per iteration:

This metric is very self explanatory. It helps team find it's true potential.

3) Product Burndown Chart with Standard deviation (More here)

By looking at it team can find out weather they will going to go live at the expected time or will need to do some adjustments.

4) Velocity chart per iteration (It is not burndown chart):

It is team's velocity over the period of time and an average line showing the trend. It is difficult to look at the raw data and infer if team is improving or not but black like clearly indicate that team is getting better over time.

5) Impediments (anything which is slowing team) per Iteration:

Simple yet very powerful metrics.

6) Risk burndown per Iteration: I follow Mike Cohn's prescribed approach and works perfectly fine in our context.

7) Product Owner's Time per day: This metric is very useful if you have same problem like ours. Our product owner was divided amongst lots of work stream. He could not spend time with team at all, so having a metric like these helped us resolve the issue with upper management.

8) Defects per demo metric: The title pretty much explains the purpose.

9) Number of unscheduled requests per iteration: Gather this data if your team getting requests from outside forces a lot.

10) Wait time per iteration: Any time team is waiting for response from DBA or Production Deployment teams or Any external dependency on regular basis.

11) Wasting of time per iteration: One of my team's lots of time was getting wasted on an old tool. We had to use that tool since it was company standard. We started tracking time we were wasting per iteration on that tool and got it replaced after 6 iterations.

12) Team Expenses vs. ROI per Iteration:  I believe this is a very important metric in agile team. How quickly are we being able to delivery value?

13) Behavior per Iteration: This can be anything which you would like to capture over time. i.e. Code coverage per iteration, number of attendees per demo etc.

These are few metrics which I have in my toolbox. Let me know anything interesting you have tried which has worked very nicely for your team.

Cheers!
Manisha