I agree with you, which is why I prefer to communicate these issues in full context rather than put smilies on a board and lose said context.
I can barely remember what I did the previous day in the morning scrums unless I worked on one specific thing only, I can also have many happy, so-so and frustrated moments every day.
This is why I feel such a board to be useless. You can't easily gamify or fake authenticity in face-to-face conversations.
We run about 20+ parallel projects in the company, with teams ranging from 6-10 to 40+. Retrospectives are a terrible way to share information in such a context as teams get formed and changed all the time. I frequently spend time helping 3-4 projects every week on top of my assigned project.
We simply don't wait until the end of a project to fix problems, there's often too much at stake. Just like we don't wait the next day's scrum to fix an issue - we use scrums to make sure everyone is on the same page. We instead have monthly all-company short presentations by teams wanting to show their results during lunch time as well as more focused monthly presentations on company time.
It's not perfect, but I'm pretty sure it beats months of smiley faces. What does it even mean to aggregate smiley faces? I fail to see the value of saying "we were happy 75% of the time during the last project" without understanding why.
Yes, aggregating mood for a whole project then looking back afterwards and saying "yep, that was the data" would be pretty useless for getting that product shipped. But, that's not what's being claimed. The claim is that the smiley calendar is a tool that helps everyone spot some problems and trends. This is in addition to having a few managers keep in-practice private (and probably mental) logs of everyone's mood over hundreds of face-to-face check-ins.
The value I see in this is that people sometimes totally do fake their mood face to face for a variety of reasons. People sometimes will also totally fake being overly happy on a board too. It's just one more opportunity for people to bring problems to the surface. It'll work better for some people than others, better for some teams than others. But, when it works it would be tremendously valuable.
Like most useful metrics, the chart can show trends that correlate with other documented time series metrics. These can be reviewed periodically at regular intervals. Retrospectives can be held whenever it helps the team, e.g. at the end of each sprint/iteration cycle rather than only at the end of a project or major milestone. YMMV, and agile is all about what works for a particular team.
