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.

Agile Backlash? Or Career Wakeup Call?

I’ve been reading accounts of how Agile has ruined lives. It’s quite the hot topic at the moment. Initially I thought it was yet another Agile backlash.

But unlike some of the previous anti-Agile rhetoric I’ve encountered, this isn’t by Traditional Consultants accusing Agile Consultants of playing with post-its instead of doing “real software engineering.” Nor is it by Traditionalists looking at Agile from the outside and saying “that dog don’t hunt.” Rather, it’s by practitioners who have been on “Agile” projects and burned in some way. These are working programmers with skin in the game. And they’re hurting.

So I started reading more carefully.

As I read through the vitriol in the comments, I noticed two general patterns.

The first pattern involves people who have been burned by a corrupted flavor of “Agile” foisted on them by clueless managers in dysfunctional organizations. By “clueless,” I mean the kind of manager who thinks the way to find a qualified coach is to find someone with a certification from a 2-day CSM class. Or the kind of manager who thinks that if we do a global search and replace on key phrases in our process docs that we will somehow be transformed into an “Agile” organization. By this I mean:

phase -> iteration
project manager -> scrum master
requirements -> stories
estimated hours -> points
status meeting -> standup

Sadly, there’s nothing we can do to prevent this bastardization of the word “Agile.” It happens with every buzzword. ISO, CMM, CMMi, RUP, take your pick.

I was on a project once where management decided that UML was the right cure for all our ills. Of course, it wasn’t. Didn’t help a bit. Actually made things worse. After everyone got trained up on UML we had to have meetings to review useless artifacts created only so we could check off a task item: “Create Use Case.” But UML was not the problem. The real problem was an executive team in so far over their heads that they were willing to believe in magic, and a staff so burned out and sick from the verbal abuse that they were willing to pretend magic existed.

So, to the people who are victims of Fake Agile, I extend my deepest sympathies. “Agile” ruined your life only in that it provided an all-too-glib buzzword for your organization and management to latch onto. I dearly hope that you’re able to experience real Agile: frequent delivery of value at a sustainable pace while adapting to the changing needs of the business.

Actually, maybe you already had experienced Agile, but your clueless management screwed it up by initiating an “Agile Transition” with so-called Agile Consultants or Coaches who dictated and enforced cumbersome variations on Agile practices in a sad command-and-control parody of Agile with theĀ  ironic result of decreased communication, collaboration, visibility, feedback, and alignment. For you, I hope you can escape the nightmare and find a healthier organization.

But there’s a second pattern of responses that I find both disturbing and fascinating. The responses in this category do not appear to be motivated by a misunderstanding of Agile, but rather are attacks on Agile practices: standups, pairing, collaborative teams, open team rooms, and the like.

At the mild end of the range in this second pattern are people who object to being “interrupted” by meetings or derailed by having to collaborate with others.

I suspect that some of these folks are introverts working with a whole passel of extroverts who took to the social nature of Agile like ducks to water. Introverts need time and space to process stuff internally. If they don’t get enough time to themselves during the workday, they burn out. If this sounds like you, I hope that instead of seeing Agile practices as evil you can work with your team to achieve a workable balance of collaboration time and alone time.

At the more extreme end of this second pattern, however, the comments get nasty. Some refer to the business stakeholders as idiots, use dismissive labels like “bean counters,” and decry the work of other “crappy programmers” that they have to clean up after. These aren’t just attacks on Agile, they’re attacks on people.

Perhaps some of these comments come from good people who have been in toxic environments too long. I want to give everyone the benefit of the doubt.

But I think that at least some of these folks have a vested interest in the status quo. They liked the old way of working because it allowed them be the magicians behind the curtain. No one knew what they did or how they did it. They could pick and choose the work they liked.

These are the folks who think they are at their most productive behind a closed door, headphones on, music blaring, being “Programmer Man” (or woman, as the case may be). They dismiss requests for help with an airy wave of their hand and a distracted, “RTFM.” They think Dogbert is right about just about everything and they resent being stuck working with a whole pack of Wallys. They like to work from 3PM to 1AM because those are their best hours: things are quiet and they’re not interrupted. They write what they want, the way they want to, without concern for what the business stakeholders asked for.

Many of these people are undeniably brilliant. They produce more code—working code, even—in an afternoon than an average programmer can write in a month. And it may even be beautiful code, too. Well-factored. Clean. Really good stuff.

And yet these folks are not nearly as effective as they think they are.

Their code might be elegant, but because they dismiss Product Managers and BAs as “idiots,” their code doesn’t do what the business actually needed.

Even if their code does do what the business needed, the fact that it was created in isolation means that doesn’t play well with the rest of the system. So it takes weeks to integrate and test it. These brilliant programmers, self-satisfied with their own competence, drastically discount the work required to turn raw code into something that has business value. They blame everyone else for long integration cycles, unable to see their own hand in the mess.

And even if their code works within the context of the rest of the system, the organization is frequently bottlenecked through them because they’ve decided to take on the mantle of the hero.

For these folks, Agile represents loss. A forcible expulsion from their comfort zone of darkened offices with closed doors and noise canceling headphones. The loss of autonomy afforded by opaque processes. The loss of sovereignty over “their” code.

And so I wonder if perhaps at least some of the current backlash is offered by those who are being forced out of their self-imposed isolation, into an open team culture. It feels like a crisis to them. It may even feel like Agile is ruining their lives. But as Jerry Weinberg says, “it’s not a crisis; it’s the end of an illusion.” In this case I think it’s the end of the illusion that they were the best because they cranked out more code than anyone else. Or the illusion that all that teamwork stuff is a bunch of fluffy nonsense and not nearly as important as the technical heavy lifting they do.

The truth is that creating even a modestly complex software system is of necessity a social activity, a team sport. It is not enough to be brilliant. It never was. Effective team members have social skills. They listen, collaborate, share, and contribute.

So, to the people who think Agile ruined their lives because it requires an uncomfortable level of teamwork, I say: what a marvelous learning opportunity for you. Yes, you are brilliant. But to advance as a professional, you need to be so much more than that. A deeper understanding of algorithms, OO design, or functional programming will not help you move forward further. It’s time to get on with the difficult and painful work of learning to be a good team member. Welcome to the next stage of your career.