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’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.

I’ve mentioned my WordCount simulation here before, and some folks have expressed curiosity about it. I started writing a blog post about it, and quickly realized that it would take a whole lot of blog posts to tell all the stories I want to tell. So I’ll start by explaining the simulation in more detail, and in subsequent blog posts, I’ll tell stories. Some will be amusing little anecdotes. Others will be tragic tales of woe. You’ll laugh, you’ll cry…oh, never mind. Let me just describe the simulation.

So this is the simulation that I use in my Agile Testing class, as well as in other contexts where I want to teach lessons about increasing Agility. The mechanics of the simulation itself are very general: the simulation models the organization of a software company. It just happens to work really well for making Agile concepts very visible, and visceral.

At this point WordCount is a mature simulation: I have honed and refined it over the last several years, and have run it countless times. The simulation requires a lot of moving parts. Just printing the supplies to run the simulation can be a chore. It involves 26 files whose contents are printed on 5 different colors of index cards, 5 different colors of paper and cardstock, and 2 different sizes of stickers. Fortunately for my sanity, I now outsource most of the printing work to a local printer. (Though I swear I can hear the manager groaning when he sees me walk in the door.)

All those moving parts support a relatively simple organization: WordCount, Inc. is a fictional company that makes word counting software. Each participant chooses a role within the company from the following descriptions:

The Product Managers interact with the Customer (played by me or a co-instructor/co-facilitator), define the product, and write requirements on blue index cards.

The Developers turn the requirements from the Product Managers into executable instructions (“code”) on green index cards. The code is then installed on the Computer.

The Testers design test cases on yellow index cards and execute them against the code installed on the Computer by submitting input on white index cards, and receiving output, also on white index cards. Of course, not all input can be processed. If the Computer cannot process the input, it throws a catastrophic error on a purple index card. This usually prompts the Testers to write a bug report on a red index card.

The Computer follows the instructions that the Developers wrote on the green index cards (the “code”) to take the input on the white index cards and process it to generate output, either word counts on a white index card or an error on a purple catastrophic error card. Multiple participants can play the role of the Computer, but the Computer team must coordinate their efforts internally. As you can imagine, sometimes different participants playing the role of Computer interpret the code differently, and give different output for the same input. This inevitably leads to tremendous confusion among the Developers and Testers.

The lone Interoffice Mail Courier (there can be only one) delivers messages and Project Artifacts between groups.

The Observers watch the interactions and share their observations with the group during debriefs. They’re not really part of the company, but they are active participants in the simulation. I usually hand one of the Observers a camera so we have photographic evidence that we can reflect on later as we distill lessons learned from the simulation to apply in the real world.

Throughout the simulation, we work in rounds. So we work on the simulation for 15 minutes, then pause to hold a mini-retrospective in which we reflect and adapt the process to increase Agility.

When we start, there is an existing process in place that resembles a very traditional organization with groups working in silos and very constrained communication. The process explicitly defines responsibilities and communication paths by specifying things like “Communication between Developers, Testers, and Product Managers occurs only through Interoffice Mail,” and “Only Developers may create or modify Code.”

Each group starts with an initial set of artifacts. So the Product Managers have notes from their fictional predecessor’s conversations with the customer, the Developers and Testers have an initial set of requirements, the Developers and the Computer have version 0 of the code, and the Testers have an existing set of tests.

As we begin the simulation, I explain that: as the Customer I desperately need their word counting software to run my business; I have been promised a delivery of the basic word counting system Real Soon Now; so far nothing has been delivered to me. I also make it clear that the more features they ship, the more money they make, and that their goal should be to maximize revenue.

We then work for 15 minutes.

In a typical first round, Product Managers work furiously to produce requirements on blue cards while Developers frantically write code on green cards and Testers crank out test cases on yellow cards. Pens go flying as participants scribble madly on colored 3×5 index cards.

