I’m not sure The Definitive Agile Reading List lives up to its name, but it is very good. I know I’m going to seek out some of entries that I haven’t read yet.
Month: March 2008
Agile FUD: Frequent deliveries of working code
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.
Mr. Miller offers two criticisms of frequent deliveries.
Continue reading Agile FUD: Frequent deliveries of working code
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: management oversight
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.
The Quality Assurance Mindset
Bruce Schneier has a new commentary at Wired, Inside the Twisted Mind of the Security Professional, in which he notes that “Security requires a particluar mindset”:
Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.
I would argue that the security mindset is a specialization of the QA mindset.
Bruce Schneier comments further:
I’ve often speculated about how much of this is innate, and how much is teachable. In general, I think it’s a particular way of looking at the world, and that it’s far easier to teach someone domain expertise — cryptography or software security or safecracking or document forgery — than it is to teach someone a security mindset.
My wife often calls me a natural-born QA engineer. In general, I take that as a compliment, which isn’t usually the way my wife intends it.
Automated GUI testing in agile
Recently, I’ve had several conversations at work about the cost/benefit analysis of performing automated GUI testing (in our case, using Borland SilkTest, of course) in our agile environment.
In general, automated GUI testing is most useful in the following situations: when the UI of the application under test (AUT) does not change much, and when there is significant regression testing to be done–where the time commitment of creating and maintaining automated tests is lower than the time commitment of repeating manual regression testing.
I’ve been working with an agile team that is in the first few sprints of a new product; this product’s UI is still changing frequently at this point and the product does not yet have much functionality for regression testing.
So, we have a resource allocation dilemma: this team would not benefit particularly from automated functional testing at this time. However, in, say, a year, when this product is more mature, automated UI tests would be very beneficial. But if we wait until then to start automating, we’ll never get caught up, so we need to start devoting steady effort to the automated testing soon.
In an agile environment, it’s difficult to get resource commitments for efforts that only have long-term results.
I’d love to hear whether others have faced this same dilemma and how you dealt with it.
Agile Testing Talk
This is a good talk by Elisabeth Hendrickson from December, 2005 at Google. She has lots of insights into testing in an agile environment and she’s an entertaining speaker.
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.
Agile FUD: Documentation
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.
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: