Not everyone agrees with my definition of Agile.

Dave Nicolette commented that he thinks my definition actually describes Lean. He defines Agile in terms of the Agile Manifesto.

I replied to Dave elsewhere, but wanted to post my response here too since this is a topic that comes up frequently.

I have trouble defining Agile solely in terms of the Agile Manifesto.

Mind you, I believe the Agile Manifesto is a great document. With it, the original signatories gave the industry a focal point, a fulcrum on which to turn. They forever changed our industry by distilling the difference, in terms of their guiding values and principles, between the lightweight approaches they used and the then-generally accepted formal processes & industry “Best Practices.”

And turn we have. “Agile,” at least as a buzzword, is mainstream. Increasingly organizations are adopting Agile methods to remain competitive.

However, I see the manifesto as a beginning, not a definitive end. The community has learned much in intervening years.

Part of what I’ve personally learned is that defining Agile in terms of results short circuits two of the bigger problems I see plaguing the community: 1) religious debates and 2) superficial but ultimately hollow attempts at transitions that result in frAgile processes.

Where people define Agile in terms of practices, I see more instances of Cargo Cult adoption (”We’re Agile because we stand up every morning!”) and religious dogmatism (”You don’t TDD?!? You can’t possibly be Agile!”).

Where people define Agile in terms of values, I see more instances of Agile-as-an-excuse (”Documentation? No. We don’t document anything. We’re Agile!”).

But where people define Agile in terms of results, I see greater focus on the ultimate goal: value to the business.

As it happens, the best way we’ve found to achieve that goal so far—or at least the best way I’ve seen so far—involves embracing the values and principles of the manifesto.

But I believe that remembering why those values and principles are important, remembering the result we’re trying to achieve, is essential. And so I define Agile in terms of results.

A few days ago, I tweeted that I was looking for nominations for events for an Agile timeline and am extremely grateful for all the responses I received.

The request was for the keynote talk that I just presented at PNSQC. I’ve had several requests for the timeline that resulted, so I figure the easiest (and therefore fastest) way to share the resulting timeline would be to share my slides.

Here they are (pdf, ~1Mb). Enjoy! (As always, comments/questions/critiques welcome.)

I’ve been hinting about a new venture on Twitter, and it’s time to explain what’s going on.

I’m in the process of opening a new office. Or rather, my company, Quality Tree Software, Inc. is opening a new space in our current building in Pleasanton, CA.

It’s 1200 square feet of open-layout-Agile-goodness. When it’s done, it will be outfitted in the spirit of the best Agile organizations I’ve seen. It will be one big wide open workspace with lots of natural light. We’ll fill it with modular furniture that will be able to accommodate a variety of uses.

The space is still under construction. So you’ll have to use your imagination to envision the finished space. But trust me. It will be cool. It will look like a well-appointed team room. There will be big whiteboards. There will be a big visible CI monitor. There will be a library. There will be a story wall. There will be big visible charts. There will be desks suitable for pairing. There will be comfy chairs. There will be index cards.

My intent is to create a training space that offers participants an immersive Agile experience. Just as I’ve recommended that people visit Pivotal Labs in San Francisco or Atomic Object in Grand Rapids or Menlo Innovations in Ann Arbor, I hope that others will be inspired to recommend that their friends and colleagues visit our new space to see what an Agile space feels like.

And because having this space means we have our very own dedicated venue, we’ll be able to offer beta-level, not-quite-ready-for-primetime classes at significantly reduced rates. And we’ll be able to experiment freely.

I’m already talking with other training providers about classes they might want to do in the space. Our intent is to host offerings from all sorts of folks. It’s kinda like having a performance venue showcasing awesome trainers and facilitators who are aligned with our values.

In that spirit, the vision is to create far more than “just” a great training space. I also hope that the space can become a kind of community hub. I want it to become the kind of place that people look forward to visiting just, well, because. Because it feels good to be there. Because it reminds them of what a living breathing team space feels like. So we plan to host community events like OSTATLI in the space. And I hope that the space will foster a community of practice for Agile trainers where we can share experiences and material, and collaborate to create better classes.

There’s still a lot more work to be done before we’re ready for visitors. We’re currently targeting an October opening. But construction delays could push that date back. I’ll post updates here, and pictures, as things progress.

In the meantime, I hope you’ll consider visiting us when the space is finished!

I think it’s important to define “Agile” when I talk about “Agile Testing.”

