First, let me summarize what I’m trying to accomplish.

Over the years I have received several inquiries asking if I have online versions . . . → Read More: Virtual Training Experiment Report: Lessons Learned]]> Back in August, I called for volunteers to help me experiment with online training. Many folks expressed interest in what I’m trying to do. So I thought I’d write a little status report.

First, let me summarize what I’m trying to accomplish.

Over the years I have received several inquiries asking if I have online versions of my instructor-led testing classes available. I always say “no.” That’s because my classes are interactive, collaborative, and experiential. Participants don’t just do exercises. They take on roles in simulations, play with toys, work in small groups on realistic testing problems, and generate ideas in big group brainstorms. A typical webinar structure doesn’t even come close to supporting that style of training.

But these days virtual collaboration solutions do much more than just let a presenter display slides and talk. So I began to wonder…maybe the technology is finally ready to support the kind of training I do?

I started by defining what I would really need in a virtual classroom, given that I want my online classes to feel as interactive and spontaneous as in real-space. And that means the following:

• Supports at least 6 and preferably 10 or more people connecting from around the world.
• Supports Firefox and Mac seamlessly. (IE-only solutions need not apply.)
• Has integrated VoIP so there’s no phone line needed, and no need to make international phone calls.
• Has integrated video that allows participants to see each other, all at once, in realtime.
• Allows for multiple simultaneous speakers so the conversation can flow at least as smoothly as on a telephone call (no “pass the microphone” metaphor).
• Allows participants to drive a shared browser so they can collaborate on web-based exercises, such as testing a web app.
• Allows participants to capture their individual insights and contribute ideas in a shared workspace, visible to all, in text and drawings.

And of course the performance and reliability has to be at an acceptable level. I don’t know how to quantify what constitutes “acceptable.” But I do know that every time I have to say “I’m sorry, I didn’t catch that. The sound dropped out. Could you repeat what you said?” I’m going to get progressively grumpier. Ultimately my intent would be to offer commercial public classes online, and I can’t ask people to pay for classes when they can only hear 50% of the conversation.

So to figure out if the technology was ready for prime time, I held a series experiments. Many were small, involving just me and one other person. Two were larger experiments with six and five people respectively (including me).

The results were mixed. I’m still cautiously optimistic, but not completely convinced the technology is ready for this kind of usage.

In each of the two big experiments – held on two different virtual meeting solutions – the sequence of events was remarkably similar:

1. Got everyone connected. That involved a lot of rounds of “Can you hear me now?” and “I can’t see you!” and “How do I…?”
2. Discovered that the VoIP audio was flaking out, and took steps to throttle back on the video bandwidth in an attempt to correct the problem.
3. Did a round of introductions.
4. Did an online version of a short exercise that I use in real classroom settings.
5. Debriefed the exercise.
6. Debriefed the overall experience.

So far, the lessons I’ve learned include…

Have Two Machines
As the meeting leader, I find it incredibly useful to be logged into the meeting twice, once as Host, and once as a normal participant. This ensures that I see what the participants see. And it gives me a safety net so that if one machine is experiencing technical difficulties, I have another way to connect with participants.

The Webcams Are Important
When I started this process, I wondered if webcams were actually necessary or if they were gold-plating. I discovered that the webcams are essential to create the kind of collaborative atmosphere I want to create. As one of the participants in the first experiment put it: being able to see the other people created a bond. Amazing how a 1″x1″ 1-frame-per-second-stop-motion-animation of a person contributes so much to forging a connection.

Let Participants Type
In the first experiment I ran with other people, I did the same things I do in a classroom setting. So when I shared the web page with the exercise we were going to work through together as a group, I drove, just as I would if I were projecting the exercise onto a screen at the front of the room. And when we debriefed the exercise, I typed. Finally one of the participants said, “Wait a minute…we all have keyboards, so why are you the only one typing?” Doh! Of course! That’s why the whiteboard is a shared resource: so everyone can contribute insights without having me act as a scribe. It’s why I wanted a shared collaborative space to begin with. Silly me! I was too accustomed to the physical constraints of laptops and projectors and pens and flipcharts.

So I made the participants type more in the second experiment, and I think the results were better. (Not perfect, but better.) I will continue to find ways to ensure all participants have the opportunity to drive and type. I think that this is actually one way in which a virtual venue could be MORE effective than a real classroom.

Watch the Momentum
In the real world when I run extended exercises, the participants tend to have a fair amount of momentum. My problem usually isn’t keeping the participants engaged in the work, but getting them to stop. In a virtual context, I have observed that the discussion seems to grind to a halt much more easily. I’m not sure why yet. But it’s something I need to watch and find ways to address.

Keep the Group Small
Initially I thought I might be able to handle groups of up to a dozen people in a virtual setting. Now I’m thinking eight. It takes more effort and attention than I’d originally imagined to ensure that everyone is participating and engaged, to keep track of who’s saying what, and to monitor the technology to make sure all is well. Also, I think there are still issues with scaling the number of participants, and even eight might push the limits of the technology too much. Maybe six is the right number.

Moving forward, I need to:

• Make the whole experience smoother. That means I need to become much more familiar with all the options and controls so everything is second nature (no more “Now where was that menu option…?”). I think that some of the awkwardness the group felt in the sessions had more to do with my blunders than with real limitations in the technology. So I need to spend more time rehearsing.
• Hold a separate one-on-one session with each participant to check their audio and visual and practice the mechanics of using the technology in advance of the actual session. And that means developing a set of good and preferably relevant-to-the-topic Getting Started one-on-one exercises.
• Experiment with different exercise structures to see if some are better for keeping the momentum going than others. Also experiment with overall course structures. My in-person classes have a blend of individual, small group, and big group work, but emphasize working in groups. I suspect the optimal balance for online training is different. So I plan to experiment with incorporating more self-paced individual work done in preparation for the interactive online sessions.

But before I get too far ahead of myself, I have to decide how much (more) time and money I want to invest in this endeavor. To do that, I need two vital pieces of information:

1. Can the technology really and truly do what I need it to do? My experiments to date have been promising but inconclusive. So in the next few weeks I’ll be running one more big experiment to test performance and audio/video quality with more people. If you’re interested in participating, watch this space for details…
2. Will anyone pay money for it if I can make it work? So far I’ve been much more focused on the question “Is it possible?” than on the question “Does anyone want it?” But I need to assess interest. And you can help. If you would be interested in seeing my company offer online experiential training as a for-pay service, drop a note in the comments or send me an email. (No obligation. No sales person will call. I will not add you to my mail list unless you ask me to. Your feedback just helps me decide if there’s enough public interest to pursue this.)

Oh, and if you have additional questions or comments, feel free to drop a note in the comments about those too!

I think I’ve tested it. I think I’ve fixed all the (sufficiently important) bugs. But that’s just me wearing my developer hat saying “It works on my machine.” If you happen to notice any problems with the new WordPress theme, I’d be most grateful if . . . → Read More: New Look (Beta)]]> I spoke too soon. Last night, I wrote:

I think I’ve tested it. I think I’ve fixed all the (sufficiently important) bugs. But that’s just me wearing my developer hat saying “It works on my machine.” If you happen to notice any problems with the new WordPress theme, I’d be most grateful if you could let me know. Oh, and you can let me know if you like it too. Thanks!

Within minutes of posting that, I realized that the graphics were jaggy and ugly on a PC. Hmph. So I pulled down the new look and the “New Look” post, and went to bed grumbling about ugly PCs vs. beautiful Macs.

Depending on your perspective, I either pulled it down too fast, or not fast enough. By the time I pulled it, Google had already indexed it, and feed readers all over had already gotten the new post via RSS. But when folks went to the site, they got the old look, and no sign of the “New Look (Beta)” post. Confusing to say the least.

But if I’d done things differently, I wouldn’t have gotten Zach’s hilarious email this morning chronicling his adventures trying to find the mysterious “New Look” post.

Anyway…

