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?