The Interoffice Mail Courier stands by, ready to deliver messages, but typically only has to deliver a handful. One Interoffice Mail Courier was so concerned about the potential volume of mail that he recruited an assistant. They both stood idle for most of the first round, bored. Similarly, the Computer is also usually idle for the first round, and often starts throwing errors just to amuse itself. The Product Managers, Developers, and Testers are so busy producing artifacts that they don’t have time to communicate or even execute the software that already exists.

When we debrief the first round, the Product Managers, Developers, and Testers often report feeling stressed, pressured, and frustrated while the Interoffice Mail Courier and Computers report being under-utilized, idle, and bored.

But all that stress and self-imposed pressure doesn’t yield success. As of today, no group has ever made money in the first round. No group has even come close. In fact, out of all the times I have run this simulation, only one group has ever managed to demonstrate the software to the customer during the first round.

And yet some managers look at the efforts of the Product Managers and Developers and Testers in the first round and see focused productive work happening. In a couple of cases, managers have walked up to me during the first round and said, “Look at how focused each of the teams is! And notice how quiet it is in here! Everyone is working so hard! This is great!” One of the managers was kidding: she knew that the lack of communication would be a problem. But the other manager? She was not kidding. She was dead serious. That’s what she thought productive teams looked like.

As you can probably imagine, I have lots of stories about this simulation. There’s the story of the Hero who single-handedly almost caused the failure of the whole company. There’s the story of the group that actually did fail entirely, and then blamed me for their failure, as though I had played some trick on them. There’s the story of the Micromanaging Manager. There’s a story about a Project Manager who quit in disgust after 15 minutes. And there’s a story about a Product Manager Who Always Said No.

There are stories about Developers arguing with the Computer about the correct interpretation of the code. And there are numerous stories of Product Managers who got so wrapped up writing requirements they forgot to talk to the customer, and Developers who wrote Code that was so complex even they had no idea how to interpret it, and Testers who spent so much time documenting test cases that they forgot to execute them, and myriad other forms of organizational dysfunction that just happen to look a whole lot like real life. That’s why simulations are so much fun: they give us the opportunity to experience all the complexities of the real world distilled into a microcosm.

Along the way I’ve learned numerous lessons like “Never Use a Communication Solution to Solve a Visibility Problem,” and “When Someone Says They Want Control, They Might Just Need Visibility,” and “If the Customer Offers You an Example, Take It.” So I’ll tell stories about those lessons too.

But all those stories will have to wait for another day. This entry is long enough as it is.

And now for a blatant commercial announcement: I’m hosting a public offering of my Agile Testing class with Dale Emery on December 10 and 11 in Pleasanton, CA.

I predict that this is going to be a great class.

First, it features my WordCount simulation, and that’s always fun. I’ve run that simulation over 100 times and I learn something new every time. If you’re looking for a way to get people in your organization to understand, viscerally, why silos and Agile do not mix, this simulation is the best way I’ve discovered so far. It’s also a great way to see the impact that an integrated value-focused test effort that yields fast, visible feedback can have on Agility. (Note to self: I should blog more about lessons I’ve learned from that simulation.)

Second, the class features my Acceptance Test Driven Development (ATDD) demo. ATDD is a powerful way to involve testers early and make testing part of the definition of “Done.” And it’s also a powerful way to integrate test automation efforts into the development cycle instead of succumbing to test-last automation.

Third, Dale will be there. Dale and I make a great team.

When I ran a 1-day variation of this class at the STAREast and STARWest conferences as the “Adapting to Agile” tutorial, it sold out. I am (of course) hoping that this class will do the same.

I have had some people ask if I will hold future public offerings of this class, or other classes. The answer is yes – but only if I can fill this class. So if you want to see me offer more public classes, please come to this class and/or pass on the word to your friends and colleagues. Please help me fill this class…

I finally decided that too many of the things on my To Do list are things that I probably should not be handling personally, like dealing with getting business cards and routine invoicing. And too many of the things that I should be handling personally, and quickly, are being left undone too long.

So I posted an ad for a part time assistant on Craig’s List. And being test obsessed, I devised a test to give me a good indication of whether a given candidate had enough of the skills I needed to bring in for an in-person interview.

