A wise man once told me that most developers dont care about the why, they only care about the how. That is especially true around process and agile development. Developers want to know "how" to do scrum, but rarely want to know "why" they do it. The issue with this mindset is that scrum and agile in general are highly adaptable. Scrum is full of independent concepts that can be adapted to your individual circumstances in order to achieve a highly efficient and productive team. However, when you don't understand why you are doing them, you tend to adapt out the good stuff and miss the whole point of what you are trying to accomplish with Scrum.
Probably the most misunderstood and abused concept in Scrum is the daily stand-up. I have seen many instances where developers go through the motions of the stand-up, they even ask and answer all the right questions, but they are doing it for all the wrong reasons. Ultimately, the purpose of the stand-up is for the team to know what the team is doing. The purpose is not for the scrum master, project manager, or team lead to know what the team is doing. When you pull a team together for a daily stand-up, that is their opportunity to listen to what is going on, understand where the pieces they are waiting on are at, know what struggles their teammates are going through, and be able to voice what your own struggles are in an attempt to get assistance or understanding from the team.
At its core, the stand-up is about forming a group of people that are all in this together. In other words, a team... If you are checking your email while your peer is giving a status report to the team lead, you are not part of a team. You are an individual who may or may not contribute to the overall success of the group. If you are "tweeting" instead of listening to the struggles of your peers, you may be doomed to repeat their pitfalls.
So, tomorrow in your stand-up, put your phone down and make eye contact with every person that gives their update. Ask yourself, "How does that impact me?" or "Have I struggled with that before?" Have your first response be, how can I help these people out to contribute to the overall success of the group. That ultimately is what a team does.
Probably the most important principle in all of agile development reads like this...
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
I like to sum this up in one succinct statement, software that is sitting in QA is not providing value to anyone.
The most important thing an agile practitioner can do is identify valuble pieces of software and get them to production as fast as posible.
Notice that this principle does not specify a timebox, or iteration length or any other such thing. The key is in the term continuously. As soon as you have something that could be providing value, get it out the door.