Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Driving on Indian Roads reminds me of Software Development

I’m thrilled to be back in Bangalore. One thing I really missed in US was the craziness of driving on Bangalore roads. Everything was so systematic, there was no thrill, no excitement, no fun, I would be bored to death. The other day I started to think what did I really like about driving on Indian roads? There was something about driving here, that strikes a chord with the way I work [you would have guess by know, .i.e. develop software]. I concluded that, driving on Indian roads have a lot to do with the way I build/develop software .i.e. using Agile methods. Here are my initial thoughts why I think so…

  • Chaos from outside : If you are not driving on Indian roads, it looks like the epicenter of chaos and noise. It will take a while for you to figure out why the traffic on the roads are oriented in 360 degrees. Everyone seems to be honking at each other. If you talk to someone who has watched an Agile team work for a week, they can share similar thoughts about chaos and noise. Companies where I have tried to introduce Agile, chaos and noise seems to be one of their top concerns. Once you are part of the system, life is wonderful. Trust me, you will never look back again.
  • Embrace change : If you drive though a street and come back to it a week later, there is a high probability that the direction in which the traffic flows would be reversed. Changing the directions of one-ways is very common here. Driving 2 wheels with helmets on is another rule that has changed at least 10 times in the last few years. There is a constant evolution. The good thing is folks embrace change and continue with it. Strikes a chord with what happened yesterday during your planning meeting?
  • Heavy emphasis on open communication and continuous feedback : If you watch people in India drive, you might wonder why they honk continuously and sometimes flash their headlights? Well, that’s our way of communication and feedback. If you watch carefully, the intensity of honking and the frequency of flashing lights varies depending on what one driver is trying to communicate to the other. A gentle honk, means, I’m about to overtake you, watch out. Continuous honking means, move out of my way, you are wasting my time. A gentle flash of light means watch out, I’m behind out. All of us know the importance of open communication and continuous feedback on software projects.
  • Self organized : If you look at the traffic rules in India, we are not so rigid about the rules. You will find people overtaking from left and right. Sometimes you’ll find group of vehicles jumping the lights when the opposite side is empty. We don’t even have cops standing everywhere with Speed guns. A lot of busy junctions, don’t have cops. People nicely self organize and move on. I believe in self organized teams and I think that is the most effective and scalable way to build software.
  • Adaptive planning : Its quite common to find one of the roads in your route blocked due to some maintenance work or accident. It very rare you’ll find people waiting for it to clear up. Immediately people find another route and move on. We plan to deliver and not deliver to a plan. Its very rare to find that everything on a software project going according to the plan. Things change, we always have surprises and we learn to adapt and move one. Also note that let it be heavy rains, floods or heavy winds, none of these seem to bring the traffic to a standstill. People adapt and move on.
  • Stressful and Intense : No doubt driving is a lot of fun, but driving on Indian roads is stressful and can be intense. This is the same feedback I get from people who work on Agile projects. Pair programming session can be quite stressful and intense. Trust me, you’ll feel much more exhausted in 4 hours of pair programming session compared to 10 hours of working on your own. Both of these activities needs a lot of attention and can drain you out soon.
  • Mitigate risk : From outside, it might feel like driving on Indian roads is very risky. But if you look at the number of deaths caused due to accidents in India, its far less than that caused in US. Please note that number of deaths includes humans and animals. For those who live in suburbs in US, can tell you how many deers they find dead everyday. The trick is with people traveling so close to each other, there are very little chances to be caught by surprise. With constant feedback and continuous collaboration on Agile projects we try to mitigate a lot of project risks. Pair programming and collective ownership is another great way of mitigating the risk of one person being the bottlenecks.
  • Maximize the throughput : If you notice the number of people that travel through these roads each day, its amazing. Look at the roads, every inch of the road is occupied and sometimes we don’t even spare the footpaths. We like to maximize the usage of the available resources (capacity utilization). But at the same time we focus on making sure we reach home/office fast. (throughput). Every software project tries to maximize its throughput and Agile gives me a great platform to do so.
  • Minimize the operating cost : I’m not too sure, but my gut feel says the amount of money and effort invested in maintaining and building roads in India is far less than what they do in other countries like US. Also consider the ratio of number of cops to the number of people traveling through these roads; it is very very small. We believe in reducing any form of overhead ;) This is the harsh reality of software projects. But Agile helps me strike a good balance.
  • Agility [the verb] : With the short distance between the vehicles, one needs to have really good reflexes to survive on Indian roads. Its amazing to see everyone jamming their brakes when something unexpected happens. They recover and move on. Being Agile [verb] is the key to success on a software project.

