WordCount: a Happy Surprise

Sometimes teams that run through my WordCount simulation succeed wildly beyond anyone’s expectations. They go beyond the limits of the simulation, achieving a level of effectiveness and efficiency that’s off the charts. I’m always delighted by such occurrences.

One such happy surprise occurred at a private, onsite offering.

Before running the simulation, one of the managers in the organization took me aside. “This group is resistant to Agile. They also have a reputation of being the worst group here. Good luck.”

He shook his head at me a little ruefully. The “good luck” wasn’t sarcastic. It was a genuine expression of hope. The WordCount simulation can transform the way people think. The manager was hoping for just such a transformative experience.

Little did I know that I was about to be the one transformed.

With the manager’s comments ringing in my ears, I introduced the exercise. I was prepared for a difficult session and was emotionally geared up to deal with whatever resistance or anger came my way.

The simulation started off with the predictable pattern. In the first round the group stuck to the silos that I had put them in. As with so many groups that had run through the simulation before them, they didn’t have enough test results or customer feedback to come anywhere close to producing anything useful. They failed to recognize revenue in the first round. That’s normal: no one ever manages to ship in Round 1.

After the first round, we debriefed the results. Then the group tackled the problems they had observed in the first round by adjusting their practices. I pulled back from the group, allowing them to decide for themselves how they wanted to work together for the second round.

That’s where things took a surprising turn.

Often groups that are resisting Agile will hold tight to the process that I impose in the first round. They’ll continue to have designated working areas for Testers and Developers. Even if they do away with the role of “interoffice mail courier,” they will continue to work primarily through artifact handoffs. Sometimes they will even add new roles like “Project Manager” to enforce the process and coordinate activities, creating a level of bureaucracy that surpasses even the cumbersome initial process that I saddled them with.

This group didn’t do any of that. Instead, they gutted the initial process, removing all barriers to communication and collaboration, leaving only just enough process in place to ensure their work didn’t devolve into chaos.

When we started the second round, the Developers, Testers, and Product Managers were all co-located around a single huge table. The Product Managers immediately engaged with me to make sure they understood my requirements, then fed all the information they gleaned from me back to the other participants. The Developers and Testers collaborated on designing and executing tests. The group brought me in for demonstrations and acted on all the feedback I gave them.

The result: they delivered a working system and recognized revenue in the second round. That doesn’t happen very often. I was impressed.

The group fine-tuned their process for the third round, tightening their feedback loops even further. By the end of the third round they’d delivered on all my standard feature requests. I had to start making up new stuff. They further refined their practices for the fourth round. At that point I was scrambling for feature ideas.

I had been prepared for a difficult session in which I would have to nudge and coach and guide participants into recognizing the power of Agile practices. Instead, I had a group that so thoroughly embraced the principles behind Agile that I could hardly keep up with them.

Cognitive dissonance set in. I was almost dizzy trying to reconcile the picture the manager painted for me with the reality I had just witnessed. This group was among the most effective I had ever had the honor to work with. So why did they have a reputation for being among the worst, most resistant?

When we debriefed the whole exercise, I asked some probing questions about their perspective on Agile in the real world.

I learned that they didn’t have anything against Agile per se. But they did have a problem delivering within their organization. Their success as a group was not wholly within their control.

It was a classic case of Conway’s Law. The organization resembled the architecture. This particular group happened to be responsible for a chunk of architecture that depended on other parts of the system. The dependency was one-way, so the other groups tended to ignore this group’s needs. Unfortunately that’s all too common with anything that’s not considered part of the core system: localization, installers, configuration tools, reporting, etc.

Moreover, the group had been living in that context for a very, very long time.

In order to survive, this group had learned how to work within their context to deliver consistently. They were slow by the organization’s standards. But given that this group was completely hamstrung by dependencies on other parts of the system, the fact that they had managed to deliver at all was nothing short of miraculous.

Now that I understood their context, I understood how they had managed to fly through WordCount. In comparison to their real world situation, WordCount, even with all its initial artificial constraints, was a walk in the park.

The whole experience illustrated so nicely how Agile doesn’t solve problems, it reveals them. But it doesn’t always give us a clear picture of the root cause. The manager who took me aside recognized a problem with this group. The problem was very real. But he thought the problem was with the group. It wasn’t. It was with the context in which the group had to operate.

There’s a more general principle at play here. It’s much easier to point the finger at something we can see: an underperforming group. It’s much harder to discover the underlying systemic maladies that led to the problem. We can see the symptoms, not the disease.

And I learned that the team with the worst reputation may be stronger than anyone imagines.

Subscribe

Subscribe to our e-mail newsletter to receive updates.

5 Responses to WordCount: a Happy Surprise

  1. Hector September 24, 2010 at 12:25 pm #

    Thanks for this post. I’ve seen this behavior before but I wasn’t aware of how prevalent (and well documented) it really is.

    If there was a “like” button for this post I would have clicked it many times ­čÖé

  2. Joshua Lewis September 27, 2010 at 10:04 am #

    Interesting post. I think the comment ‘the team with the worst reputation may be stronger than anyone imagines’ is in part true of the team in which I work.

    A lot of the things you describe (blaming people instead of the environment/context) is known as the Fundamental Attribution Theory.

  3. Joshua Lewis September 27, 2010 at 10:08 am #

    Correction: its called the Fundamental Attribution error

  4. Flávio Borges September 29, 2010 at 5:41 pm #

    Very interesting your post.

    I think it’s a great picture of many companies.

    Unfortunatelly, so many people simply can’t see the “disease”, just like you have talked.

    Congratulations.

    See you later!

Trackbacks/Pingbacks

  1. Agile Testing Days 2010 – Day 1 (Agile transitions) « Test Side Story - October 21, 2010

    […] were taking part in the WordCount experiment, of which Elisabeth recounted an earlier experience here. After a round of introductions, we┬ádivided┬ároles within the WordCount company: tester – […]

Leave a Reply