Sorry, I prefer to spend my time worrying about the code rather than worry about the rules for interacting as a team. Those rules need to be edgy enough to make things run smoothly and quickly, but not make people wonder if those rules are a bad idea or not.
The kind of Agile he describes is perfect for a startup. It gets things rolling without too much worry about failure... It keeps things from being too enterprise-y.
But an established company needs to be more concerned about their clients and their clients' data. Things need to be as stable as possible.
All right, I'll finally comment on Agile (personal perspective, not newsworthy of itself).
A few years ago, one of the "big name" proponents of Agile and whatnot came to the area, and I let a few people know and we went to listen. [1]
It was nothing more than a buzzword laden rehash: Part common sense, part a rephrasing of the same old corporate mumbo jumbo we'd all long since learned to ignore where we can, and tolerate where we must.
On top of it, he was an arrogant prick -- at least, that day. The people I was with were generally quite intelligent and rather conscientious. Some tried to ask questions, especially to get past the buzzwords to the gist of the topic. His responses basically ran along the lines: "You're doing it wrong." This as a preface -- as an assumption, not even acknowledging the details the person described. Then, more 'blah blah buzzwords' lead to "blah blah metrics'.
It felt like a verbalized extension of PowerPoint (IIRC, he had PowerPoint along for the ride, too).
After that, I stopped paying much attention to articles on "agile". There's some good value in some of the details, but trust your common sense, and that you've probably already figured out most of the basics for yourself.
Also, I'll add that different people have different working styles. Exhibit some trust that they have figured out, at least to some extent, what works for them. Then stop trying to pound them into that proverbial "round hole".
Yes, people have to communicate effectively. But this does not equate with e.g. shoving them all into a "bullpen". Or making them think all day with someone staring over their shoulder, or vise versa.
As for e.g. continuous builds/integration and all the other technical aspects. Some good portion of that is an outgrown of continued developments in various systems. I suppose "agile" publicizes these, but you should be aware of and considering them, regardless.
[1] I guess I should add that he worked for IBM, IIRC. So, of course, they were there to promote "agile" in a manner that would sell IBM products and services.
My experience may therefore relate more to how agile translates to the world of larger corporations. By the time its transmogrified by all those filters, it sounds a lot like more of the "same old same old".
The kind of Agile he describes is perfect for a startup. It gets things rolling without too much worry about failure... It keeps things from being too enterprise-y.
But an established company needs to be more concerned about their clients and their clients' data. Things need to be as stable as possible.