Agile is one of those capitalized umbrella terms, like Quality, that means many things to many people. And given that Agile Testing involves testing in an Agile context, it’s hard to talk about it if we have not established a shared understanding of the term “Agile.”

I define Agile in terms of results. Specifically, Agile teams:

(Tip ‘o the hat due to various sources that inspired my definition, including the APLN’s Declaration of Interdependence for the phrase “continuous flow of value”, Scrum for the phrase “potentially shippable product increment”, XP for the core practice of “Sustainable Pace”, and Jim Highsmith plus too many other people/sources to mention for the idea of adapting to changing needs.)

Teams that are consistently able to achieve those results typically exhibit the following characteristics:

• A high degree of Communication and Collaboration.
• Seeking and receiving fast Feedback.
• Seeking mechanisms to support Visibility so everyone knows what’s going on at any given time.
• A high degree of Alignment so everyone is working toward the same goals.
• A shared Definition of Done that includes Implemented, Tested, and Explored before being Accepted by the Product Owner.
• A relentless Focus on Value.

And teams that manifest these characteristics typically have adopted a combination of Agile management and engineering practices including:

• Prioritized Backlog
• Short Iterations (or Sprints)
• Daily Stand-ups (or Scrums)
• Integrated/Cross-Functional Team
• Continuous Integration
• Collective Code Ownership
• Extensive Automated Tests
• etc.

Too many people equate practices (e.g. Prioritized Backlog) and methods (e.g. Scrum) with Agile. But that’s backwards. Agile practices and methods increase the odds of achieving Agility, but they’re not a guarantee. The practices serve the desired outcome, not the other way around.

A colleague recently described the requirements process in his (non-Agile) organization to me. In their process, the business people talk to the business analysts who talk to the systems analysts who give requirements to the programmers.

As he was explaining all this, I couldn’t help but reflect on all the possible points of failure.

I’ve seen conversations around requirements go horribly astray with just two people: a business person specifying what they want, and a developer who is supposed to implement it. How much more likely must misunderstandings be when requirements are coming from people who are multiple levels of indirection removed from the originators of the requirements?

The first thing that came to my mind is the Telephone Game. In case you’ve never played it, in the Telephone Game, one person thinks up a story, then whispers it to the next person. That next person whispers it down the line to the next person. And so on. Eventually when the story reaches the end of the line, the last person tells the story as they heard it to the whole group, usually with much laughter as the group hears how the story evolved through many successive tellings.

But then it occurred to me that this is less like the Telephone Game and more like a succession of translations. The business person tells a story in BizSpeak to the Business Analyst who interprets it and retells it in BA-Speak (perhaps in terms of “Must,” “Should,” and “May” functional requirements) to the Systems Analyst who retells it in SysSpeak (perhaps UML Use Cases and/or Sequence Diagrams) to the Programmer who must translate it into TechSpeak (maybe State Models, Class Diagrams, and ERDs) and then code. The languages may have some commonalities, but they have a lot of differences too.

And that made me wonder what would happen if I played the game with the Google translator.

So I picked an innocuous sentence out of one of my blog posts, and translated it from English to German, then to French, then to Italian, then to Spanish, and then back to English. Here’s the result.

English: Agile means delivering business value frequently and consistently while adapting to changing business needs.

to German: Agile Business Wert bedeutet, liefern häufig und konsequent, während die Anpassung an sich wandelnde Bedürfnisse.

to French: Agile Business valeur signifie, et fournissent souvent de cohérence, tandis que l’adaptation à l’évolution des besoins.

to Italian: Agile Business valore significa, e spesso prevedono la coerenza, mentre l’adeguamento alle mutevoli esigenze.

to Spanish: Agilidad de negocios de valor medio y, a menudo, la coherencia, mientras que la adaptación a las necesidades cambiantes.

back to English: Agility and business value, often, the coherence, while adapting to changing needs.

Hmmm. Something got lost in translation.

Now, I wondered, what would happen if I chose more radically different languages?

English: Agile means delivering business value frequently and consistently while adapting to changing business needs.

to Indonesian: Tangkas berarti memberikan nilai bisnis yang sering dan konsisten sementara beradaptasi dengan perubahan kebutuhan bisnis.

to Hungarian: Fleet átlagos üzleti és következetes, alkalmazkodva a változó üzleti igényekhez.

to Dutch: Gemiddelde vloot en samenhangende activiteiten, aanpassing aan de veranderende zakelijke behoeften.

