Here is an excerpt from an interview that Nitin Bharti did with Scott Ambler, Chief Methodologist for Agile at IBM. At one point in this interview, Scott gets to the core of challenge of "selling Agile" to a business. It is much more about communicating than it is about process:
A lot of the business needs are being met by the Agile community far better than the traditional community, but we often don't recognize and don't understand - technical people don't understand how to communicate that to managers.
I think that's a huge frustration for the technical people, but also for the business people, because I run into organizations all the time where the technical people are down in the trenches. They're doing their jobs. They're good at it. They're trying to bring Agile into the organization. The business folks aren't listening to them, and it's because they're not speaking the language of the business.
The business doesn't want to hear about testing and development. They don't want to hear about the neat, new tool you're doing or the new book you've read. They want to hear about what business impact can you have. You've got to be able to talk to the business in business terms, and a lot of technical people don't seem to be good at that.
Lawyers vs. Programmers
This particular quote is interesting because you can swap out the words "Agile" with the words "Open Source", and get the same result. It is often a challenge to introduce new technology and methodology into a corporation because we don't have the kind of professional reputation (as developers) that lawyers have. But, there's an interesting difference. A Legal department rarely "steps-down" to use terms that the rest of the company can understand, a legal document in a corporate case that involves your company will be delivered to you even though you can't understand it. If you ask your lawyer to revise the terms of an End-user License Agreement, they don't do the work on your terms, they tell you what changes need to be made. It is less of a discussion and more a requirement.
A CEO might ask a lawyer to explain exactly what something means in layman's terms, but that same CEO wouldn't question her company's lawyer about litigation tactics. "You know, my son's friend is a lawyer, and he said you can just file a civil suit. You want me to bring him in here tomorrow? He's pretty sharp." How many times, have you worked on a system of enormous complexity that required a massive amount of time, effort, and investment to produce some new technology only to overhear some C-level executive wonder "What took you so long?" Or, "My wife's friend does web design, he said you could do this in PHP for $10k". There's a knee-jerk skepticism that exists for technology that doesn't exist for other professions.
Part of becoming more of a "profession" is to own your own process and to start communicating complexity beyond the boundary of your department. Agile's continued maturity might be part of the solution to this problem. What I hear in Ambler's statement is (paraphrased): "Agile works, now we have to sell to the board room, they are not yet convinced."
These are the trends I'm seeing in Agile:
- Technology departments that have adopted Agile methods may share common ideas about "Agile", but there is little clarity as to what is and is not Agile. Agile practitioners would likely agree on a set of core tenants, but implementation still varies widely.
- Corporations have started to realize that technology departments can and do manage themselves internally with great efficiency, and that letting go of upfront planning and strict command-and-control approaches to software development can yield positive results.
- The Agile movement, more established than it was a few years ago, is now focused on the business case. In the earlier part of this decade, the focus seemed to be on developer evangelism. The movement has arrived, they are now busy converting C-level executives.