Agile self-righteousness

I posted a question to an agile testing group and one of the replies implied that if we were doing agile correctly, I wouldn’t face the problem that I asked about.
The mildly holier-than-thou tone of the reply really sounded familiar to me–I realized that I often have the same attitude. But now I see that such self-righteousness doesn’t do anyone any good. If someone hasn’t already gotten the message through preaching, more of it really isn’t going to help. I will monitor my own responses better in the future.

Agile FUD: Frequent refactoring

This post is part of a series in which I address Bill Miller’s criticisms of agile. Please read the original post for context. In this post I take on his criticism of the role of documentation in the agile process.
Bill Miller says of refactoring:

The mantra in the Agile community is constantly refactor. This is a highly expensive approach, and in this age of globalization where costs drive decisions, it should be looked at with trepidation. This isn’t a wise approach, as market pressures to deliver quickly always constrain your latitude for refactoring.

Let’s look at one of the agile projects that I’m currently involved with.

Continue reading Agile FUD: Frequent refactoring

Agile FUD: Armchair quarterback

I recently ran across Bill Miller’s blog You Want IT When?. Bill has a lot of experience in managing software development, but in my opinion, he is way off the mark in his opinions on agile. Unfortunately, he makes a lot of claims that I’ve heard repeatedly from people who haven’t actually experienced agile or haven’t really understood its philosophical underpinnings.
Bill starts off by admitting that he’s only read about agile–which he clearly doesn’t see as a problem:

After reading many articles published by Agile proponents, I remain steadfast in my beliefs that something is wrong, and rather than advancing the state of the art practices in Software Development, Agile proponents are setting us back, and in this world where jobs easily cross international boarders, especially easy in software, we need practices that demonstrate the value proposition for keeping teams here in the US: practices that deliver reliably and predictibly [sic] on commitments and practices that can demonstrate improvements in productivity and quality.

In the next few posts, I’d like to address Bill’s criticms one by one.
UPDATE: Here are the follow-up entries that I’ve completed:

Is agile adoption leveling off?

There has been a big discussion the last few days in the Agile Testing Yahoo! group about this article from The Industry Standard: Agile progress report shows adoption has hit a wall.
I don’t buy the premise that agile adoption has peaked, but the article mentions some of the challenges that some organizations face when considering agile:

Some organizations, however, cannot adopt agile methods, Ambler said. “It’s simply because of their own organizational culture.” He said. “They have systemic challenges,” said Ambler.

“It’s a good way to do small projects, at least from my perspective,” said Rich Peters, senior software engineering manager at Braxton Technologies. “In our environment, we can’t use that technology because we have government requirements about how we do our development. But for internal projects, it would be fine.”

Ambler cited issues with agile. “One of the biggest problems right now in the agile community is we’ve gotten really good at developing siloed systems. That’s not useful,” he said.
Some challenges to agile development include entrenched processes, enterprise discipline, compliance requirements, team size, and application complexity.

I particularly loved this line:

Ambler also said research found a disparity in what developers and managers thought was happening with agile; 61 percent of developers thought they were doing agile development while 78 percent of management thought agile development was in use.

My adventures in agile software development

I started work at Borland in April, 2006. Around that time, the company had decided to convert the entire R&D organization to the agile/scrum methodology, and since I was working in a brand new division, it was a natural place to start.
Of course, Borland wanted the predictability, productivity and quality increases that come with agile, but Borland had an additional reason for adopting the agile process: Borland’s business is selling products and services for managing the software application lifecycle. Adopting agile was a case of eating our own dog food. We were charged with developing agile processes that served our own and our customers’ needs.
So far, the company considers the agile implementation a great success, and it has started converting other divisions to agile. Stay tuned to this space for more details on the lessons we’ve learned from our agile implementation.