to Finnish: Keskimääräiset laivaston ja siihen liittyvää toimintaa, mukauttaa muuttuviin liiketoiminnan tarpeisiin.

back to English: Average fleet and related activities, to adapt to changing business needs.

(Hmmm. This makes me wonder whether “average fleet” is one example of a set of related activities, or whether one needs to average “fleet and related activities.”)

In any case, perhaps the lesson here is that the farther apart the languages are, the more gets lost in translation. And perhaps that points firmly toward the need for a ubiquitous language, as Eric Evans and the Domain-Driven Design community describe it, across the business stakeholders and the implementation team.

Or perhaps it’s just further evidence that it’s amazing that any software ever does anything useful. (Truly, given how many ways things can go wrong when developing software, I’m often astounded that anything ever works.)

But going back to the original story that prompted this post, where the business people talk to the business analysts who talk to the systems analysts who give requirements to the programmers: I think this simple example in natural language illustrates the risk of having multiple levels of indirection between the business stakeholders and the technical team.

This is why close collaboration between the Product Owner and the implementation team is so important in Agile. Otherwise, the real meaning and intent of the requirements will be lost in translation, and perhaps all the business value as well.

Certification of software professionals has been a hot topic for quite a while. At least 15 years. Maybe longer.

I keep hoping that the whole thing will blow over.

But it hasn’t. And it’s not going to. Too many people have too much of a financial stake in the success of certifications. Certification customers, including individuals and their employers, want certifications to have value. Certification providers want to continue making money.

But while I’ve been able to ignore most development and test certification initiatives up until now, I don’t think I am going to be able to ignore Agile certifications for much longer.

So I guess it’s time for me to talk about this publicly. I’ll start with tester certifications.

General certification programs, like the ISTQB tester certification, focus on knowledge of “best practices” and definitions. I have nothing against learning the material in the ISTQB Syllabus. There’s good stuff in there (even if the most recent books in the Foundations bibliography were published in 2004). However, I do have a problem with charging a whopping huge amount of money for test preparation classes, and testing people on their ability to memorize the contents on a Body of Knowledge, then slapping a Certified Tester stamp on their forehead.

The classes surely have some value. The trainers I know who teach certification prep classes certainly have much to offer. I see no harm in learning what these people have to teach.

But the cost of these classes is high. Certification preparation class can cost hundreds of dollars more than comparable non-certification classes, and the ISTQB test fee is another couple of hundred dollars.

And for what?

It is not clear to me that there is any evidence demonstrating a positive correlation between competence at software testing and possession of an ISTQB certification. (Some wags have argued that there is a negative correlation. I’m not going there.)

Rather, I suspect there is no correlation. I do not believe that certified software testers are any better at testing, on average, than uncertified testers.

And because I do not think there is a correlation between tester certification and competence, I see no value in software testing certifications. I think they’re a marketing scheme concocted to increase training revenues.

But people buy into this stuff, and classes leading to certification outsell classes that don’t lead to certification.

It’s important for me to note that I don’t have any problem with certifications in a specific technology. When Microsoft certifies someone as an MCSE, it means that Microsoft, the creator of a technology, is certifying that the candidate has met minimum competency requirements in that technology. Microsoft is not pretending to certify someone as a developer; they’re certifying that the candidate knows some specific fiddly details about a specific technology related to development.

It may seem like I’m splitting hairs. But it’s an important difference. There is a right and a wrong answer for specific technical questions like how to change a Windows Registry setting (hint: it’s not the form you submit to Microsoft to register your copy of Windows). General topics, like Software Testing, are not so clear cut. What’s right in one context could be dead wrong in another.

So, enough on tester certifications. I’ve successfully ignored them up until now, and plan to continue ignoring them in the future.

What I’m really concerned about are general Agile certifications.

I started hearing the rumblings around Agile certification some years back. In response, the Agile Alliance published a statement about certifications. It’s a good statement. I’m delighted the AA published it. I was in the room when Brian Marick and a small group decided to write the statement and I think they did a fabulous job on it. That can’t have been an easy thing to write.

And I was delighted when Laurent Bossavit and Brian Marick started WeVouchFor, a different kind of certification involving endorsements of competence rather than tests of knowledge.

