| QUESTION & ANSWER |
Agile and waterfall neck and neck as business side fails to engage |
 |
By Jan Stafford, Executive Editor
16 Mar 2009 | SearchSoftwareQuality.com |
|
|
Lazy business execs and analysts are key barriers to wider adoption of agile development, according to Jon Kern, co-author of the Agile Manifesto and
a keynote speaker at the Server Side Java Symposium in Las Vegas this week. Beyond the issue of agile adoption, his pet peeve is business leaders' failure to count software as a capital asset and get involved in its quality.
"There are plenty of old-school, waterfall-based development practices in place in which the business side just says, 'Do it. I sent you the business requirement. I don't have time to talk about it. Just do it,'" Kern said in a recent SearchSoftwareQuality.com interview.
In this excerpt from the interview, Kern discusses the disconnect between business and development leaders, why agile requires top-notch developers and why piecemeal adoption of agile fails, as well as offering advice on requirements and testing and QA practices. Kern's advice and observations come from his field work helping companies with development and agile as software architect and agile manifestor for Immuexa. At the Java Symposium, Kern's keynote topic is the keys to agile software development. Our recent survey showed an even split between waterfall and agile users. Do you see that split in the development community?
Kern: This meshes with my experience and travels to hundreds of companies. There's no clear-cut winner right now. Which method is used depends upon who's in the company. The move to agile often starts with developer, and then there's the rare company where it starts higher up.
Another barrier to agile adoption is that a lot of companies still find it difficult to get business people to participate at a level that's optimal. It's hard to break the mold or the habits that have grown in these types of companies.
How does the divide between the software development and the business sides impact product quality?
Kern: My pet peeve is the lack of our ability to tie development effort to business, to tie quality to profit/loss, to treat software as an asset -- or not. It's easy from a high-level point of view to only look at the application, the amount of money it's made since deployment.
Companies are used to hardware-oriented IT where you get a bigger server and you can quantify it with some kind of metric. It's more difficult to quantify new features, to quantify that this change in the software cost this much to create and then made us this much after deployment.
Ideally, what I consider development is that the users ask for the features and just tell them how much it's going to cost. Then, they need to understand the business impact of getting those features. For us it's no skin off our backs to make feature X or feature Y. What's iffy is if the business leaders are smart enough to make the business call once we explain that feature X costs 10 bucks and makes you $100 and feature Y costs $100 and only makes you $10.
In your writing and presentations, you've said that agile requires highly skilled teams. Why is that?
Kern:
|
|
|
|
|
There is a false lust for features at the expense of quality and tests.
Jon Kern
Co-author, The Agile Manifesto
|
|
|
|
|
|
|
|
|
|
In practice, agile requires a higher-skill set, even though ideally it shouldn't. It should do the opposite. If it's set up right, you'd have the proper checks and balances, and even the dumbest person could contribute; but I find that agile in practice is more difficult to handle, because not everyone understands the constellation of practices and techniques you use in agile. If you do it all -- do every step of the agile process -- it works well and is balanced. If you cherry-pick and only do things that makes sense to you and your business execs, the value drops off rapidly. You've got to have smarter people to do agile, people who can take the broader view.
Yet, project managers and consultants tell me that skilled people and, thusly, higher-paid people are getting laid off first.
Kern: I feel that the savvy business folks understand that a skilled handful of IT far outweigh the masses of unskilled labor. But there are plenty of companies that do not treat software like it is a capital asset.
It's hard to imagine that something the company relies on for paying salaries and so many other critical processes isn't considered a capital asset. Could you image a car manufacturer not caring about what goes into building the car?
It's hard for lay people to understand what software is and why they should treat it as a tangible item. It's a poor job of trying to link business values to the efforts around building software.
You've suggested that gathering too many requirements might be counterproductive. Others have told me that many projects don't gather enough requirements. Could you explain some key points of your approach?
Kern: The key is to understand which requirements are critical to shaping the architecture and can greatly affect the project, and which ones are "cheap" and do not matter that much. The former are often short-changed in projects because either the team is naive, or because these are "harder" to get right. The latter are often littered all over the place because they are easy to come up with and people think it is "progress" to have "more."
The concept of working on quality and testing from the get-go in projects seems logical, yet I still hear about QA and testing being done at the end of the process. Do you see the former approach being adopted more? Why might there be resistance?
Kern: TDD (test-driven development) and quality at every step is still a big challenge. Mostly, I think, due to inertia that teams haven't done it that way very much. There is a false lust for features at the expense of quality and tests. I could go on.
Some people like and some don't like or understand the value of test-driven development. I'm constantly struggling to get the team I'm working with now to write more tests. Rather than write a test when a bug is found, they'd rather jump in after the fact and fix the bug. We found a bug. We wrote a test. Now we know with some level of confidence that that bug won't ever appear without a test in front of it. Let's save money now and not worry about the future. It's a funny scheme of things.
|
|
|
|
