Agile Drive - What Motivates Agile Teams?

Every since I watched this cool video for Dan Pinks book Drive, I have kept his message front of mind. According to Dan and contrary to what many believe, motivation is composed of 3 simple things: purpose, autonomy and mastery.  Initially I found this hard to believe but the more I look at this the more motivated I become.

So turning to Agile teams, how does this relate?

Purpose
Agile creates a great sense of purpose.  Sprints or iterations create a tangible sort term goal that helps the whole team focus together.  The best teams I have worked with all establish and agree a clear sprint goal, in terms of value to the user and perhaps technical improvement.
Stand-ups frame each day, establishing work completed and work planned - focusing the mind for the day to come.  Blockers are those issues that stand in the way of the team purpose.
User Stories express software in terms of the goals and actions of a user - the purpose the user will be able to achieve when the story is complete.  Moving these to Done moves the user closer to their purpose and connects us to the value of our work.

Autonomy
The key element of autonomy in Agile is the ability for team members to pull new work to themselves. We drop task assignment in favor of this.  The are many reason why but apart from autonomy, I will leave them to another post. When we are free to choose our own work from the board, we have a different relationship to the work. The opportunity to choose goes along way - even if only dud work remains.  Modern societies are founded on the freedom to choose.  Why then would we drop this in the work place? (answer: Frederick Winslow Taylor and another post).  If you are finding motivation to be low, this is a great place to start looking for answers.  Why in our modern, democratic society do we think it's right to tell people what to work on? Rather than ask them to pick from the list of available, prioritized tasks?

Mastery
Agile is built on this.  We focus on developing expert skills in project delivery, then generalize this across the whole delivery life cycle.  Generalizing specialists.  It's key to be able to fulfill a role well before moving on.   In the mad dash that has been the growth of this IT industry, I think this has been forgotten.  There is so much focus on moving into management roles that people forget about mastering a skill.

I think a large part of the growing popularity of Agile is because these three factors are baked into a well functioning team.  The first thing I do now, when asked to help a team, is look at these.  Of course we talk about practices and principle but what I am really looking for is:

Do they have purpose?
Are they mastering their skills (or trying to escape their role)?
Are they free to choose their own work?

After that it's the Agile Principles and finally, if there's any time left, we look at practices.