Beware the Hero

The team in the WordCount simulation was floundering. We were midway through the third round and it looked to me like the team wasn’t even close to shipping.

Most teams are able to produce a basic system that I’ll accept in my role as the Customer in the third round, or early in the fourth. That’s important to me; teams need to enjoy at least a modest success. Total failure is depressing, and I have found that teams that fail are more likely to point fingers than glean insights about Agile Testing.

But sometimes, like in this case, a team will struggle to ship anything at all. So I have a variety of techniques for increasing the probability that the team will be able to produce an acceptable system by the end of the fourth round. Sometimes I give the team a little extra time in a round. Sometimes I ease up on my more persnickety requirements. Sometimes I push for specific practices that I think that they’re missing during the mini-retrospectives between rounds. And sometimes, particularly if I sense that a little individual coaching would help, I gently and quietly intervene during the simulation rounds.

In this case, I had noticed that every time the Developers installed new code on the Computer, it caused some kind of problem. The most recent update caused the Computer to throw purple catastrophic error cards with every input. Worse, the code updates were coming very slowly, so I didn’t think the Developers would be able to fix all the problems before time ran out.

I read the code deployed on the Computer, and immediately understood why the Computer was throwing catastrophic errors: there was a simple error in logic. I could also see why the Developers had not detected the problem: the error in logic was hidden in instructions that were so overly complex they were nearly incomprehensible.

So I decided that a Developer intervention was in order.

I walked over to where the Developers were working. One Developer was standing up, a little away from the group, writing code on green cards taped to the wall. The other five Developers were sitting around the table, talking and sketching ideas on notepads. I walked up to the guy standing up, working on green code cards. He was, as far as I could tell, the only one actually writing code.

“How’s it going, Fred*?” I asked.

“Rough,” he grumbled. “I have all these bugs I’m fixing!” He waved his hands at the collection of red bug cards taped to the wall next to the code. “And I’m also having to talk to the Product Managers to understand the real requirements, and also tell the Testers what to test.”

“OK, so you’re overloaded,” I said, reflecting Fred’s frustration back to him. “Are you the only one writing code? What are they doing?” I asked, gesturing to the other Developers.

The other Developers looked up at us. Fred replied, “I’m doing the bug fixes on this release. They’re working on the next release.”

“Yeah,” said a Developer, holding up his notepad. “We’re figuring out how to do the Sorting requirement.”

“So your fictional company hasn’t shipped anything yet, and you have one guy working on making the current release shippable and five people theorizing about how the next set of features could maybe, perhaps, be implemented?” I summarized the current state of affairs.

They all nodded.

“How about if someone helps Fred with the current release?” I asked. “Maybe it would help if someone paired with him on the code?” I looked to the other five Developers for a volunteer.

Fred looked offended. “No,” he said. “That’s not necessary. Let them work on the next release. I’m fixing the bugs. I’m almost done.”

At first, I thought the problem was that the other five Developers were having too much fun theorizing instead of coding, leaving Fred to do the dirty work. But I suddenly realized that there was another dynamic at play.

Fred was enjoying being the go-to guy for this release. Yes, he complained that he had a rough job. But that complaining was his way of saying, “See how hard I work? See how much I can take on? I am carrying this whole release on my shoulders, by myself. I am a Super Star!”

I was not going to be able to talk Fred into accepting help. So I decided to leave Fred to his work, and check in with the Testers. I’d noticed that some of the “bugs” that Fred was supposed to fix weren’t really bugs from the Customer’s point of view, and I wanted to find out how the Testers were designing their test cases.

After checking in with the Testers, I checked in with the Product Managers. Now I was sure that all the requirements and tests were in sync and represented the real Customer requirements. I returned to Fred. He was plugging away with code fixes, batching them up for one big bang install.

“How’s it going?” I asked.

“Good, good. Almost there!” Fred seemed frantic but cheerful.

I worried that Fred was about to install a lot of changes all at once. Installing one change at a time would have given Fred much better feedback.

Then I noticed a new bug on the wall, one with a purple catastrophic error card attached. In his harried state, Fred was ignoring incoming bug reports and test results. “What’s this?” I asked, pointing to the bug.

