As I donned my running shoes, switched on the mp3 player and tuned in to Owen Rogers talking about Adopting Agile, I have to admit I was expecting to be disappointed. Which is not always a bad thing - I love listening to podcasts that I disagree with - especially when running - it gives me extra energy. 
In fact, listening to some dance music classics also does wonders but can have embarrassing side effects - recently I was running in what I thought was a remote forest track, stopped for a breather and broke out some rarely seen dance moves only to look up a see a small group of hunters silently staring at me through the trees. Nice. But anyway, I digress...
The reason I wasn't disappointed was that Owen said some really sensible stuff. It's one of those topics that people can get a bit religious about - and often at the expense of promoting healthy discussions and sharing ideas. Two things in particular stuck in my mind.
It's Not Helpful Talking About "Being Agile"
Not sure if Owen used the term "Being Agile" - but it's my interpretation of a common perception that becoming Agile is actually a measurable achievement. That you can follow a checklist of practices and methodologies and claim the badge. The word itself has so many different interpretations that I've actually stopped using it in front of my clients. As Owen discusses the Agile Manifesto is the result of seventeen geeks getting together and articulating the principles they believed contributed to successful software projects. While there are more concrete practices and methodologies like Scrum and Extreme Programming it's unlikely that you will find one approach that is appropriate for all types of projects.
Owen's approach when talking to teams is to look at the immediate problems they are facing and determine whether any of the development practices or processes that are associated with the agile movement can be used to improve the situation. Every team is different, they all work under different constraints and pressures, some agile practices simply won't work and others will be a revelation. It's all about applying those practices that make sense to a particular team.
At the end of the day it's all about "Being More Agile"
If There's Only One Thing You Do...
When asked what single thing a team could do to become more agile Owen alluded to the first Agile Manifesto principle.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
The idea being that if you achieve this you will be motivated to implement other good practices - well defined and small iterations, customer involvement, continuous integration, requirement prioritisation...
This practice is most easily understood and implemented when developing a product. It's easy to see the value of, say, Google, regularly implementing new Gmail functions every few weeks.
However, I've always found this principle to be good on paper but often hard to put in to practice within a service based company. The value of many business applications is only ever realised when they are finished. For example, I was recently involved in an Internet site that allowed customers to apply for funding online. It was a complicated series of application forms that only made sense in their entirety. It simply wasn't possible to deploy the application in stages.
Of course, the answer is sometimes to apply this principle to UAT deployments. While you're not actually adding any business value you are providing your client with a regular opportunity to review progress and provide feedback.
Anyway - thanks Owen for making my run more enjoyable.