Remember junior high school history class, when we heard that Luther's protest conveniently occurred just when secular princes were looking for ways to gain independence from Rome? The Agile movement arrived when more was happening in the technology industry than just the disgust of developers with schedules in which no one believed, or projects that didn't deliver what the customer wanted.

Tom's blog post, and it got me thinking: if Luther had started the Reformation and agile, the Reformation might have looked quite different. Instead of nailing 95 theses to the door in Wittenberg, in his first iteration, Luther might have only demanded a handful of changes to the Catholic church.

0- The Agile Convert attempts to understand and learn all the Practices.

1- The Agile Purist follows all the Practices (this is the evangelical recent agile convert).

2- The Agile Pragmatist starts to realize that not all practices work in all situations and pursues the Agile Principles molding the Practices to their specific environment.

3- The Agile Purist follows all the Principles.

4- The Agile Pragmatist starts to realize that not all Principles work in all situations and pursues the Agile Values molding the Practices and Principles to their specific environment.

5- The Agile Purist follows all the Values.

6- The Agile Pragmatist starts to realize that not all values work in all situations and pursues the ??? molding the practices to their specific environment.

7- The self-actualized agile follower realizes that Agile is the embodiment of some higher understanding that can be applied in part or whole to any environment to help deliver more value… forget the boundaries of values, principles, or practices… these are just simple mechanisms to enable the education of agile to others.

On this scale, I would rate myself about a 4, with quite a bit of 7 thinking thrown in.

Where do you stand on this scale?

You can never test everything with the same (extensive) depth; even in a waterfall project you have to make choices. In an agile project all the activities are time boxed so you have to make choices about how extensively you want to test each feature. We use a risk based approach to determine which test activities we are going to carry out for a feature during the iteration. The risk level of every feature is determined by the customer and the teams. It is a very transparent process so the customer knows exactly which test activities are executed for every feature

I've heard a lot about risk-based testing in the last couple of years. I don't mean to sound like a know-it-all, but I've been employing risk-based testing for years (which goes along with risk management mentioned in yesterday's post), only I didn't know it had a specific name. What do others think of this?

Most testers I meet simply have not been exposed to the virtually impossible business challenges regularly facing development projects that often lead to decisions that appear completely counter to a commitment to quality when taken out of context. The fact is that there are a huge number of factors influencing a software development project that, at any particular point in the project, may rightly take precedence over an individual tester's assessment of quality. Given their lack of exposure, it's no wonder testers seem to habitually take a "my team doesn't listen to me" point of view.

When I conduct job interviews with QA engineers, I often test the candidate's awareness of these factors by asking this question: "Can you name a time when you just had to put your foot down with regard to quality? For example, declared that the software can't ship due to quality concerns, etc.?"

It's a little bit of a trick question. The answer that I hope to hear is: No; it's not my job to make those decisions; it's my job to provide risk assessment data to decision makers who do have to make these tough decisions. Secondarily, if I'm doing my job correctly throughout the dev cycle, there should not be any surprises of this type. If a situation is building that might result in such a confrontation, then I haven't done my job in monitoring the situation, trying to solve it, or at the very least keeping management in the loop on the building crisis, so that they can make appropriate contingency plans. There's nothing management likes less than getting into a crisis situation with no warning.

In his post, Dean throws out a lot of possible reasons for this problem, but the end of the post gets to the heart of the matter for him:

Off the top of my head I cannot recall a single university in this country that talks about a career in testing as an equally viable career choice in the same vein as development. Even though in the workplace, I'd argue that testers have an equally as important role as developers. This discrepancy contributes to our lack of growth in mature and capable candidates, leading us to see the same poor candidates going from shop to shop and always somehow getting through the front door.

It is as though testing has become the place for people who fail at being a dev, a system analyst or business analyst or if you can pull a visa and need something where the demand is so great that the quality of the screening is frequently wavered to get "warm bodies" through the door.

Maybe the situation is different in Australia than in Austin, but I'm not sure I see the same dearth of qualified candidates. And as for Dean's concern about testing not being seen as "an equally viable career choice . . .as development", as far as I can tell, that's always been the case. If anything, this situation might be better than it used to be as the software industry has matured.

I'd love to hear others' thoughts and experiences.

One thing strikes me right away about this article: it makes no mention of the agile manifesto or the agile manifesto's principles. Perhaps the author assumes that the reader already understands these basics, but I don't really see how an organization can adopt agile without starting with the manifesto and principles. As I have mentioned before, you can follow all the steps in this guide but still not be agile unless the entire organization understands and buys into the values and principles of the manifesto.

Update: Amr Elssamadisy, the author of the article, replies in the comments.

The most interesting conversation was with an agile coach from Sweden. If I understood him correctly, he believes that scrum has reached the point of being just another buzzword, and that many organizations are pursuing it just for buzzword-compliance, not understanding the fundamentals and value of scrum. I'm sure there's a certain amount of that, but I don't think it's widespread enough to warrant his sharp opinion.

He did raise interesting one point, though: fork out a couple thousand dollars, attend two days of training, and you, too, can call yourself a certified scrum master. He believes that scrum masters should have much more training than that. He said that the agile coaches he's working with have developed a year-long process for learning how to facilitate agile.

This guy's thoughts on what it takes to be a qualified scrum master meshes with a conversation I had yesterday with some of my Borland coworkers. One of them was suggesting that scrum masters could benefit from facilitator training since facilitation is an established discipline that's very similar to the role of scrum master. I would love to get some facilitation training.

...the reason I enjoy Agile development is because it made my job more fun. Today, thanks to Agile development, I interact with customers more than ever before. As a product owner, I do more demos and am able to provide new features that hit closer to the mark faster and more frequently than ever before. This in turn means more oohs and ahs from customers which is more fun for me and more profitable for the business.

As I mentioned in an earlier post, I'll be working the Borland booth at the Agile 2008 conference in Toronto next week. We will be showing the integration between SilkCentral Test Manager and a popular open source testing tool. (The marketing people won't let me say be more specific here; come by the booth at the conference to find out more!) The guy who's preparing the booth demos and materials for the integration just sent me the following email:

I’ve been working . . . on our Agile Test Strategy for SCTM [SilkCentral Test Manager] and how it relates to our other solutions. I’m putting together the PowerPoint for the 'demo loop' in the booth based on the information I was able to gather over the last couple of days.

Also, I have a VMWare image of the integration . . . I plan to have screen shots of the demo . . . but have the VMWare image available for those who’d like more info on the integration.

The integration that we will show at the conference was developed very recently but will be released later. Due to our internal use of agile, we have this functionality working now, and we will be able to demo it. Without agile, I would have been stuck in the booth with the slide deck and other published materials only.

In a recent column over at StickyMinds.com, titled Does Exploratory Testing Have A Place On Agile Teams?, Johanna Rothman writes the following:

Agile projects require true generalists as testers: people who have requirements-, design-, and code-understanding skills. Without those skills, they can't think critically enough about the product under development, and they might not be able to create enough variety of tests. If they understand the requirements, design, and code, they can turn that understanding into crafty tests. Some of those tests will be exploratory. Even some of the exploratory tests will need to be automated in order to repeat them. And, I've seen great testers on agile projects who can quickly create automated tests to do some of their exploration.

I read that as a confirmation of my thinking. Coders can indeed do testing, but it takes someone on the team who has the big picture in mind in order to do good exploratory testing. QA generalists are needed to do this work.