Fred frowned and shook his head as he read the bug report. He tore it off the wall and rushed over to the Computer table. I followed. Fred slapped the purple card in the middle of the table. “What’s this?” he demanded.

“An error,” replied one of the Computers. “Because of this instruction,” she pointed to a green card. “It doesn’t make sense.”

Fred leaned over, reading. “Of course that makes sense,” he declared as he pointed emphatically at the offending green code card, “That instruction means that you ignore single quotes unless it’s an apostrophe!” Fred walked through the instruction set with the Computer again, step by step, explaining what the code meant. Finally, satisfied that the Computer understood his intent, he went back to his coding wall.

After Fred left the Computer, we ran a Customer acceptance test. I fed the Customer acceptance test phrases as input to the Computer. They were a little closer to having an acceptable system: two of my four acceptance test cases were passing. Closer, but not there yet.

Time was up for the round. So I called “Stop!” and we went into our short debrief and mini-retrospective. The team was grim. The tang of failure hung in the air and made everyone a little edgy.

For half an hour, we talked about bugs and acceptance tests and requirements and alignment and feedback. The team decided to make some changes to improve their practices, and we began again. I felt confident that the team had the information they needed, and much more effective team practices in place, and that they would have an acceptable system early in the fourth round.

However, as we got into the fourth round, I had the sinking feeling that they might actually still fail.

Most of the organization was doing well, as I thought they would. They were working together effectively, collaborating to ensure that tests were automated, that the test results were visible, that requirements and tests were aligned, and that the bugs and new requirements were appropriately prioritized. The team as a whole was on track.

But Fred was all over the place. He was still working on those bugs. He was coding, he was talking to Testers, he was talking to Product Managers, he was arguing with the Computer about how to interpret his instructions. He raced around the room, frantically busy. And Fred’s fixes were the only thing standing between the team and success. No matter how well the rest of the team did, Fred’s inability to get those few remaining bugs fixed was dooming them.

It was not because Fred was incompetent. Far from it. Fred was very capable. Yes, the code he wrote was a little convoluted. But that wasn’t the real problem. The real problem was that because Fred insisted on doing all the fixes for the first release himself, the entire capacity of the team was throttled down to what a single person could do. And that one person was so overloaded he couldn’t process the information he was getting—the test results and bug reports—that he desperately needed in order to make the code work correctly.

By taking so much on his own shoulders, Fred was doing something Ken Schwaber cautioned me about when I took the Certified Scrum Master class: he was being responsible to the point of irresponsibility.

Eventually the team did succeed. 16 minutes into the 15 minute round, the team shipped acceptable software and recognized revenue, and there was much rejoicing.

During the end-of-simulation debrief, I offered my observations about how everything landed on Fred’s shoulders, and how that caused some of the pain they experienced. But I chose not to offer my opinion that Fred relished his role as The Guy Who Did Everything. I don’t believe in public humiliation as a teaching mechanism.

I did, however, want to take Fred aside for a private discussion about his role in the team’s near-failure. Unfortunately I didn’t have a chance before the end of class. It’s entirely possible that Fred still does not realize that he almost single-handedly brought down the whole company. In his mind, he’s the guy who made the software work.

Fred’s experience taught me a crucial lesson: Beware the Hero.

The Hero mindset is deeply ingrained in the software industry culture. As an industry, we’ve romanticized the image of the lone programmer hyped up on caffeine and pizza pulling all nighters, performing technological miracles.

Fred wrote the vast majority of the final shipping code. He fixed the vast majority of the bugs. He coaxed the Product Managers into clarifying the requirements. He helped the Testers know what to test. By all possible measures, Fred was a super star, a Hero.

And yet the team only just barely managed to ship as the fourth round went into overtime. It was an unnecessary near-miss: I’ve seen numerous teams run this simulation, and given the practices this team had in place by the end of the fourth round, they were well-positioned to crank out feature after feature and rack up a tidy sum in fictional revenue. The only thing that held the team up was the bug fixes that Fred had been working on, by himself, for half the simulation.

The team very nearly failed.

All because Fred insisted on being the Hero.

* Not his real name.


Subscribe to our e-mail newsletter to receive updates.