Sure, there’s always a risk with endorsements that it becomes a kind of you-scratch-my-back-I-scratch-yours mutual love-fest. But I think that even such reciprocal endorsement arrangements say far more than commercial exam-based certifications that have a pass rate in the high 90%s. I’m not alone in that perspective, but endorsements alone are not enough for a lot of people. They want the certification.

I do understand the desire to have Agile certifications.

Agile is relatively new. There are a lot of people, and companies, sporting big ol’ “Now with Agile!” stickers slapped on top of their old RUP/CMM/CMMi/current-hot-thing stickers. So it can be difficult to tell those with deep Agile understanding from those who think they’ll make more money by adopting the hot buzzword-of-the-month.

And so employers look for objective evidence, like certifications, that someone who claims to know Agile actually knows what they’re talking about. And individuals want those certifications as a form of evidence.

The only real Agile certifications that I am aware of right now are the various Scrum certifications. Since Scrum is now the most popular Agile process, it’s no surprise that the Certified Scrum Master (CSM) is the most commonly-held Agile-related certification available today.

As an aside, it’s my understanding that the CSM designation started as a kind of an in-joke. I got my CSM by taking the CSM class. In it, Ken Schwaber said that the certification meant that we probably knew a little more at the end of class than we did at the beginning. But he wasn’t guaranteeing it. And then he taught us all the “secret handshake” (woof) so we could prove to other CSMs that we were in the club. (For the record, I took the CSM class so I could meet Ken Schwaber and learn about Scrum from one of the originators. The certification was a side effect of taking the class. The AHA! moments and resulting deep learnings are far more valuable to me than the certification.)

Then the Scrum Alliance decided to take the CSM, and other Scrum certifications, seriously. They put teeth in the certification.

And that’s fine. It seems to me that the Scrum certifications are like technology certifications. The Scrum Alliance is certifying knowledge of Scrum, a specific process. They’re not trying to certify general knowledge across all things Agile. They’re not saying that being a CSM means you’re generally competent. They’re just saying that being a CSM means you know what a Scrum Master does within the Scrum process. You know the mechanics.

Further, the CSM class is fabulous with or without certification. It’s experience-based, participative, interactive and leads to deep learning. I recommend it.

But this week, I am again hearing the rumblings for general Agile certifications, not just Scrum certifications.

People are asking me how to become Certified Agile Testers. The very thought makes me queasy. Agile Testing isn’t a process or a technology. It’s testing in an Agile context. And that’s not something I know how to certify someone in.

And just today I ran across a site run by the self-proclaimed World Agile Qualifications Board. And that made me angry. Really angry. Angry enough to write this post and not to link to their site. You can search them out if you want to, but I won’t drive traffic their way.

Alan Page suggested on Twitter that perhaps it’s an April Fool’s Joke, like Waterfall2006.com. I’m hoping he’s right. I’d rather feel stupid for falling for the joke than outraged at the reality.

However, even if it turns out to be a practical joke, the strength of my anger surprised me.

On reflection, and being brutally honest, I realized that it’s an anger borne of fear.

I fear that the quest for certification and availability of general Agile certifications, no matter how dodgy, will lead people away from the non-certification classes and services that I, and others like me, offer.

In this economy, that could be disastrous for my business.

I would like to believe that people in this industry are sufficiently discerning that they will come to my Agile Testing classes because my classes are valuable. The kinds of things I teach are not the kinds of things that are certifiable.

How do you certify someone on the realization that they’ve been playing the hero all too often? Or on the bone-deep visceral understanding around the effects of changes in feedback latency. These are the kinds of lessons that I believe participants in my Agile Transformation simulation learn. And they are not things that translate to a certification exam.

And so I am afraid, even though I know that fear is a lousy compass.

Being afraid makes me feel pressure to offer something certification related. But doing so goes against my principles for all the reasons I’ve already explained.

Maybe the best thing I could do would be to offer a self-certification. Want a certification? Declare yourself certifiably Test Obsessed. Here’s the certificate:

I was honored to be included on the lunch and learn panel at the Software Quality Association of Denver (SQuAD) conference this week. One of the questions that came up had to do with triaging bugs in an Agile context. Here’s my answer, in a bit more detail than I could give at the panel.

The short answer is that there should be so few bugs that triaging them doesn’t make sense. After all, if you only have 2 bugs, how much time do you need to spend discussing whether or not to fix them?

When I say that, people usually shake their head. “Yeah right,” they say. “You obviously don’t live in the real world.” I do live in the real world. Truly, I do. The problem, I suspect, is one of definition. When is a bug counted as a bug?

