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

If you can’t get Distributed Development working, your company is doomed!

Today Distributed Development is unavoidable and is the need of the hour.

My belief is that if you have the “right” set of people, motivated and happy on your team, it will be a huge contribution to the success of the project. But the problem is most often “right” people are distributed all over the world and not located in the same city. A lot of organizations have tried to move people to the same city so that they can be collocated. While this might work to some extent, this model cannot scale and is not sustainable. All of us would like to settle down in the location of our choice. We don’t want our work to dictate where we live and what lifestyle we choose. For example, I like to live in India close to friends and family. So far I have traveled quite a bit, but once my daughter starts going to school it would be very difficult for me to relocate to another city.

Also if you consider a lot of leading companies they are loosing a huge amount of people, because most of those employees don’t want to travel/commute any more and want to settle down in one place. While tele-porting is a few centuries away, employees have to live with stressful commute everyday. Not only this is a huge wastage of time, it also affects your productivity and makes your family life very stressful. Currently most of the successful companies have offices in multiple cities. One of the main drivers for having multiple office in different cities is to attract local talent. If your company does not plan to have a office in location X, guess what, your competitors will open an office and you’ll loose some of the smartest folks you could have other wise hired. And when you have multiple office, guess what, people in different offices have to work together. This is another reason why distributed development is becoming more and more important.

In Agile we talk about having development and business teams together. It is very critical to have constant business involvement. But what do you do when your Business is distributed? Because of the global economy most businesses have global presence.  Also each region might have slightly different business rules or market. Hence it is very important to have development teams close to local businesses and distributed. This again leads to distributed development.

Another point to be aware of is, if we consider what industrialization has done by building power centers in industrial cities leaving the rest of the country really backward. We don’t really want IT to do the same thing to the country’s economy.

If you consider these practical issue, collocated team model turns out to be unrealistic in the long run. The chances are you will have to compromise on the quality of people or have the team members travel a lot if you want all of them to be collocated. The alternative is to build a model where the team members can be distributed across space and time.

Unfortunately so far, we’ve not had great results with distributed development. A lot of people have published their experiences trying to effectively work in distributed teams. For some it has worked or some it has not. But for most of them its not as effective as collocated teams.

What has worked best of me so far is to start off a team by having them collocated for a couple of week to a month. Then created cross-functional self sufficient teams in each distributed location. Once this model seems to work, then try to fully distribute your team with team members spread all the world. This turns out to be a long and painful process. But this is the best I know of today. Check out my presentation on Distributed Agile which I gave at the IV Agile Gathering in Ukraine.

Next year I plan to kick off a few experimental distributed projects to try out different techniques to get Distributed Development work as effectively or may be even better than collocated teams.

  • Israel Antezana R.

    If you would like to try some distributed project with Bolivia next year let me know I would be happy to do the experiment with you.

  • Israel Antezana R.

    If you would like to try some distributed project with Bolivia next year let me know I would be happy to do the experiment with you.

  • Madhusudhan

    Hi Naresh, You think Fitnesse Acceptance test concept can be used as a collaboration tool between distributed teams? So Team A in location P can write a failing Acceptance test that Team B in location Q can write code and fix. By doing so the 2 teams are not required to colocate and yet are communicating well(set and get expectations cleared). After all Agile core is to ease out communication apart from other objectives.

  • Madhusudhan

    Hi Naresh, You think Fitnesse Acceptance test concept can be used as a collaboration tool between distributed teams? So Team A in location P can write a failing Acceptance test that Team B in location Q can write code and fix. By doing so the 2 teams are not required to colocate and yet are communicating well(set and get expectations cleared). After all Agile core is to ease out communication apart from other objectives.

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

    Madhu, I think it can help, but I don’t think it would solve the problem. Also personally I don’t believe having Business Expert on one side and having development and testing on the other side will work well. I would rather prefer having two cross-functional self-sufficient teams in each location.

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

    Madhu, I think it can help, but I don’t think it would solve the problem. Also personally I don’t believe having Business Expert on one side and having development and testing on the other side will work well. I would rather prefer having two cross-functional self-sufficient teams in each location.

  • http://www.clifftop.us/ Ellen Feaheny

    I completely agree with your article – for more reasons than one.

    The most successful projects/teams that I have been on in my career have been distributed environments – with stakeholders from opposite sides of the country and/or international. And I have been on alot.

    I don’t think I thought too much about it when I was on those teams, but as a consultant (myself and others), doing whatever it takes is standard course – you just do it, with determination to make everything work as best possible – pushing the tools (of the day), pushing technology (of the day), pushing communication, and make the distance disappear. As senior consultants, you are expected to act this way – just make it happen.

    In the last 5 years especially, this has gotten easier and easier – with great tools to make it a lot easier!

    (In fact, I marvel at some of the pain we put ourselves through at times just to make it work – but STILL, the teamwork was better, it seemed.)

    In reflecting on this now, I think it is ironic that in the less distributed teams – all in same office, for example, things were a lot less efficient. People didn’t push things as much to be efficient and self-sufficient.

    Communication also often was worse – people didn’t write things down as much – verbally repeating same things again and again, or relying on meetings (with notes often not taken), and using inefficient email attachment methods, for example, rather than a shared server or source control repository, collaborative platform, or project management task tracking system.

    Seems like simple stuff. This is why I like Agile ways (done right) so much – by nature, it forces the issues, it forces collaboration, it breaks code faster (to be fixed faster), it breaks departmental walls, it forces issues to the surface – as a team, in the system, not finger pointing (again assuming, if done well).

  • http://www.clifftop.us Ellen Feaheny

    I completely agree with your article – for more reasons than one.

    The most successful projects/teams that I have been on in my career have been distributed environments – with stakeholders from opposite sides of the country and/or international. And I have been on alot.

    I don’t think I thought too much about it when I was on those teams, but as a consultant (myself and others), doing whatever it takes is standard course – you just do it, with determination to make everything work as best possible – pushing the tools (of the day), pushing technology (of the day), pushing communication, and make the distance disappear. As senior consultants, you are expected to act this way – just make it happen.

    In the last 5 years especially, this has gotten easier and easier – with great tools to make it a lot easier!

    (In fact, I marvel at some of the pain we put ourselves through at times just to make it work – but STILL, the teamwork was better, it seemed.)

    In reflecting on this now, I think it is ironic that in the less distributed teams – all in same office, for example, things were a lot less efficient. People didn’t push things as much to be efficient and self-sufficient.

    Communication also often was worse – people didn’t write things down as much – verbally repeating same things again and again, or relying on meetings (with notes often not taken), and using inefficient email attachment methods, for example, rather than a shared server or source control repository, collaborative platform, or project management task tracking system.

    Seems like simple stuff. This is why I like Agile ways (done right) so much – by nature, it forces the issues, it forces collaboration, it breaks code faster (to be fixed faster), it breaks departmental walls, it forces issues to the surface – as a team, in the system, not finger pointing (again assuming, if done well).


    Licensed under
Creative Commons License