Having said all this, its always easy to find things that are done quite different in these 2 scenarios. Taking any analogy to an extreme causes more harm than good.

  • Jagadish

    Consider the bottlenecks caused by drivers who do not stop for the flow in the other direction to complete and start nosing into the flow. Eventually this causes a logjam and ensures that traffic does not flow in any direction. A clear reflection of “self thinking” as opposed to systemic thinking. Do you see a similar danger in Agile if there is no overall vision or architecture roadmap and teams are busy working iteration on iteration but not going anywhere?

    You need to differentiate throughput and utilization. Throughput is the flow or speed at which you move from one end to the other in a system. While there is no doubt Indian roads are packed to the limits (utilization), it does not necessarily mean the thruput is high. You can compare a 10 km journey (eg: to EC) taking 45 min with an equivalent journey in the US. From a Lean or Agile perspective it is the flow rate or throughput which is important and not the utilization.

  • Jagadish

    Consider the bottlenecks caused by drivers who do not stop for the flow in the other direction to complete and start nosing into the flow. Eventually this causes a logjam and ensures that traffic does not flow in any direction. A clear reflection of “self thinking” as opposed to systemic thinking. Do you see a similar danger in Agile if there is no overall vision or architecture roadmap and teams are busy working iteration on iteration but not going anywhere?

    You need to differentiate throughput and utilization. Throughput is the flow or speed at which you move from one end to the other in a system. While there is no doubt Indian roads are packed to the limits (utilization), it does not necessarily mean the thruput is high. You can compare a 10 km journey (eg: to EC) taking 45 min with an equivalent journey in the US. From a Lean or Agile perspective it is the flow rate or throughput which is important and not the utilization.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Those are some really excellent points. Thanks.

    My response:

    >> Do you see a similar danger in Agile if there is no overall vision or architecture roadmap and teams are busy working iteration on iteration but not going anywhere?

    It would be unfair to say that it might not be possible. A lot of time Agile and XP in particular, is accused of “Missing the forest for the tree”. But we need to think if this is because of the process or because of the team.

    So far in my experience I have not seen this happen. With such heavy focus on short releases and quick feedback from customer, I find it difficult how people can be working on iterations but not going anywhere. If that happens, I would think, the customer role is not being effective.

    XP had a practice called Metaphor, which has helped me a lot to make sure every one has the vision both functionally and Architecturally.

    I would even go to the extend of saying that in a tradition waterfall process, since the feedback cycles are so long and people are working in isolation, the chances of missing the forest for a tree is might higher.

    >> You need to differentiate throughput and utilization.

    Sure. While I completely agree with your definition of throughput. I was thinking more from the number of people that travel thru these roads each day as a measure for throughput. So if you think about the business value delivered by the roads, it is important to measure how fast you travel on the road, but it is also important to measure how many people can travel thru them at any given point in time.

    From Toyota’s point of view 100% utilization is not very good. They talk about slack. Which means if the machines are utilized at around 80%, the throughput is high, coz the waiting time is low.

    Trying to take the same principle to roads, I can see how 100% utilization can affect the throughput.

    We know that 1/throughput = velocity. Both in manufacturing and software, velocity can give you an accurate measure of how many units are delivered per unit time. So we always want to increase velocity and decrease throughput time.

    I’m not too sure if this can similarly applied to Roads.

    Ex:
    Scenario 1: On an average , it takes on an average one person 30 mins to travel from point A to point B. At any given point in time, only 2 people can travel thru the road.
    Scenario 2: On an average , it takes one person 60 mins to travel from point A to point B. At any given point in time, 10 people can travel thru the road.

    Scenario 1 seems ideal. But what happens when you have a million people waiting to travel? I would assume Scenario 2 is better than scenario 1.

    That’s really what I was trying to get at. But you are correct we cannot apply this to software, coz we don’t have a million features ready to go.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Those are some really excellent points. Thanks.

    My response:

    >> Do you see a similar danger in Agile if there is no overall vision or architecture roadmap and teams are busy working iteration on iteration but not going anywhere?

    It would be unfair to say that it might not be possible. A lot of time Agile and XP in particular, is accused of “Missing the forest for the tree”. But we need to think if this is because of the process or because of the team.

    So far in my experience I have not seen this happen. With such heavy focus on short releases and quick feedback from customer, I find it difficult how people can be working on iterations but not going anywhere. If that happens, I would think, the customer role is not being effective.

    XP had a practice called Metaphor, which has helped me a lot to make sure every one has the vision both functionally and Architecturally.

    I would even go to the extend of saying that in a tradition waterfall process, since the feedback cycles are so long and people are working in isolation, the chances of missing the forest for a tree is might higher.

    >> You need to differentiate throughput and utilization.

    Sure. While I completely agree with your definition of throughput. I was thinking more from the number of people that travel thru these roads each day as a measure for throughput. So if you think about the business value delivered by the roads, it is important to measure how fast you travel on the road, but it is also important to measure how many people can travel thru them at any given point in time.

    From Toyota’s point of view 100% utilization is not very good. They talk about slack. Which means if the machines are utilized at around 80%, the throughput is high, coz the waiting time is low.

    Trying to take the same principle to roads, I can see how 100% utilization can affect the throughput.

    We know that 1/throughput = velocity. Both in manufacturing and software, velocity can give you an accurate measure of how many units are delivered per unit time. So we always want to increase velocity and decrease throughput time.

    I’m not too sure if this can similarly applied to Roads.

    Ex:
    Scenario 1: On an average , it takes on an average one person 30 mins to travel from point A to point B. At any given point in time, only 2 people can travel thru the road.
    Scenario 2: On an average , it takes one person 60 mins to travel from point A to point B. At any given point in time, 10 people can travel thru the road.

    Scenario 1 seems ideal. But what happens when you have a million people waiting to travel? I would assume Scenario 2 is better than scenario 1.

    That’s really what I was trying to get at. But you are correct we cannot apply this to software, coz we don’t have a million features ready to go.


    Licensed under
Creative Commons License