In an Agile context, I define a bug as behavior in a “Done” story that violates valid expectations of the Product Owner.

There’s plenty of ambiguity in that statement, of course. So let me elaborate a little further.

Let’s start with the Product Owner. Not all Agile teams use this term. So where my definition says “Product Owner,” substitute in the title or name of the person who, in your organization, is responsible for defining what the software should do. This person might be a Business Analyst, a Product Manager, or some other Business Stakeholder.

This person is not anyone on the implementation team. Yes, the testers or programmers may have opinions about what’s a bug and what’s not. The implementation team can advise the Product Owner. But the Product Owner decides.

This person is also not the end user or customer. When end users or customers encounter problems in the field, we listen to them. The Product Owner takes their opinions and preferences and needs into account. But the Product Owner is the person who ultimately decides if the customer has found something that violates valid expectations of the behavior of the system.

Yes, that does put a lot of responsibility on the shoulders of the Product Owner, but that’s where the responsibility belongs. Defining what the software should and should not do is a business decision, not a technical decision.

Speaking of expectations, let’s talk about that a little more.

When the Product Owner defines stories, they have expectations about what the story will look like when it’s done. The implementation team collaborates with the Product Owner on articulating those expectations in the form of Acceptance Criteria or Acceptance Tests.

It’s easy to tell if the software violates those explicit expectations. However, implicit expectations are a little more difficult. And the Product Owner will have implicit expectations that are perfectly valid. There is no way to capture every nuance of every expectation in an Acceptance Test.

Further, there are some expectations that cannot be captured completely. “It should never corrupt data or lose the user’s work,” the Product Owner may say, or “It should never jeopardize the safety of the user.” We cannot possibly create a comprehensive enough set of Acceptance Tests to cover every possibility. So we attend to both the letter of the Acceptance Tests and the spirit, and we use Exploratory Testing to look for unforeseen conditions in which the system misbehaves.

Finally, let’s talk about “Done.” Done means implemented, tested, integrated, explored, and ready to ship or deploy. Done doesn’t just mean coded, Done means finished, complete, ready, polished.

Before we declare a story “Done,” if we find something that would violate the Product Owner’s expectations, we fix it. We don’t argue about it, we don’t debate or triage, we just fix it. This is what it means to have a zero tolerance for bugs. This is how we keep the code base clean and malleable and maintainable. That’s how we avoid accumulating technical debt. We do not tolerate broken windows in our code. And we make sure that there are one or more automated tests that would cover that same case so the problem won’t creep back in. Ever.

And since we just fix them as we find them, we don’t need a name for these things. We don’t need to prioritize them. We don’t need to track them in a bug tracking system. We just take care of them right away.

At this point someone inevitably asks, “But don’t we need to track the history of the things we fix? Don’t we want to collect metrics about them?” To that I answer “Whatever for? We’ve caught it, fixed it, and added a test for it. What possible business value would it have to keep a record of it? Our process obviously worked, so analyzing the data would yield no actionable improvements.”

If we are ever unsure whether something violates the Product Owner’s expectations we ask. We don’t guess. We show the Product Owner. The Product Owner will say one of three things: “Wow, that’s a problem,” or “That’s outside the scope of this story, I’ll add it to the backlog,” Or “Cool! It’s working exactly as I want it to!” If the Product Owner says it’s a problem, we fix it.

If the Product Owner says “Technically, that’s a bug, but I would rather have more features than have you fix that bug, so make a note of it but leave it alone for now” then we tell the Product Owner that it belongs on the backlog. And we explain to the Product Owner that it is not a bug because it does not violate their current expectations of the behavior of the software.

Someone else usually says at this point, “But even if the Product Owner says it’s not a problem, shouldn’t we keep a record of it?” Usually the motivation for wanting to keep a record of things we won’t fix is to cover our backsides so that when the Product Owner comes back and says “Hey! Why didn’t you catch this?” we can point to the bug database and say “We did too catch it and you said not to fix it. Neener neener neener.” If an Agile team needs to keep CYA records, they have problems that bug tracking won’t fix.

Further, there is a high cost to such record keeping.

Many of the traditional teams I worked with (back before I started working with Agile teams) had bug databases that were overflowing with bugs that would never be fixed. Usually these were things that had been reported by people on the team, generally testers, and prioritized as “cosmetic” or “low priority.”

