My "Ahas" from 10 Years Agile

The Salt Lake Agile Roundtable discussion group (Yahoo Discussion Group) has a little tradition that I've become quite fond of over the years - at the end of the meeting everyone in attendance has to provide at least one "Aha" moment (something during the discussion that stuck with you) from the discussion. Not only does it reinforce important concepts by repetition, once you know that you need to communicate these to others you start to pay more attention to the conversation. Which in turn gives you more "Ahas" and so on.

Once I discovered that I somehow connived myself onto the invitation list for the recently completed "10 Years Agile" conference (#10yrsagile for twitter fans), it was inevitable that there'd be some forthcoming "Aha" moments from the conference that I'd want to be sharing with whoever would listen.

At this point it's probably worth mentioning that my particular style of Agile is the Crystal family of methodologies developed by Dr. Alistair Cockburn. I became a fan of Alistair back in 2002 when we were speaking at the same local conference on software development, and over time that relationship has developed to the point where I consider him both my mentor, and one of my closest friends.

I do have a real point to my blatant name-dropping. Alistair had asked me to publish my "Ahas" somewhere so he could do whatever it is that he wants to do with them. So with that in mind, here are my "Ahas" from 10 Years Agile.

1) Leadership and Vision - There was a lot of discussion around the concept of "leadership" in the Agile community. Makes sense, but it seems to me that discussing leadership without a parallel conversation about vision isn't going to make a lot of sense. If anything perhaps we should focus first on defining what our shared vision is, and then address the issue of leadership. Since it's clear that we've already got leadership in play (see "elephants" below) I am not so sure that more or different leadership is going to make as much a difference as we'd like.

2) Defining and realizing "Value" - One of the most prevalent issues was value - defining it, quantifying it, increasing it, you name it. Value was definitely one of the more pervasive issues in the discussion. The specific "Aha" that occurred to me was that we may be over-simplifying our discussion of value in relation to an Agile organization. The value of Agile means different things when you move between individual <=> team <=>organization. The ways that you measure value for each are going to vary greatly. Job satisfaction as a value measurement means a lot to an individual, but not much to the organization. Return on investment is a key value for the organization, but how important is that to the individual?

3) Practices and Tools outside of development - One of the more interesting frustrations I had during the course of the conference was the seemingly pervasive attitude of "Agile is for software". At one point in the discussion a participant claimed that a team isn't Agile unless they have followed specific software testing practices. Later in the conference there was a heated debate about whether the term "engineering" should show up in one of the outputs of the conference. I am not debating the need for specific practices that will improve work products. What irks me is if we expect Agile to become a tool for the organization as a whole, don't we think that the tools and practices of the CEO, or the Marketing team have the same importance?

4) Elephants in the room - Of course we're talking about the prevalence of the "certification" entities as the most visible public face of Agile to the world. It was clear that there wasn't a lot of love in the room for the value of certifications as they exist today in the Agile world. What didn't seem to be so clear to others (or maybe I just didn't have the right conversations) was the fact that there isn't much we can do about them other than work with them or put out a better product. Take an organization like the Scrum Alliance. Are they going to change their business practices based on outcry from the rest of the Agile community? Not a chance. By the best definition of success we have in a capitalist system, they are successful because they are making money. If we don't like what they are doing, there's a proven formula for dealing with this. Compete with them and force them to change by way of a superior offering.

5) From Certification to Evaluation - The real problem that I see with #4 above is the fact that the business community is accepting certifications as if they somehow predict job performance or improve the chances of successful adoption. Unless you can show me what your failure rate is for people attempting to certify as whatever title you're giving, I'm not the least bit interested in that certification. What amazes me is that the certification bodies themselves aren't more concerned about this. Without critical evaluation of the knowledge and skills that are being trained how does the certification organization know how effective its educational effort is?

6) Does Agile really make a difference? - Not so much a question that showed up at the conference, but one that kept running around in my head, kicking over garbage cans and spray-painting the cat. As mentioned in #4 above, a capitalistic society provides some very clear measures of success, and is as Darwinian an environment as you can get for principles and practices that affect the bottom line. It's clear we've made excellent progress over the past 10 years, but it's still not so clear to me why businesses aren't beating down the door to really adopt Agile throughout the enterprise and not just be buzzword compliant. If we expect Agile to move from the dev team out to the larger organization we're going to have to be much clearer about defining and proving the real value of Agile as a better means of doing business.