What I suspect (um, hope) you all don’t know is that I spent a fair amount of time last night fixing functional problems with the site through the tried-and-true, but oh-so-cowboy, process of take-it-live, find-the-fatal-error, take-it-down, fix, and repeat. So by the time I posted the “New Look (Beta)” message I had already solved numerous very real problems and just wanted to be done.

Bugs showing up in production that didn’t show up in the development and test configuration? How could that be?

In trying to create a development and test environment on my local network, I downloaded WordPress and installed it on my Mac. And I then used the Default theme as a starting place. You see, I don’t actually know PHP, and am relatively unskilled at WordPress theme creation. So starting with something that works well, then tweaking it until I got the look I wanted, seemed like a good way to go. (Some of you may be thinking, “Wow, this site looks nothing like the default.” Behold the power of CSS. That, and I learned an awful lot over the last couple of days about how WordPress works. But I digress.)

When I took the new theme live for the first time last night, I discovered my fatal error. The version of WordPress on my local machine is 2.3.1. The version of WordPress installed by my host, GoDaddy, is 2.0.4. And the new theme was incompatible with the version 2.0.4 of WordPress. I got fatal errors all over the place.

So at this point (about 10PM my time), I decided to do something that I would never do if this had been a real software project with real consequences. I decided the fastest way to get from broken to working would be to:

1. Look at the live site to get the error message.
2. Change back to the old theme while I worked to fix the bug.
3. Grep the local files to figure out where the offending code was coming from.
4. Fix each instance of offending code and test locally.
5. Upload the fixes.
6. Change the presentation to the new theme and go back to step 1. Repeat till done.

Cowboy, yes. But it worked. Within 15 minutes I’d fixed all the fatal errors and the site was actually functioning. Like I said: not recommended for real projects, but this is my blog, not a mission critical web app. And it would have taken me at least an hour to downgrade my local WordPress instance and do this the proper way. I didn’t have an hour.

After all that, I was so proud that it worked, I overconfidently posted the “New Look (Beta)” message. And only then did I finally got around to looking at the new site on a PC. In retrospect, that was the wrong order to do those things in. In any case, looking at the new design on a PC was just depressing, and I’d had enough for one night.

This morning, I figured out that although Macs make scaled-down images look nice in a browser, PCs don’t. I’d taken a shortcut and rather than resizing the images properly as I tweaked the design, I just used the WIDTH and HEIGHT attributes in the IMG tag to change their size. The result was that the images looked oh-so-1985 jaggy on a PC.

This whole experience underscores the importance of cross-browser and cross-functional testing before taking a site live. I knew that. Really I did. But I ignored it because my local network just isn’t set up to make this kind of thing easy. I knew it would be a little bit of a hassle to get a PC to surf to WordPress hosted on my Mac, and I couldn’t be bothered. I was overconfident about my ability to create designs that work cross-browser and cross-platform. And I was willing to take the risk if I was wrong. Mostly, I was just being impatient. I wanted to get the new look live before I went to bed, and I was tired and wanted to sleep.

These are all really bad reasons not to test. But then this is why I develop my own websites instead of outsourcing the effort. I need these reminders of how easy it is to choose to do the wrong thing for bad – but legitimate sounding at the time – reasons.

You see, I hear “we can’t do that kind of testing because it’s too hard” from my clients on a regular basis. And it would be too easy for me to become all judgmental and say “it’s not that hard; you’re just lazy.” But I can’t say that because I make the same dang mistakes in my own development. So instead of grumbling about lazy developers, I say “I know it’s hard. But it’s important. So instead of telling me that it can’t be done, please tell me what it would take to make it more feasible, and we’ll work on that.”

Oh, and for the record I’ve now set up my Mac and PC so I can surf to the test site running on the Mac from the PC easily. (Mostly that involved adding entries to the hosts file on the PC.) Still haven’t downgraded my local WordPress instance, but I will before I do any more serious theme development. Next time will be different. But since I tend to do these big site redesigns about once a year, next time is also a long way off.

Unless y’all absolutely hate the new look. So tell me what you think…

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 . . . → Read More: Oh, the irony…]]> 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.

