Full Distributed Teams: are they viable?(pixelmonkey.org) |
Full Distributed Teams: are they viable?(pixelmonkey.org) |
My guess is that everyone in the office was discussing bits and pieces outside the chat room and neglecting to keep me in the loop, perhaps unknowingly. Later on they decided to have formal weekly meetings, but this didn't really improve the situation.
37 Signals described how they worked around this problem by forcing employees at the parent office to work from home more often, see http://37signals.com/svn/posts/2360-equality-and-remote-team...
There are numerous instances, including very large projects with multiple developers (Apache, Linux kernel, Debian project) in which this works quite well, and arguably several in which it doesn't (I suspect some of the desktop fails of GNOME and KDE have a lot to do with an insular psychology emerging among the development communities).
There've even been academic studies of the groups, including those by Biella Coleman (University of Chicago / Columbia), Siobhan O'Mahoney (Stanford/HBS). Steve Weber's The Success of Open Source nails a few of the dynamics pretty well too, though with less focus on actual teams (http://books.google.com/books/about/The_Success_of_Open_Sour...).
That said: many FS projects are highly modularized, an in particular, kernel development happens in large part by professionals paid to work at a given company on some aspect of kernel development. So the model is very mixed.
My own experience: maturity, individual dedication, group dynamics, and the absence of a "mothership" (and concomitant us-vs-the-world mentalities), as well as a dedicated effort to keep all communications on the group channel (as opposed to meatspace) is critical to success.
It's a mixed bag. You really lose a lot not having physical interaction with your teammates (except the once or twice a year you happen to fly everyone to the same place). It's a lot easier to get on each other's nerves when you're not face-to-face. Management of people becomes a lot more difficult because of the disconnect of discussion over Skype or chat.
On the other hand, you can handle a lot more stress and workload by not having to worry about the commute and office hours. Sleep is easy to catch up on, even in the busy times. It's a lot easier to do things like taking a walk or grabbing a coffee down the street to clear your head - far less social pressure against taking a needed break than you'd see at the office. It's also a lot easier to thread in events in your life.
Ease of hiring is probably the big benefit with fully distributed teams. You have access to talent all across North America, and if you don't mind the timezone differences you can pick up people anywhere worldwide.
i love it. now back to work :o)
Someone might be a competent developer in their own right, but not a ninjarocksuperstar. Still, if that person can understand three conflicting ninjarocksuperstars' points of view and see how to reconcile them and build a consensus, it might be the most valuable contribution of anyone on the team that day.
One of the problems with managing something like a software project is that it's very hard to measure this effect. If you're in an office where people are interacting regularly, there's usually an easy alternative to measurement: ask everyone who helped them do their job the most lately, and the guy that 75% of your team name is the quiet one who works in the background to keep everything ticking over. If everyone is 100% distributed, that guy might not be contributing at the same level as everyone else, but that's because you're not taking advantage of his skills and your team is weaker for it, which is your mistake and not his.
(I try to be consensus guy regardless of coding skill, but I'm not sure how good I am at it. That's why appreciate when there is someone who really is good at it on the team, even if their personal coding skills are merely average.)
Speaking from experience on both sides of that coin (currently the remote-side). It stinks. Communication incentives are out of wack. Remote people feel isolated and missing out on conversations, whether needed for a project or just missing out on camaraderie. Co-located people feel the distance of the remote people, and they either make conscious inefficient communication choices to include them or continue with the confortable in-person efficient choices.
It's hard work to have a minority of your workforce remote. I believe that if the balance tips the other way, remote communication and coordination gets easier and more streamlined. Even if it's not fully remote or separate co-located teams.
This is actually a big issue for us right now. Being a small startup in Nashville, there isn't exactly a lot of easily accessible space for us. We have to leave where we are at right now, and are trying to figure out what our plan off attack is going to be for the next few months.
The distributed model seems to be working the best. We are a truly distributed company. I felt kind'o self conscious when someone would ask where our offices are. But now, I realize, we get stuff done! The team just works, and works far more efficiently than any team I've been part of before.
Granted, 10 out of 12 of us are introverts. I think there's something even better at work. Everyone shows up and does what needs to be done when it's convenient for them, we don't really have "politics" since nobody spends a significant amount of time chitchatting by the proverbial "watercooler" etc.
It's really a very unique culture. We're far apart, but we know each other thru our work and we take quite a bit of pride in our work. There are several serious shortcomings though.
So far, I haven't seen a tool that was quite up to the task of keeping the team cohesive as one unified team.
We started out using Trello (which I still think is amazing), but as we grew to past 5 people and multiple projects, trello quickly became a mess (maybe due to how we're using it). We do rely heavily on skype and dropbox.
We recently switched to TeamLab, which is pretty awesome given all the features,but it's still not right...
I wish I could just extend trello, add some wiki/blogging functionality to it and drastically improve the search.
So, I'm contending that there probably isn't any tool out there specifically directed at a distributed teams. If there's one out there that works well for you, please share... At this point we've decided to roll our own given the time and collective energy we're already spent trying to learn and implement some of the existing tools.
(BTW, our team's not specifically developers, we range from business types to designers, writers and Coders)
To be honest being out of band isn't too bad, we've always got someone working around the clock, so it feels like we're always moving along.
It isn't a project management tool (lots of good ones already exist), but it is a great discussion tool. Our remote team is closer together because of it.
If you try it out, we'd love to hear your thoughts, feedback@gingerhq.com.
http://oduinn.com/blog/2012/04/04/we-are-all-remoties/
IRC and video chat are two critical components for Mozilla's teams.
I currently work on a team of 12, in three countries and at least seven cities.
Anyone who says otherwise is a sales man trying to flog video conferenceing gear or deluding themselves.
This is based on many years experience and the common factor for good projects was a team that meshed well and was in the same office.
I'm a remote worker, so I have switched to tmux + console emacs (some guys prefer vim). That works much better than ScreenSharing and a typical GUI editor.
I've checked out wemux, but it didn't solve my pain-point which was the ssh setup at the remote end.
The bigger deal is not whether your team has the tools. But whether they use the tools. Co-located people may talk in campfire/irc/group chat, and some may not even log in. But remote workers depend on it.
Next most used communication method are internal P2s - http://p2theme.com/ - which is great for async communication. With people all over the world it is important to have a good async communication method.
Another reason both IRC and P2 are so important is that they have URLs for history. Anyone in the company can go back and read through the discussion.
The third communication method is Skype/Google Hangout. Many teams will have a regular (weekly is common) voice or video chat, generally less than an hour.
We have some glue tying these together and we use some in-house development wiki's and live-editing tools for producing faster and collaborating better.
Thanks for wemux; that looks really great :)
But for actual coding I've found http://pair.io (using tmux) to work fantastically; I can't wait for them to come out of private alpha.
Any important discussions happen in Ginger (https://gingerhq.com) so people can participate asynchronously (disclaimer: its a product we built).
Once a week we have an optional staff meeting that happens in Google Hangout.
For the tech side, we rely heavily on GitHub and sometimes Pivotal Tracker.
I think your comment is a recognition that the most important aspect of face-to-face time isn't actual productivity / collaboration but simply social connection and team camaraderie. This is probably the biggest challenge that Fully Distributed teams face, but it isn't insurmountable with some creativity and planning.
Since when is body language involved with getting stuff done? Or do you mean office politics and those greatly productive meeting hours?
bandwidth of communication
The lower bandwidth is more than compensated by the better signal/noise ratio.
I've found communication in remote teams to be radically more efficient than the usual office chitchat. You just don't waste time in poorly focussed meetings, adhoc exchanges that all participants have forgotten a minute later, or the infamous daily standups that give everyone the blurry feeling of being on the same page - without knowing which page that would be.
Chat is the primary communication channel in the teams that I'm participating in and the sole act of typing something out instead of saying it makes technical discussions tremendously more focussed.
It also enables a culture of meta-discussion that simply doesn't happen in old fashioned meeting-driven companies. I have many dozens of Chat-threads going on in parallel, some of which reach back months, often with long pauses. These threads contain pretty much the entire thinking that went into any given subject. Nothing is buried on funny colored post-it notes or blurry memories of long forgotten meetings.
Feel free to compare that to your "knowledge-base", "Wiki", or what have you?
certainly not viable now.
Says who?
I've been "the remote guy" exclusively for the past 5 years. For different companies, some fully distributed, some with a central office. If you want to maximize productivity of a mature team then that is your modus operandi.
While face-to-face communication is perhaps the best mechanism of communication at the moment, a centralised team has a far, far smaller pool of potential hires to draw from. It's effectively a tradeoff of communication vs. talent.
My own opinion is that communication between fully distributed teams isn't that bad, and is getting better all the time. The small advantage of having a centralised team doesn't seem worth reducing your talent pool by several orders of magnitude.
http://spectrum.ieee.org/automaton/robotics/industrial-robot...
or the texai
http://spectrum.ieee.org/automaton/robotics/robotics-softwar...
Maybe one day this will become commonplace (when they become an order of magnitude cheaper, I suspect). Meanwhile, Skype is a good idea.
What is that sorcery you are speaking of? ;)
I've found that note-taking / decision communication happens so infrequently that it's far better in the long run to just stick to logged forms of communication.
If it's a pair programming team, of course, the documentation is in the code. But if it's something architectural or changing the direction of the product/team, it's gotta be written down.