Usually the Daily Scrum meeting is held around the beginning of the day, but that's not a rule, and in many cases (because of time zones) it is not even true.

The Scrum Guide doesn't state that when the Daily Scrum should be done, it only suggests to have it in the same time (and place) every day: "The Daily Scrum is held at the same time and place each day to reduce complexity."

Then, right after this, the 3 questions (I'm quoting the first 2) are mentioned:
"What did I do yesterday that helped the Development Team meet the Sprint Goal?"
"What will I do today to help the Development Team meet the Sprint Goal?"

I have a "problem" with "yesterday" and "today". This indirectly means that the Daily Scrum is in the morning, the first thing in the day. That's not appropriate. I'd like to change it to this:
"What did I do since the last Daily Scrum that helped the Development Team meet the Sprint Goal?"
"What will I do until the next Daily Scrum to help the Development Team meet the Sprint Goal?"

One of my Scrum Master mentors, or some Scrum article from the distant past recommended this 4th Daily Scrum question (that I now always use):

Did I discover any requirements (new or existing) that the Scrum Team should be made aware of?

Sometimes a developer may realize when looking at a particular item in the Sprint Backlog that they could knock off another item in the Product Backlog that is not in the Sprint if they spent an incrementally small amount of additional time. There is a natural tendency to not want to mention it because of perceived (and real) Sprint schedule pressure. I call this 'Toilet Paper tube thinking'.

It is entirely possible that the extra item could be done within the current Sprint with no changes to the Sprint just because it is such a small amount of extra work.

If there were a situation like this, or some new requirement no one had thought of, a quick off-line meeting would ensue. Maybe this new requirement just gets added to the Product Backlog for some future Sprint.

Fixing the timer on the scrumboard so that everybody in the team can see the time one is allowed to speak has different advantages:
- the speaker can move cards free hand
- listeners don't get nervous if they think somebody talks too long, they see and know if somebody has the right to speak
- the speaker also can see the time and can speed up etc

I think the aim of having the daily scrum timeboxed but still all people in the team could tell their status is easier to reach if you use such a timer and holder. I have been using different timers, also some that have some fun factor and collected them here: http://pm.stackexchange.com/questions/13991/gamification-competition-fun-and-jokes-in-the-daily-scrum.

The one I like best for ios can be found here: http://yaazone.com/apps/daily-scrum-time-keeper/. There you can also find some background information about such a talking stick.

Developing software is hard and requires much critical thought and analysis of the problem.

Another massive problem is the outside world expecting predictions about when something will be done and how much it will cost. The 'lets just start and see where we end up' model is so much better. They don't understand such predictions are always lies and are shocked when something goes over budget or takes more time.

But people always want to avoid facing the hard problems. It seems Scrum has become very rigid to force them to face those problems. Even though dogma's don't actually work in real life (look at the problems religion causes).

I would like there to be an alternative less dogmatic version of Scrum where the participants are trusted to use their brain. Developers should be able to change their development processes as needed.

I understand there will always be a need for something to keep the stupid managers at bay, but we don't all need to fit in that little box.

The Sprint Retrospective section says (July 2013):

"Inspect how the last Sprint went with regards to people, relationships, process, and tools"

From a humanistic / servant-leader / Deming perspective, I feel "people" is not a good word to use here, since it can easily be misunderstood or misconstrued. "Relationships" probably already covers the associated issues.

But if we want to discuss people issues explicitly here (rather than out-of-band), then I would hesitantly suggest "behaviours" as a replacement. And I would put it last, not first.

[Aside: When articulating such a Retrospective list, I usually also call out "policies" explicitly. Although, I suppose "process" might cover it.]

We found our retrospectives only skimmed the surface of our our issues where so we did a retrospective that looked at what our principles should be for our Scrum team we discovered some deep niggly interteam problems that infact were easily solved once we identified them. We has a session in three parts: theoretical review of the SCRUM guide (avoiding discussions about how we do it) while at the same time people noted themes and issues on postis, then we grouped our postits into the themes and for each wrote down problems and solutions, then we summarised it in a statement of principles for our whole team. So suggest "Principles Retro" with Agenda: Theory, Theme with issues and solutions and Playbook. We found our theme worked well if mapped to Scrum roles, events and artefacts, hope this helps