We've seen a number of misconceptions about Agile come and go. For example, the urban myth that Agile is all about velocity gets far less circulation. More people have seen Agile in practice, witnessing first hand the other potential benefits (more chances for mid-course corrections, greater predictability of outcomes, better business/IT alignment, etc.) than just writing code faster. More people are starting projects with these potential benefits in mind, so Agile has clearly moved past the perception that it was some perverse cult of speed. Speed has no intrinsic business value, aside from keeping a twitchy software developer who has consumed way too much Mountain Dew from chewing his own foot off in frustration about delays and obstacles.

 
Agile Gets To Specifics Quickly
Business value is the goal for Agile transformation; benefits like quality, predictability, and business/IT alignment are either measures of that value or steps needed to achieve that value. Both topics require a lot of clarity or specificity. Otherwise, Agile can look a lot like a road trip gone horribly wrong: we're not sure where we're going, how close we are, or whether we're going the right way at all.
 
Agile succeeded brilliantly because it started with some very specific practices and values. Don't end a sprint without working code. Keep your backlog prioritized. Build the expectation of new or changing requirements into planning. Don't build your plans on information you don't have. That's a lot more-specific guidance than something like"Achieve this maturity level and you'll be fine" or "Follow this KPI to the ends of the earth."
 
Now that Agile transformation has moved beyond the individual team, we need to be clear and specific when phrasing and answering some new questions. Some refer to upstream concerns, such as "How often should we ask business users for feedback?" Others point downstream from the team, such as "How important is it for our testing environment to look like a real production environment?" Others span the entire software value stream, such as "Do our outsourcing partners really understand value?"
 
Specific questions demand specific answers, which in turn spawn more specific questions. Once you've decided on the importance of a production-like development, testing, and build environment, the next logical questions are: "How do we implement these? And how fast can we spin up instances of them?"
 
Looking For Specifics At Agile 2012
Which brings me to Agile 2012, which is happening this week. This conference always excelled when it provided specific answers to specific questions. I've attended some excellent presentations on topics like incorporating UX professionals into Agile processes, applying Agile practices to embedded software development, and handling tough security and compliance requirements within a methodology that on the surface seems not only indifferent but allergic to these concerns. The more specific the presenter was in addressing these questions, the better the session.
 
Recently, when attending this yearly Agile conference, I've felt that the sessions have become a little fuzzier on these details. To be fair, the sessions pitched at beginners can't cram too many details into the brains of newbies all at once without generating confusion or catatonia. However, since many of the intermediate and advanced sessions this year are only 30 minutes long, it remains to be seen exactly how far down into the proverbial weeds they can get. On the other hand, most of today's sessions were 3-plus-hour-long mini-workshops, a format which almost requires a significant level of detail (or just amazing showmanship). I'm looking for more of a happy medium between these two extremes, as I suspect is true of many others here in Dallas this week.
 
[And if you're attending Agile 2012, and you spot me across a crowded room, don't hesitate to say hello.]