There was a highly charged discussion on real colocation vs. remote colocation on one of the mailing lists. I think the number of posts far exceeded 100+ and eventually there were more emotional and personal arguments than any meaningful real responses. Finally, the original poster left the group, people who were left on the group were in introspection + justification mode for a day, and life seems to be slowly returning back to normal on that list.

I think the discussion lost its fizz because of several reasons, but I feel most of us are still living in a denial mode as far as remote work is concerned. Just because we have Agile Principles that ‘favor’ colocation, there is no good reason to justify that as the means to colocate the teams, come what may. My argument is don’t suboptimize the whole in order to superoptimize the parts. So, if I were a carpenter on contract to build a house and only knew how to use a hammer, it would amount to me demanding that every door and window be made using only the hammer whether the house needs that or not, and whether that suboptimizes the house construction or not. I look at life this way: if you are lucky to have an ‘ideal real world’: small, colocated teams, than by all means, go Agile in its full spirit. However, if higher business imperatives make your business remotely located in multiple locations, then you can’t be pushing your tool just because that’s your comfort zone ! A customer doesn’t care what process we use internally as long as he get what he wants and when he wants at the right price point he has in mind. To a large extent, the same goes for your management also. They might recognize that you can improve your development productivity 2X (or whatever is the going rate) but let’s be honest. How much time and effort does the software phase consume in the overall product development ? Obviously that number varies depending on the type of system being built, but even in 100% software-only products, there is a reasonable (and quite often, significant) amount of time and effort that must be consumed by non-software teams. If we assume software teams are consuming 40% effort on a systems project, and by distributing work, the organization is getting a 2X improvement (without being judgemental about the type of ‘improvement’, let me just say this is a result of availability of talent at the right price point that is able to deliver the work within desired quality). Now, even if Agile practices are able to bring a comparable 2X improvement, that is probably only affecting that 40% of the development effort to become 20% but at the cost of colocating everyone which means the cost of overall project might double in the worst case, going up from 100% to 200% ! So, if that is the way an argument for supporting Agile adoption is made, I won’t be surprised if there are no takers. This ostrich mindset reminds me of the Swiss Army manual - if there is a discrepancy between map and terrain, trust the terrain.

A far better approach would be to first understand what is an organization’s constraints and expections in distributing the work to remote teams. What benefits are being expected, and are actually being accrued in reality by doing that. Once done, that is a great starting point to have the debate on how best we can make distributed teams more productive - so, it is nomore a question of pure faith vs. pagan. It is a question of what is the best way we could help teams in the given context. The idea is not to challenge why real world is so ugly and try to facelift it because the mirror won’t like it, but to accept the real world for its face value (surely, healthy debate on why it is so is always welcome in any organization) and find or make the mirror that will do best possible justice to the real world.

I once worked on a product in Digital Set-Top boxes that had teams in Belgium, Netherlands, India, Ireland and US and even though some might argue, thre was no way we could have done that project in a single location, and the major reason was not cost arbitrage alone. We all knew how difficult it would be to coordinate among so many locations, how difficult it would be to ensure that architectural integrity is maintained, interfaces stay consistent, and so on. Yes, that is real world. We were some 60+ engineers combined in all those locations. Could we go back to our company and tell, you know what, our software development process doesn’t support multisite work and we get cold sweat just thinking of what a nightmarish experience this would be - how about putting us all in a single location because that’s what we know ? Theoretically, one might do this, but I think the company has hired me not so that I could replay obvious excuses to them, but show my knowledge, skills and ability to manage complex problems like these. Precisely the reason I am in this job - if those real world problems were not there, would there be a justification for my role ? So, I would perhaps be better off doing as best a job as I can. The first thing that I might want to do is to acknowledge the real world.

That brings me to a very fundamental idea - what is real world ? is there a universal definition of real world, or is your real world different from mine ? is there a universal process that can heal all type of problems in the real world (whether there is only one real world, or multiple real worlds) ? why should we always think that a process must be macho enough to be able to solve all type of real world problems ? when no one man or woman can claim to know it all even in one domain, why is it that we want to project our process as Mr. Perfect Process that acts like a silver bullet for all types of targets ?

Which of the ‘real worlds’ does your software team live in - an ‘ideal real world’ or a ‘real real world’ ?

~ Tathagat Varma, Blog: http://managewell.net