Such collections of low priority issues never added value: we never did anything with all that information. And yet we lugged that data forward from release to release in the mistaken belief that there was value in tracking every single time someone reported some nit picky thing that the business just didn’t care about.

The database became more like a security blanket than a project asset. We spent hours and hours in meetings discussing the issues, making lists of issues to fix, and tweaking the severity and priority settings, only to have all that decision making undone when the next critical feature request or bug came in. If that sounds familiar, it’s time to admit it: that information is not helping move the project forward. So stop carrying it around. It’s costing you more than it’s gaining you.

So when do we report bugs in an Agile context?

After the story is Done and Accepted, we may learn about circumstances in which the completed stories don’t live up to the Product Owner’s expectations. That’s when we have a bug.

If we’re doing things right, there should not be very many of those things. Triaging and tracking bugs in a fancy bug database does not make sense if there are something like 5 open issues at any given time. The Product Owner will prioritize fixing those bugs against other items in the product backlog and the team will move on.

And if we’re not doing things right, we may find out that there are an overwhelming number of the little critters escaping. That’s when we know that we have a real problem with our process. Rather than wasting all that time trying to manage the escaping bugs, we need to step back and figure out what’s causing the infestation. Stop the bugs at the source instead of trying to corral and manage the little critters.

Shameless plug alert!

Dale Emery and I are offering the 3-day Agile Testing Series of classes in Pleasanton, CA on April 22 – 24, 2009, and in Portland, OR on April 28 – 30, 2009.

We’ve structured the three days as a la carte offerings. You can take one, two, or all three days.

• Day 1 is “Adapting to Agile,” also known as The WordCount Simulation.
• Day 2 is “Acceptance Test Driven Development (ATDD) in Practice”
• Day 3 is “Exploratory Testing in an Agile Context”

We have discounted pricing right now: early bird pricing is just $499/day instead of the usual $599. In addition, if you register 2 or more people for the same class simultaneously, you can take advantage of our 20% group discount. And we’re offering a “Buy 3 get 1 free” Guest Pass offer where if you buy the whole series, you’ll get a Guest Pass to give to a friend or colleague so they can join in the fun (some restrictions apply, see terms and conditions for details).

And if that’s not enough, I’ve created a limited coupon offer for my blog readers. The first 5 people who register for each class using the coupon code “testobsessed” will receive an extra 10% discount on the class fee.

It had already been a frustrating morning. Too little sleep, and too little coffee. Squabbling kids. Traffic. Parents who didn’t know how to use the carpool lane at school and just stopped in the middle of the road, holding up traffic for 5 minutes while Junior fetched his lunchbox from the depths of the giant SUV. By the time I got to work, I had my cranky pants on.

And so when I read through a series of messages in some online forum or another in which some poor newbie was asking questions about Agile that indicated that they Just Didn’t Get It, I had to bite my tongue. I was not going to take out my frustrations with my morning commute on some poor unsuspecting person asking a perfectly legitimate, if naive, question.

But I couldn’t just ignore it. The wrongness of the assumptions in the message nagged at me, distracted me, kept me from focusing on the stack of work I intended to do.

So I wrote the following on Twitter:

If the org has 1-1 map btwn old vocab & new (e.g. WBS==sprint backlog, PM==Scrum Mastr, status meeting==Daily Scrum) they’re doin’ it wrong.

Turns out that was just the beginning. It seems there’s no end of ideas about how NOT to do Agile. I soon found myself writing about misinterpretations of TDD:

If the org thinks TDD means the testers write test documents before coding starts, they’re doin’ it wrong.

If the devs think TDD means writing *all* the unit tests in advance, and only then writing the production code, they’re doin’ it wrong.

@qualityfrog picked up on that with his contribution:

If those without title ‘developer’ aren’t included as team members, they’re doing it wrong.

Then @woodybrood suggested I should tag them. Thus, the #notagile tag was born. My most recent #notagile entries:

If an Agile team’s typical cycle time for critically important PO-requested fixes is measured in months, they’re doin’ it wrong. #notagile

If the Agile process has a reqs sprint and a design sprint and a code sprint and a test sprint, they’re doin’ it wrong. #notagile

I’m finding that having a place to put How Not to do Agile ideas is helping me. It’s cathartic. I’m not finding myself distracted the urge to write long diatribes on my blog anymore. And I’m pretty sure it’s lowering my blood pressure.

