Driving Self-Organization

July 8, 2015

Bangalore Traffic

“Too bad the only people who know how to run the country are busy driving cabs and cutting hair.”

-George Burns

I learned to drive in Southern California. I’ve always been kind of proud of that fact. Driving in the southern land of pavement and potholes requires a special kind of aggressive driving in order to survive the freeway melee. You have to learn to barge into a lane when there isn’t any room, to turn left on a light after it turns red, to tailgate in order to keep others from cutting you off. That’s quite a litany of questionable driving practices. All in a typical day of driving in Cali. Don’t mess with me, I’m an expert.

That’s what I thought before I went to India.

Driving in a taxi in India was an eye opening experience. Silly little conventions like lanes are completely ignored. The entire road, from sidewalk to sidewalk, is your vehicular playground. Driving the wrong way into oncoming traffic is a matter of habit – how else would you get where you are going? I tried to count the number of times I was nearly in a head on collision, but I gave up – partly because I lost count, and (maybe) because I was distracted by my own screaming.

Don’t get me wrong: I was in complete and utter admiration. The level of self-organization and complexity was breathtaking! With what appeared to be a complete absence of rules, people managed to get to and from work every day amidst what appeared to be complete chaos. I very quickly resolved to never lecture anyone on the merits of self-organization ever again! Why? Because apparently I’m an amateur. If you want a lesson in professional level self-organization, don’t talk to me. Talk to a taxi driver in Bangalore.

Someone asked me if I thought I could drive in that traffic. My answer was yes, but not because I think I’m good. Quite the opposite in fact. The Indian driving system appeared to be remarkably tolerant of incompetence. The traffic ebbed and flowed around complete bumbling dolts with apparent ease. Contrast that with where I live in Seattle: one idiot in the left lane can shut down an entire freeway for hours.

Each day in India, I took a one hour commute to and from the office through complete chaos. We circumvented obstacles that would have shut down a US freeway for hours. The creativity on display was dazzling. And as an added bonus, I was thankful to be alive when I arrived at my destination!

Compare that to my commute in the US. Everyone lines up uniformly. We stay in our lanes. Creativity is discouraged. It’s not very exciting. My commute at home also takes an hour. It made me wonder: which system is more efficient?

Under what conditions is a system with fewer rules faster than a system with relatively rigid rules? It was tempting to look at the Bangalore traffic and speculate that perhaps it was faster in some ways. It was certainly more exciting (especially after a few beers late at night in an auto-rickshaw). However, a certain level of orderliness also has its benefits.

I find myself on my own humble commute now, cars stacked up in nice, orderly lines behind an endless parade of red tail lights – and I wonder, “What if we had fewer rules?”


Punctuated Disequilibrium

August 22, 2011

I’ve heard people talk about the gradual gains that agile teams make over time as they engage with continuous improvement, but I’m here to tell you that isn’t what I see in the real world. I guess the expectation (perhaps my own included) is that when teams start to improve they will make many small changes over time and reap corresponding gains in performance. You know, a little change here, a little gain there. I guess I envision it looking a little like this:

However, I see something different. What I’m witnessing with the teams that I work with appears nothing like that. Instead the teams seem go for long periods with no evident change in performance or productivity. They just seem to trundle right along and then BANG! You see a dramatic improvement. It sort of looks like this:

The team is trying out different things the whole time. They’re failing at some things and succeeding at others. They are continuously playing with the chemistry set we call Agile Development. From the outside you don’t see much happening. Sometimes for long stretches of time – we’re talking years here. The point is that my experience is that often, it’s a combination of many things that leads to significant performance gains by a team. Finding that combination of what works can take a while. But when it does happen, it is reflected in a rather dramatic improvement in performance. It’s not a slow gradual change.

Of course there is a flip side to this change. Here’s another example:

Some teams that I’ve worked with have made great gains and then “jumped off the cliff.” What goes up can come down. I call this “Tom’s First Law of Team Performance”. Just as there is sudden improvement, there can be an equally sudden decrease in performance. Team’s can make a change that kills performance just as easily as they make a change that improves it. I’ve seen it work both ways. Sometimes it is change outside the team, within the corporate culture at large that causes these radical swings in performance. Software teams work in a complex ecosystem. When change happens, I think it tends to either be suppressed by the system or, when the conditions are just right, lead to dramatic changes in performance.

Bringing Performance to Light

March 27, 2010

In the Tipping Point, Malcolm Gladwell talks about a phenomenon called Fundamental Attribution Error. Basically, FAE is attributing success to the wrong things. His point was that we often fail to take context into account when making judgments. He gave an example of a study where subjects were asked to judge the performance of two basketball teams, one playing in a darkened auditorium and the other under normal lighting conditions. The subjects were asked, which team is better? The answer: the team in the well lit auditorium of course.

The only difference between the two teams was the context (lit vs. unlit). Both teams were equally skilled, but the team playing in the dark missed many more shots. That led me to ask myself, “Is my team playing in the dark?”

The context that software development teams work in has a profound affect on how they perform. I’m not just talking about physical context, but also the culture, the technology, and even their social context. I suspect that there are many fantastic teams that are working “in the dark”. It’s our job to turn on the lights.