Three ideas came together a few weeks ago that provide the topic for this posting.
First while browsing the agile virtual community I encountered a reference to a youTube video with the headline "Learn the Agile software development methodology in less than 10 minutes. "
Second I was reading the abstracts of talks by some thought leaders that offer to clear up the multiple misconceptions about Agile.
Third, I was thinking deeply about adoption of Agile in my current situation.
I was initially impressed by the 10 minute video, it gives a nice concise definition of some common vocabulary and roles used in an Agile project. Yet, I fear it also contributes to the misunderstanding that experienced agile practitioners talk to others about. It may also lead executives with P/L responsibility to look at Agile methods with less respect and confidence.
I believe that there are also others who started their "agile journey" more recently or at a different place who tend to view Agile methods as light weight or more suited for the free spirited. They may be attracted to Agile methods as the least invasive of a variety of alternatives.
The more seasoned players my look at all of this with some degree of skepticism. They think how can something that simple support the claims being made.
In light of all this I have to offer my brief point of view. The process description is simple. Yet the organizational climate in which that process can thrive is no simple matter to achieve. Getting people to be accountable is hard. Getting out of the "it's not my job" mentality can be a challenge way beyond what one can learn in 10 minutes. How to create the foundational alignment and climate is what I'm learning and hope to continue to learn.
To do this I view presentations on motivation by people such as Dan Pink http://www.ted.com/talks/dan_pink_on_motivation.html and I listen deeply to team members who challenge me with statements like "why isn't it enough that I come to work every day and do good work".
The "agile manifesto" or the "declaration of interdependence" http://pmdoi.org/
are value statements not process prescriptions. The blood, sweat, and tears to create that type of alignment is how you pay your dues to achieve the benefits that proponents of agile methods offer. (faster, fewer defects) And in some cases your organization may not be able to fully implement an agile development methodology. It is not the "best practice" every one should adopt. In the end we must do what is necessary to create value for our organization in the current time and setting.
If nothing else agile methods should cause one to reconsider the value that any current practice or communication process brings to an organization and consider very carefully how "change" impacts the success of failure of your project.
Agile is not simple, and certainly not a quick fix. Rather it is a challenge and a cause to rethink and evolve our current current management and project management science.