Follow along or feel free to contribute your own to the Twitter stream (tag your tweet with #notagile).

I’m in the process of writing marketing copy for a series of public classes that Dale Emery and I will be offering on April 22 – 24 in Pleasanton, CA and April 28 – 30 in Portland, OR.

(I am also still working on getting the registration system to bend to my will, so you can’t register just yet. I’ll post something here when the registration system finally goes live…soon, soon…)

Anyway…

I was wondering if I could impose on the collective wisdom of the general community to help me hone my message?

First, some background…

The classes are a 3-day series of Agile Testing related classes.

• Day 1 is “Adapting to Agile,” also known as The WordCount Simulation.
• Day 2 is “Acceptance Test Driven Development (ATDD) in Practice”
• Day 3 is “Exploratory Testing in an Agile Context”

The classes can be taken individually, or in combination.

From a marketing perspective, I want to include a little Question and Answer style blurb about what days someone should plan to take. For example:

I’m in a QA/QE/Testing group, and my organization is adopting Agile. This is all new to me. Where should I start?

We strongly recommend that you take all three classes in this series.

The first day, “Adapting to Agile,” will give you an opportunity to experience an Agile transformation and see how the whole team (not just testers) adapts testing-related activities as the context changes. Along the way, you’ll learn how test activities can support Agility by increasing visibility and feedback. And you’ll learn how to spot waste and focus on customer value in testing.

The second day, “Acceptance Test Driven Development (ATDD) in Practice,” will give you an understanding of how test specialists can contribute throughout the development cycle. ATDD might also address the concerns you might have around how you’ll be able to derive tests without having requirements documents.

The third day, “Exploratory Testing in an Agile Context,” will teach you about applying Session-Based Exploratory Testing as part of a sprint or iteration. It will also answer concerns you might have around how an Agile team tests for the risks and vulnerabilities that are not covered by the automated tests.

And as long as I’m doing that, I wanted to extend the idea to include questions and answers aimed at convincing team members that Agile Testing classes aren’t just for testers. To that end, I wrote the following:

I’m a Developer. Are these classes just for testers?

Nope! We want you to participate! Please join us!

As a Developer on an Agile team, you contribute a great deal to the testing-related activities. These classes will help you learn how to collaborate with testers and business stakeholders on various testing-related activities to ensure that the whole team is getting the feedback they need to keep the project moving forward. These classes also might help you convince other people in your organization that testing activities are a shared responsibility on an Agile team.

I’m a Business Analyst/Product Owner/XP Customer. Should I come to these classes? If so, which one?

If you are responsible for defining what the software should do on an Agile project, then you are also ultimately responsible for accepting the software. And yet you don’t have time to test it thoroughly by yourself. You need the help and support of the technical team to be sure when you accept software that it meets your expectations. The practice of Acceptance Test Driven Development is particularly important for that. So if you can come to only one day of these classes, we recommend you come for Day 2, the ATDD class.

If you can come to two days, we recommend that you also take the “Adapting to Agile” class because it will allow you to explore the connection between stories and acceptance tests in a microcosm.

Of course, if you can come for all three days we think you’ll find it very worthwhile. The third day on Exploratory Testing will give you ideas for ways to explore the emerging system to ensure that it really does meet your needs.

Really? I should sign up? But I’m not in QA, and I’m not a Tester. I’m a …

Please excuse us for interrupting.

We hear this a lot: “Great! You have an Agile Testing class! I’ll send my QA department!” There is an unfortunate implicit assumption that the only people who have to worry about testing are the designated Testers or QA people.

In an Agile context, everyone tests.

So no matter what role you play, if you have a role on an Agile team, you have some testing-related responsibilities. Whether you are an Architect, Developer, Database Designer, UI Designer, Technical Writer, Product Owner, Scrum Master, XP Customer, Tester, QA Manager, Quality Engineer, SDET, Build Meister, Configuration Manager, Team Lead, Test Lead, Development Manager, etc., if you’re working on an Agile team that delivers software, you need to know how testing activities in Agile help move the project forward. And you need to be prepared to play your part in ensuring that the software is adequately tested before calling it “Done.”

And by the way, if you are thinking, “I’m not a tester, so I don’t need these classes,” then you REALLY need these classes to find out what you’re missing.

Before I publish all this prose as part of the marketing materials, I would really like some community feedback. What do you think? Is it worth publishing this kind of thing? Is that last little bit too harsh? Too annoying? Is it convincing? What would make it more convincing?

Thanks for any feedback you care to give me.