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?”

Advertisements

You Can’t Break it Down Until You Understand it

July 7, 2015

sea-beach-boat-grass

“Furious activity is no substitute for understanding”

– H. H. Williams

One of the first things that agile or iterative development demands of us is that we should break down our work into very small chunks. This challenge is one of the first hurdles faced by teams that are adopting sprints and trying to make all of their work fit into a tiny little 2 week time box. I’ve seen it over and over again. The first question folks ask is, “How can I break this down into pieces small enough to fit in the sprint?” My response, inadequate though it may be, is some variation on, “It’s not hard. People do it every day.” I know – not the best answer. I often get reactions that range anywhere from frank denial to outright disbelief. It just can’t be done!

I know. I get it. I really get it. If you aren’t used to it, the first time you deal with breaking work down into tiny chunks is like running into a cognitive wall. I remember the first iterative project that I did. I understood the model. The concepts made sense: break things down into small chunks and then iterate. Easy.

Only it wasn’t easy at all.

I remember sitting in front of my monitor thinking, “What meaningful piece of functionality could we do in a sprint?”

Nothing came to mind. I drew a total blank.

It was dreadful. We were working on a new product, something completely new to the market…and I had no idea what I was doing. We had no clue. That’s not to say that we were incompetent. Far from it. We all knew that we didn’t know much, and that was a big problem. Fortunately, we overcame those challenges. Unfortunately, like many people, I conveniently forgot most of those lessons and moved on.

I had another reminder the other day. I was working on the boat I’ve been building. So much of building a boat early on was big intimidating chunks of work. I had no idea what I was getting into. Everything seemed daunting. Weeks of effort. However, after 3 years of working on it in my garage, I now find myself doing something completely different. Now I can wander out and create a long list of tiny tasks quickly and spontaneously. I know much more now. I can see hundreds of little tasks that need to be done. Little stuff, literally just a few minutes of work.

So I didn’t know what I was doing when I started, but I learned, and as I learned I was able to break things down. So how did I learn? By getting started and making mistakes. Lots of mistakes. Sometimes I think mistakes are the only thing I’m good at. So now when people ask how to break things down, maybe my answer is, “Just get started, the answer will come to you as you learn the problem domain.”

Of course, if that fails, you can always take up boat building.