First exercise: we went around the room, round-robin style, and everyone contributed an idea.

A Tester said the Developers should write better Specifications.

A Developer said . . . → Read More: The "We Reframe"]]> A long time ago, when I was employed at a software company, I participated in an all-engineering offsite meeting in which we attempted to figure out what we needed to do to improve.

First exercise: we went around the room, round-robin style, and everyone contributed an idea.

A Tester said the Developers should write better Specifications.

A Developer said Marketing should give them Better Requirements.

Another Tester said the Developers should be doing More Unit Testing. (Yes, I was in that group, but it wasn’t me, I swear…OK, maybe it was.)

Someone else said the Managers should do Better Planning.

I knew things were really getting silly when someone said that what was really needed was Better Health Coverage and someone else said Bigger Cubicles. The intent of the meeting was to figure out how we could improve, not to have a two day whine festival.

But what struck me was that no one suggested something that could be accomplished by their own group. No one ever said, “I’d really like to do better at my own work by…” Every single idea was an idea that Someone Else would have to implement. At the end of two days I felt completely demoralized. We had a long to do list, much of it Action Items for management, and nothing that seemed likely to actually happen. Indeed, six months after the meeting, nothing had changed.

Since then, I’ve had the opportunity to lead similar offsite meetings. Whenever I lead such a meeting, I remember how creating a long To Do List for Other People didn’t work well, nor did hosting a Whine Festival.

Fortunately, I’ve discovered a way to avoid the Other People’s To Do List trap.

I ask participants to focus on what they can do. Not what they want someone else to do, but what they, themselves can do. And then I teach them the We Reframe.

The We Reframe involves transforming “They” statements like “They don’t give us documentation” into “We” statements like “We don’t have the information we need to do our jobs effectively”.

The transformation is straightforward. You change the sentence from what someone else isn’t doing to the effect it has on you. Some more examples:

“They aren’t doing unit testing” becomes “We’re getting software that is not stable enough to test.”

“They don’t give us clear requirements” becomes “We don’t know what we’re supposed to build.”

“They aren’t planning” becomes “We feel pulled in too many directions at once.”

This seems like a subtle difference. But reframing the problem in terms of the effect it has on you allows you to own the solution. It frees you from trying to figure out what someone else should do differently and allows you to focus on how you can adapt to the situation.

If we’re getting software that isn’t stable enough to test, what can we do about it? We could reject it. We could provide a set of minimum acceptance tests to the developers. We could integrate our test efforts with the developers’ test efforts, eliminating the handoff that isn’t working. There are a number of things we could do. But if we define the problem as “They aren’t doing unit testing,” there’s very little we can do. We can’t force them to write unit tests. Even if we could, we can’t force them to write good ones that prevent the problem we’re actually experiencing.

The reframe worked well at helping the teams I facilitated come up with an actionable list. And I discovered another profound result of the We Reframe that I hadn’t expected.

By focusing on things they can control directly, participants discovered that they have more power to solve their own problems than they originally thought.

The result is more than a list of things they can start doing immediately. It’s a general change in attitude.

So the next time you feel frustrated because They aren’t doing something, try the We Reframe to see how many things you can do without any help at all from Them.

Oh, and by the way: They are likely to notice when you change how you work, and that might lead Them to consider changing too. It’s worth a shot.

Migrating all this content has me looking at stuff I haven’t really looked at in a . . . → Read More: The Day Tim Lister Asked Me "Why Are Your Pants on Fire?" and How It Changed My Life]]> I’m in the process of migrating a bunch of content from my corporate website over here for reasons which will become apparent when I finally publish the newest version of my corporate website. But that’s a topic for another day.

Migrating all this content has me looking at stuff I haven’t really looked at in a while. And it has me reminiscing. I figure January is as good a time as any to reminisce about presentations and conferences past.

The last file I uploaded were the slides to “Why Are My Pants on Fire?”, a presentation I gave at the SM/ASM 2002 conference.

And that reminded me that I owe Tim Lister a big thank you for the title. And therein lies a story.