I asked the candidates who wrote an articulate reply to the job posting (and there were a lot of them!) to do a little research and find out what conference I’m speaking at in August, where the conference is, and what the titles of my presentations are.

It seemed to me like this was a pretty easy test that would weed out anyone who couldn’t do basic research on the web. But I made the test harder than I intended by asking about conferences in August. I forgot that there are two conferences listed on my web site for August: Agile2008 (where I am not speaking), and STANZ (where I am giving two talks).

When I realized my mistake, I thought “No problem. Good candidates will search for my name in the Agile2008 program and realize I am not speaking there.” Then I tried it myself and discovered that searching for a specific speaker is apparently a use case that the Agile conference organizers didn’t think about when they published the program this year. Even I found it difficult to determine absolutely that I am not on the program. There are too many places to look, and even the PDF program is a little difficult to search for a given speaker’s name.

Sometimes what seems like a simple test – whether of software or of a person – turns out to be much more difficult than we intended or imagined. Although I suppose that as long as none of the job candidates crash as readily as software, we’ll all be OK.

And if any of them manage the task without giving up, I will definitely know something about their ability to find information on the web!

So I woke up this morning to an email from alert reader Michael Ludgate notifying me that when he tried to access any page on my site, he got the following message:

WordPress database error: [Can't create/write to file '/tmp/mysqltmp/#sql_11b6_0.MYI' (Errcode: 2)]


“Oh, joy,” I thought to myself as I began investigating. I knew that the problem could not have been caused by anything I did. First, my most recent update to the site was back on April 2, that was just a content posting, and I was 100% certain my site had been alive and well much more recently than that. Second, I don’t even have shell access, so I couldn’t make a file in /tmp/… disappear if I tried. That meant the problem had to be with my ISP, and was probably outside my control.

After poking around for a little while in the vain hope that if I messed with stuff the tmp file would spontaneously regenerate, I sent a missive off to tech support. The auto-responder helpfully told me that I could expect to wait 24 – 48 hours for a response. Even if this is just a blog, that’s too much downtime. So I decided a phone call was in order.

A baffled tech support rep suggested I uninstall and reinstall WordPress. When I pushed him on how this problem happened to begin with, the tech support rep backpedalled a little and said he’d escalate the issue. I now had an incident number for tracking purposes, and a promise that “someone would get back to me.”

At this point I evaluated my options.

I’ve been growing annoyed with godaddy.com anyway. Every time I log into my admin account, they try to upsell me. They don’t let me have shell access. They don’t support Ruby on Rails well – or not as well as I would like. I find their admin UI clunky. These are little annoyances; they’re not enough to push me to change hosts. But now that I had a down site and no ETA for a fix, I decided that changing hosts was actually the path of least resistance.

So my adventures began. I bought 3 months of hosting on A2hosting.com, a host I’d been contemplating for RoR hosting anyway. I managed to get a backup of my content from my godaddy.com site. (Note to self: I need to revisit my blog backup strategy. I happened to get lucky today – the catastrophic error that made my site unusable mercifully did not prevent me from exporting the data. But that was sheer luck. My previous backup was a couple months old. But I digress.)

I then put up a “pardon the mess” notification on both the old and new sites and changed my DNS entries to point to the DNS servers at the new location on A2. And I installed WordPress on the new site.

I had to wait for the DNS changes to propagate before I could do more because every attempt to log into the WordPress admin interface in the new location redirected me to the old site. Fortunately, I had to go to an appointment anyway. By the time I got back I could see the new IP address when I pinged testobsessed.com.

I then began migrating the content. That meant restoring the content from the SQL backup through a MySQL admin interface, upgrading the tables, panicking when it looked like the schema wasn’t going to upgrade cleanly, and finally breathing a sigh of relief when I saw the old content in the new site.

But wait! There was still more to do. I uploaded the theme files and other resources (including images and pdfs and such). I fixed the permalink settings. I tested. I fixed glitches. I tested again. I swore.

And finally I got the old site up on a new host.

This is, quite frankly, NOT how I expected to spend my day. I was supposed to be doing paperwork – invoices, expense reports, contracts, that sort of thing. This was a geekier, and possibly more exciting way to spend my day, but it was not at all what I had planned. And in my haste it is certainly possible that I missed some detail.

I think everything is working now. Please let me know if you find anything strange – missing content, broken links, whatever. (No, I don’t have a full set of automated regression tests to cover every link I publish. I’ve considered it, but the cost of maintaining such a suite of tests seems a little high for a non-revenue-generating blog.)

And that escalated trouble ticket filed with godaddy? Still not handled. I’m not particularly surprised. My suspicion is that the problem I encountered is somehow related to the fact that I had not migrated my WordPress to their whiz-bang new Hosting Connection application management console thingy. That first tech support rep was probably right: I could have solved my problem by uninstalling and re-installing WordPress.

But I don’t think that would have been any easier than moving hosts – the only saved step would have been the DNS change. And I’m happier having migrated. And – as an extra bonus – the site even seems to be responding a little zippier.

This little digression will probably boost another back-burner project to the foreground: I’ve been meaning to change the way I manage my main company site. Other alert readers have pointed out to me that my calendar at qualitytree.com is more than a year out of date. It’s embarrassing. But I haven’t fixed it because I publish that site using an obscure little Windows-based CMS. Since I’ve gone all-Mac, updating qualitytree.com means I have to boot up my old Windows laptop, and I hate doing that.

I’m going to see how things go with the new host for a while before migrating everything. But it looks like I’ll be migrating my other website sooner rather than later.

And now I’d better start on that paperwork I meant to take care of today.

So I’ve been a little stuck in my writing lately. And that’s a problem. After all, I’ve got like 4 books worth of material stewing around in my brain, and I’d really like to get all those random thoughts down in words and sections and chapters and bound into actual books. It’s about time. Seriously. I can’t go to a conference without someone asking me “How’s that book coming? The one you were working on like 7 years ago?”

(For those who are keeping track: the book Bug Hunting will never see the light of day – it had a couple good chapters and the rest was cr*p; the book I was writing with Jerry Weinberg on testing is now Jerry’s book; any other books I may have mentioned in passing are pure speculation. While I have failed utterly at authoring or co-authoring any books, I have succeeded at contributing to other people’s books. You’ll find my words in Roundtable on Project Management edited by James Bullock and Jerry Weinberg, Visual Basic for Testers by Mary Sweeney, Windows Development Power Tools by James Avery and Jim Holmes, and most recently The Art of Agile Development by Jim Shore and Shane Warden. So it’s about time for me to figure out how to produce a book of my own. But I digress.)

Now I don’t think my problem is laziness or busy-ness or even classic writers block. Rather, every time I sat down to write anything of substance – anything longer than an email or a blog post – I felt the insistent tug of excessive friction. My writing tools were not working for me. They were working against me. And I found myself fighting them too much. So I decided that what I really needed was a new and better writing tool. Something that would work the way I work and think. Something that wouldn’t get in my way. Something that was not Microsoft Word.

Now I’ve tried a lot of editors over the years. I’ve tried plain old text editors and fancy WYSIWYG editors and mind mapping tools and even Google’s online editors. Of all of them, Google’s stuff fit my style best. I like it’s simplicity, the ease with which I can share drafts with reviewers and collaborators, and the tagging mechanism for documents. I used that last feature for organizing snippets of prose. But the biggest downside is that it doesn’t work so well for me on an airplane (given that it’s a web-based editor and all). And even if it did, it has some annoying glitchy-ness in simple editing functions (like weirdness with Undo) that just gets in the way.

For writing prose, my needs are simple. I don’t need a whole lot of formatting options just for getting words out. I need to be able to organize snippets of prose (as in Jerry Weinberg’s fieldstone writing method), I need to be able to look at all my related text in one place, and the solution has to scale to book size. The need for both organizing bite-sized bits and seeing the whole thing is why Google Docs came closest to my needs. Other solutions excelled at one side of the equation and failed utterly at the other. Mind Manager is great for dealing with little nuggets, but doesn’t let me see everything all together easily. So the result is highly fragmented writing. By contrast, Word lets me see all my prose in one place, but its outliner is just awful and let’s not even talk about scaling up to book size with the whole Master Document feature. Ugh!

So my latest find, the thing I’m trying now, is Scrivener. I’m not sure yet if it will really fit my style. And I haven’t tested it to see if it scales. So it’s too early to tell if I’ve found my writing tool of choice. But even though I had 29 days left on the evaluation, and even though I don’t yet know if it will really work for me, I bought it anyway. Why? Because the company that makes it took extra pains to make it work with subversion.

Yup, taking extra care to make sure a writing tool works with a source control system is enough reason for me to proclaim my love for them on the Internet and give the company money.

Those of you who caught my recent posting about my ability to make Keynote melt down know how annoyed I was that Keynote did not work with subversion. And another consultant I told about the experience commented “Well, that’s a non-starter isn’t it? Not working with subversion. Hmph. <snort>.”

Well Scrivener got it right. Even though Scrivener uses a similar Mac-trick to Keynote by making their “file” actually be a directory, Scrivener does not blow away the crucial .svn files needed for subversion to work. I know because I tested it. In short, Literature and Latte, Scrivener’s publisher, understood that version control is a crucial part of a professional’s workflow. They paid attention. And I love them for that.

Now – will the rest of the features help me write more? The storyboard feature looks really cool. The whole screen editing feature is great at removing distractions. But only time will tell if Scrivener and I can achieve a productive mind meld. I’ll let you know when I have a book draft done. And no, I won’t tell you what book I’m working on. I have an amazing track record of not delivering on pre-announced book titles, so the only thing I’ll admit to is that I have a book in the works. And I’ll talk about it after I’ve managed to write a whole first draft.

After almost a month on the road, I’m back in my office for a little while. This week I’ll be catching up on paperwork. (I’m really behind in my invoicing – and yes, that is a very bad thing for a business owner to get behind in. So if you’re expecting an invoice from me, you’ll be getting it this week.)

And, perhaps of greater interest to those who follow this blog, this week I’ll also be working on that virtual training project. And also working on an Agile transformations class with Dale Emery.

I also plan to blog a bit. I took some fun pictures in China that I plan to share.

More news soon.

So I’m working on course materials for a class I’ll be teaching next week on Acceptance Test Driven Development.

I decided to try using Keynote on my trusty no-longer-all-that-new Mac instead of PowerPoint. I find PowerPoint on the Mac incredibly annoying. Whenever I want to edit a presentation on the Mac that I created on the PC (like, all of the presentations I have), I get Converting Metadata messages all over the place. When editing a 300 slide file, making even the smallest change can take forever. So, Keynote seemed like a better alternative.

Now I should explain that although most of my slide decks look reasonably simple, I tend to use a lot of animations for certain types of things – like bringing a workflow to life.

And I also use the presenter notes area as a place to put the meat of the materials for participants so that when I print books with both the slide and the presenter notes, there’s a good amount of text. The result are course notes that read kind of like a book with a whole lot of illustrations.So in other words, I am not your typical lightweight presentation software user. And I’ve crashed PowerPoint a lot as a result.

But I had high hopes for Keynote. For starters, it’s Mac software. Built for Macs. None of this ported over from Windows crap.

Alas, I was doomed to disappointment.

First, when I attempted to do some fiddly edits on the text under a page with a ton of animations, Keynote died a horrible death. It didn’t exactly freeze entirely, but I could no longer edit the content. I could attempt to save/export my file, but every time I did – no matter what format – it told me that the file was corrupt. Sadly, I’ve gotten out of the habit of saving every 30 seconds, so I lost a fair amount of work.

When I finally recovered everything an hour later, I vowed not to make the same mistake again. I not only started saving rabidly every 30 seconds, but I also checked everything into my subversion repository. However, when a subsequent commit failed with the message “Directory …/.svn containing working copy admin area is missing” I learned that there’s an interaction bug between Keynote and Subversion. I used the workaround kindly published by Daniel Sadilek (bless you, dude). And I was back in business. Annoyed, but back in business.

But here’s the thing. I’m already annoyed, and now I’m looking at my .key file for a 27 slide file, and it’s 3.8Mb. What??? I know I’m abusive to presentation software. I understand that my usage is a tad on the abnormal side. But 3.8Mb for 27 slides? Slides with graphic drawings and text, no photos, no movies, no sounds? That’s nuts. With a little experimentation I discovered that more than half that is due to two slides that make extensive use of animations. And I’m betting that those same animations had something to do with Keynote dying a horrible death when I tweaked the text underneath. Someday when I have more time I’ll see if I can reproduce the bug.

Let’s just say I’m re-evaluating my decision to use Keynote. PowerPoint is looking pretty good right now. Sigh.

And this is also a lesson re-learned about software testing: there’s nothing like a real user to find real problems. For Agile projects, that means automated unit and acceptance tests are necessary but not sufficient. Make sure real humans try the software under real world conditions. Given the topic of the course materials I was working on, this was a timely reminder…though a far more painful one than I really wanted.

Earlier this year, I worked with an XP team where we had remote team members using a combination of Skype, webcams, and virtual desktop to give them a virtual presence in the team room. I was surprised how well it worked.

Sure, it was a little weird the first time I remote-paired and my pair did the driving: code appeared on the screen as if by magic. Fortunately, my pair was good at talking about his thought process, and his voice filled in the void left by the lack of visible physical cues like a hand hovering over a mouse or restless shifting in the chair.

Prior to that project, I thought it would be extremely difficult to integrate remote employees on an Agile team. But with an always-on Skype connection and a liberal scattering of speakers and microphones, the remote team members were truly present, albeit virtually. They were even there for the hallway chatter. You’d be chatting about something casually with another team member, like ways to structure validations in Ruby on Rails, and a disembodied voice would chime in – just like any other coworker who happened by and who had an opinion.

I began to think of our remote colleagues as coworkers with the curious disability of not having a corporeal body. Those of us in the team room had to make reasonable accommodations like ensuring we kept Skype running on certain boxes, and kept microphones and speakers plugged in. But the remote team members’ ability to contribute was not hampered by the lack of a body. They participated like anyone else.

That’s when I realized that the technology to support remote collaboration has become cheap enough, reliable enough, and ubiquitous enough that people in disparate locations actually can work together remotely as effectively as when they’re in the same room, at least under certain circumstances.

And that makes me wonder if the technology is now advanced enough to support a virtual version of the kind of training I like to do: experiential, interactive, hands-on training.

I should back up a step and explain that I’m not new to virtual training. I’ve been a webinar speaker. And I’ve been a participant in online classes. I know there are all kinds of solutions out there for presentation-based training. But most of the technologies I’ve seen assume there’s a slide deck. The tools do support interactivity, but mostly as Q&A instead of deeper interactive discussions or exercises.

I want something more. I want to be able to do simulations and experiential exercises and real debriefs in a virtual online classroom and have it feel as interactive and collaborative and spontaneous as in a conference room in real-space.

And I think, perhaps, the technology is getting to the point where we can.

Others think so too. James Bach has been experimenting with online virtual training. He recognized that the technology was ready before I did. And it’s going so well he’s planning to do more of it.

So…all this is a long lead in to say that I’ve started experimenting with online training. So far my experiments have been promising but limited. And I’m ready to do more.

If you’re interested in participating in any of my experiments, drop me an email or a note in the comments. I’m looking for volunteers who want to subject themselves to a small sampling of my training and exercises – free – in exchange for feedback. (You will need a broadband connection, webcam, microphone, speakers, and up-to-date browser. You may need a flexible schedule since I want to experiment with 4 – 6 participants, and finding a time that works for everyone can be a challenge. And you’ll need some patience. I’m still experimenting.)

Interested?