6 Responses to Beware the Hero

  1. Zach Fisher December 2, 2008 at 9:12 pm #


    Boy howdy, I needed to read that today. Thanks for shining your light on this topic.

  2. Jeffrey Fredrick December 2, 2008 at 10:50 pm #

    Great post!

    Reading it and reflecting on Heroes I Have Know it occurred to me that the industry actually breeds heroes by making bug fixing an activity for junior people. They work hard, stay late, and get kudos from customers (or customer proxies)… and think that this is what being a good developer is about.

  3. Phil Kirkham December 3, 2008 at 3:47 am #

    So what would you have said to Fred if you had been able to have a private discussion with him – how do you handle Hero’s ?

    It is a common problem in the industry, I had a short blog about it a while ago

    being a Hero can pay off for the individual, if not for the company

    Elisabeth responds:
    I would have started the conversation with something like, “So, Fred…about the simulation. You took on quite the role there. I’m wondering if you had any personal insights from the experience?”

    His answer would determine how I handled the rest of the conversation. If he said something about how he felt overwhelmed then I would begin by talking to him about his choice not to accept help. If he said something about the near-failure, then I would ask probing questions about what he thought could have been different, guiding him toward the realization of the dangers to the team and organization associated with playing The Hero. If he said something about how he saved the day, I would have given him my counter-observations to help him understand that his actions very nearly cost the team any success.

    And I would probably end up asking if what he experienced in the simulation felt anything like what he experiences in the real world, and if he plays The Hero at work. My guess at the time was that “Fred” is the one everyone depends on at work, and that the simulation felt all too real for him. That kind of parallel between the simulation and the real world happens frequently. And these kinds of quiet, private conversations to process the simulation on a personal level often turn into personal coaching sessions.

    My hope would be that at the end of the conversation Fred would understand the risks of playing The Hero and be more aware of his own triggers and motivations that lead him to heroism so he could make better choices moving forward.

  4. Malapine December 4, 2008 at 11:32 am #

    Suppose WordCount Inc. decides it’s time to lay people off after the product ships(and fails to meet sales projections). Who’s the more likely candidate? Fred the Hero, or one of the five Sidekicks ? As long as this dynamic exists, there is a strong incentive to try and be Hero.

  5. Anna B December 20, 2008 at 4:06 pm #

    If WordCount were a real company, what would have happened to them if Fred got hit by a bus/heart attack? (Or more happily, by a winning lottery ticket/better job offer/sudden change of priorities in life?)

    Or, for that matter, five other people in the project left, and Fred suddenly had to re-explain everything from scratch to the replacements?

    Elisabeth responds:
    I think that if Fred had left suddenly, the team actually would have been in far better shape. Fred’s insistence on working in isolation prevented the team from getting more done. I’ve seen it happen in other simulations where the sudden departure of a Hero enables the team to succeed. It’s a deep irony that the apparently-irreplaceable-heroes can actually be the biggest impediments to success.

  6. Oliver January 29, 2009 at 2:27 pm #

    The’s a LOT of Fred’s out there and as mentioned above our way of working supports the creation of these Heros. It is good for job retention to be one. Especially with hard times coming up. Managers seldom recognise what’s going on. i.e. they are so panicked that they refrain from taking consequences and “Fred” will be the key “issue” on the next release again.

    The danger to projects/companies from big red buses in the street is enormous. The “big red bus” next to never appears on project risk registers or the such. And even if they do it’s more generic.

    The big danger is, what if the “big red bus” is your competitor that hijacks your employee? That can be a double whammy.

    The bad thing is that such issues never get a $$$-tag attached. How do you price-up a Hero? What $-value do you put against the “big red bus” in your project plan? If PMs would do that the whole behaviour would change. We’d also become aware of the ROI that is wasted on those other 5 developers (that are probably close to quitting because they will never be able to live up to the Hero or become one).

    Company financials are generally screwed. This is a good example that does even eventuate in nearly every project. PMs and Unit Managers only look at $$$ and timelines but they only apply 1st grade math.

    As long as the Freds don’t become a $-liability they will not cease to exist. They will probably even be rewarded for the behaviour as the ROI is probably phenomenal.

    (Oh and just from my desk I can see about 3-5 Heros…. and sometimes that includes me too)