Back in 2000, I was working for a company I shall choose not to name. But it wouldn’t matter if I did name it since hardly anyone has heard of it.

While working at this unnamed company, I managed a group whose title was “Quality Engineering” but whose function was much more on the testing side of things.

Like most DotComs at the time, we were under constant pressure to bring the software to market faster.

You’re probably thinking, “Schedule pressure? Right. It’s software. What else is new?” This was different, as I discovered when management made it clear they’d spend just about any amount of money if it meant we could ship a week earlier.

The time pressure meant we took some crazy shortcuts. And that meant I was in crisis mode most of the time. I spent my days chasing down bugs and having nutty debates about whether or not we could ship software that, under certain circumstances we couldn’t quite pin down, would cause a Blue Screen of Death.

A year or so into the job, I took some time out to attend a conference. Talking with others about DotCom insanity gave me a much needed sense of perspective. And it felt rather cathartic.

That’s when I found myself sitting at a table with Tim Lister, Jim Highsmith, and some other luminaries I can’t recall just at this moment. I was, quite frankly, more than a little starstruck. Tom DeMarco and Tim Lister’s book Peopleware changed my life, or at least my career, and this was the first time I met Tim Lister in person.

You’d think being a bit starstruck would keep me quiet. But no. Remember I was feeling cathartic. I talked about my job. A lot. Too much. And much of what I said probably sounded like whining. Let’s be honest. I really was whining. Tim listened for a while, then stopped me.

“Let me get this straight,” he began. “You have a greenfield project with no legacy users to support, right?”

I nodded.

“The code is written in a modern programming language, you still have the original source code, and it’s even kept in version control?”

I nodded again.

“You have no legacy data you’re supposed to import into the system?”

I nodded again.

“SO WHY ARE YOUR PANTS ON FIRE?!?” he demanded.

Why indeed. His question had the desired effect: I stopped whining.

I pondered that question over the next year. I considered Tim’s words each time we had yet another crisis, whenever customers complained about devastating bugs, and every time a DOA build was delivered into test.

Then I left the company. I got tired of the smell of singed pants. I got tired of the crises. And I realized that I couldn’t do anything more to help. I’d done everything I knew how to do, it hadn’t worked, and I was done.

Turns out I had great timing. I didn’t know it at the time, but things were about to go from chaotic to dismal. A couple months after I left they laid off half the staff. A month later, they laid off another big chunk of folks. And a month after that they closed their doors.

That was 2001, the year Silicon Valley turned into a ghost town. You could tell no one in Silicon Valley was working by the shocking lack of traffic on the major freeways: commute times dropped precipitously for the lucky few still employed.

By then, I was back into consulting and training, and my commute involved airports. Lots of airports. And with each new client I visited, I kept pondering Tim’s question.

When you think about a question for that long, eventually answers emerge. About two years after Tim asked me that fateful question, I turned my answers into the “Why Are My Pants on Fire?” presentation. Now it’s one of my most frequently requested talks.

So, that’s the story of how Tim Lister inspired me to transform my miserable whining into useful answers that became a well-received and oft-requested presentation. I’m grateful to Tim for the title and for his wisdom, but most of all, I’m grateful to him for making me see I was at least partly responsible for igniting my own trousers.

One of the things that Jan observed while doing her . . . → Read More: Easily Distracted]]> Jan Chong is a doctoral candidate at Stanford, studying Organizational Behavior. Jan has two CS degrees, so it’s natural that she would combines her interest in software development and organizational behavior by studying XP teams. She presented some of her preliminary findings at Agile 2005.

One of the things that Jan observed while doing her research is that programmers working in pairs are interrupted regularly. That makes sense. The highly collaborative nature of XP increases work-related interruptions. Moreover, pairing means there’s twice the probability of being interrupted. Fortunately, working in pairs also makes it easier to refocus.

But the big surprise for me in Jan’s report was the observation that programmers working alone created interruptions for themselves. Here’s how Jan described one non-XP, non-pairing programmer:

“…Ian has few external interruptions, which gives him the opportunity to devote long stretches of uninterrupted attention to his primary work task. Instead, however, we find that Ian’s session is filled with points at which he turns his attention away from his primary work task without any external impetus. Ian’s session alternates between engagement in periods of focused work and sustained periods of social conversation or other activities unrelated to work.”

Be honest. Do you ever create distractions for yourself? I do. All the time. And apparently I’m not alone.

My distractions are usually work-related. “I should check my mail,” I think. Or “I’d better look up how to…,” But these short diversions often devolve into, well, goofing off. The next thing I know one quick query on Google has turned into two hours of romping through interesting technology-related articles that have nothing to do with the problem at hand.

Reflecting on Jan’s observation helped me recognize a pattern: I’m particularly prone to these self-generated distractions when working on large, complex tasks. And Jan’s observations of Ian increases my suspicion that creating distractions is a common coping mechanism. (That would certainly help explain the wild success of You Tube.)

So if self-generated distractions provide a way of coping with big, boring, or complex tasks, the cure would be to make tasks small, interesting, and straightforward.

Sure enough, I notice that I’m better at sticking to the task at hand when I take small steps with clear completion criteria. For example, if working on my website, I’ll work on one image, text for one page, or one style at a time. The more I try to do at once, the more tempted I am to create a distraction. Distractions provide a mental break. I feel less overwhelmed, and thus less easily distracted, when working in small, well-defined increments. (You might note a similarity here with TDD, yet another way in which XP supports a high degree of productivity.)

Aha! That means being easily distracted isn’t a sign of personal weakness; it’s an indication that I need to redefine or reorganize my work, take smaller steps, and begin with the end in mind.

I can do that. Right after I check out what’s new on Reddit.com.

I got more than I bargained for. I learned a lesson that has . . . → Read More: Who Carries the Risk?]]> I attended Ken Schwaber’s Certified Scrum Master training in June 2005. Yup, I’m a Certified Scrum Master. But I didn’t do the training for the certification. I did it for the learning. And for the chance to meet Ken.

I got more than I bargained for. I learned a lesson that has influenced my actions deeply and that forced me to re-evaluate choices I made in the past. I learned that for years I’d been accepting risk that was not mine to accept.

The lesson started to take root in the middle of an exercise that was supposed to take 90 minutes, with a lunch break in the middle. I was puzzled that it was a 90 minute exercise. I thought our team was just about done before the lunch break. The answers seemed straightforward. I couldn’t imagine spending another 45 minutes hashing through a solution.

I found myself standing in the buffet line next to Ken. “So Ken,” I began. “Why is this a 90 minute exercise? The answer seems obvious.”

Ken just looked at me. He didn’t even shake his head. He just looked at me. Stared. I began to fidget uncomfortably. Finally, he said, “You made this mistake in a previous exercise too. Think about it.”

I did. And I was baffled. What did this exercise have in common with any of the previous exercises?

The answer became clear in the debrief. As we’re talking through possible solutions, Ken brought up more and more nightmare scenarios we hadn’t taken into account with our solution. “What are you going to do about…?” he asked. Each one of his “what ifs” was a clue-by-four smashing its way through my thick skull.

I started having flashbacks to real life projects that resembled the exercise. I was nearly catatonic with growing horror at the realization of the fundamental mistakes I’d made. For years. And I’d thought the exercise was easy. The stark contrast between my overconfidence during the exercise and my sudden awakening during the debrief cemented the lesson.

And I finally saw the connection between the exercises. Each exercise had a moment when you had to choose a course of action. You had to decide whether to engage the stakeholder in a deep discussion about risks and constraints or just deliver something, anything, that might come close to what they needed. The problems to be solved were different. The format of each exercise was different. But in each case there came a moment when you had to decide whether to proceed or back off.

In each case, I’d been in favor of a “deliver something” approach. I’m a get-it-done kind of person. I like to deliver value. I like forward progress. Given the choice between “Do” and “Talk,” I’ll pick “Do” almost every time.

I suddenly became aware that my can-do approach was buffering the stakeholders from full awareness of the treacherous terrain ahead.

As a tester, I think I know something about risk. I know where bugs tend to hide; I know how to spot vulnerabilities in software; and I have a vivid imagination for nightmare scenarios. I test for risk all the time and communicate what I learn to my stakeholders and the team. But my belief that I know something about risk created a huge blind spot. I was unaware that others assume my knowledge of risk means I’m taking care of the risks for them. “Elisabeth has it covered,” they say to themselves. “I don’t need to worry.”

“YES YOU DO!” I would have shouted, if I had known about that internal conversation. “You should ALWAYS worry! So many things could go wrong, so many things I can’t control! I make mistakes. Big ones. Frankly, I can be a COMPLETE MORON sometimes. Please worry. It’s safer!”

But until June 2005, I wasn’t even really aware how much my stakeholders saw me as their salvation from worry. I missed the biggest risk of all: the risk that the people with the power to make decisions would ignore the risks.

I could talk until I was blue in the face about the risks, but my actions—helping to move the project forward—would override my words. “This is dangerous,” I could say. But I would have handed the customer a loaded gun pointed at their feet. “Don’t pull the trigger,” I could say. But the customer has the loaded gun in his hand, pointed at his right foot, and he’s thinking why would I have given it to him if it wasn’t safe?

If that 90 minute exercise had been a real project, we probably would have ended up in court with the Customer’s lawyers saying, “Well, your honor, these software people are the experts, and they failed to advise my client that anything could go wrong.” The client wouldn’t remember the admonitions, warnings, and caveats. They would remember the fact that we delivered something that failed, and they would feel betrayed.

I began wondering about ways I’d unconsciously accepted risk in the real world.

The realization hit me: Any time I reduce visibility I am transferring the responsibility for risk from the project decision makers to myself.

When I worked countless hours of unpaid, unacknowledged overtime in a desperate attempt to bring a troubled project back under control, I thought I was being a hero. But I was accepting risk that wasn’t mine to accept. The stakeholders had a right to know exactly how troubled that project was, and a responsibility to deal with it. I wasn’t being a hero. I was being a loose cannon. The fact that a loose cannon sometimes hits the mark doesn’t change the fact that it’s dangerous to everyone around it.

When I over-committed and re-prioritized my task stack or let some of my lower priority tasks slide, I thought I was doing the right thing by taking care of the important stuff. But because I didn’t discuss the decision to let tasks slide with the team, I shouldered risk I should not have taken on.

When I chose to run only a subset of the tests because we were running out of time, again without discussing my decisions with my stakeholders, I thought I was taking initiative. But once again, I was denying my stakeholders the opportunity to steer the project.

In hindsight, most of my decisions were right. I’m not saying I acted irresponsibly. But I did exceed my authority. The fact that I had reasonably good judgement most of the time does not exonerate me. I had an obligation to push the risk back onto the people with the real responsibility to handle it.

That doesn’t mean I should have forced non-technical business stakeholders to decide exactly what tests I should run. There are certainly times when I am in a better position to see which way we should go to increase the likelihood of success on the project. But it does mean that I should have made the stakeholders more aware of the tradeoffs I was making, at the time I was making them. And I should have consulted with them about options and consequences before making big changes.

This reminds me of a story that a doctor told me.

Resident doctors work insane hours: 30 or 40 hour shifts are not uncommon. That’s hours in a shift, not a week. 40 hours straight. My doctor friend finds this practice terrifying. “Lives are in our hands when we can’t even stand upright,” she lamented. But it’s standard practice and she had no luck trying to convince the hospital administration to change it.

Her solution? She created buttons for all the residents in the ER that read: “It’s been _____ hours since I’ve had any sleep.” The residents would update the number every hour, and patients would know exactly how little sleep their doctor had had. The patients could then decide whether or not they really wanted someone who had been awake for 40 hours straight stitching up a wound, doing a spinal tap, or setting a broken bone.

Now that’s visibility, and it gives the stakeholders the information they need to make a choice.

So how do you bring visibility like that to your projects?
And how do you make sure you don’t accept risks that aren’t yours to accept?