In a 2003 InfoWorld story on the globalization of software development I asked Andy Singleton to share his thoughts on distributed software development. He has continued to refine and reflect on his approach, which he says is inspired by the open source, agile, and web 2.0 movements. On this week’s Innovators podcast, Andy summarizes the often counter-intuitive methods that work well for him and his teams. They include:
Don’t interview. Just pay people to join a project, pull a task from the queue, and find out what they can do.
Don’t divide work geographically. You’re not making best use of your distributed team if you impose that artificial constraint.
Don’t do phone conference calls. “I’ve never had someone tell me: ‘I worked on a project with lots of conference calls, and it worked great, so your thesis is disproved.'”
Don’t estimate. It’s just extra work. If you know your tasks and priorities, go after them in order. Estimation won’t help, and will cost 10% of your time.
Pile on developers early. It enables people to self-sort, and yields a stronger and more flexible team at the two-week mark.
Ironically, Andy says, many proponents of agile software development resist the notion of distributed development:
They think everybody should meet once a day. That’s such a cop-out! Since most development nowadays is distributed, they’re saying that 90% of the people who should be taking advantage of agile methodologies can’t do it. What they really should be doing is figuring out how to make distributed teams at least as productive as colocated teams. And in our case, we believe they’re more productive because we’re bringing in better talent.
One of the key enablers of effective distributed work is a common event stream to which everyone can subscribe. To that end, the Assembla website has embraced web hooks. So, for example, the action of committing code to a repository implicitly fires an event. You can make that explicit by wiring the event to an action, like sending a Twitter direct message.
This is a really important idea. Today, most of the services that you’d like to weave together to enhance distributed teamwork don’t export event hooks. But it’s quite simple to do. Here’s how Assembla enables you to relay events to Basecamp:
It takes two to do this tango. The external system, in this case Basecamp, has to be prepared to catch an incoming REST call. And Assembla has to enable its users to wire internal events to outbound REST calls.
Neither requirement is difficult. And the payoff can go way beyond the basic pub/sub notification scenario shown here, as noted in the Web Hooks blog:
Thanks to CGI we got the read-write web, but we also made the web way more useful than it was intended. Suddenly browsing to a URL would run some code. And code…well, code can do anything.
Yes. That said, simple notification is nothing to sneeze at. That alone, widely implemented, would be a game changer.
Very cool stuff; particularly the webhooks. However, you’re post seems to be duplicated in the body as if you are echoing yourself.
Though, I suppose the points are all worth repeating!
Hmm. Double vision happening here…
Oops. Fixed. Thanks!
It doesn’t require two to do this tango if you can write code. Basecamp or any service doesn’t have to accept POSTs from services providing web hooks… users can write handlers that use the existing API for Basecamp or what have you to do the deed.
> users can write handlers that use the
> existing API for Basecamp
Sure. But my point is: Basecamp /has/ APIs. Many systems do not have them, or at least don’t have ones tuned for these kinds of interactions.
we’ve got a team all over the place, australia, uk, san diego, and montreal. we do a once-a-week 30 min conf call, with a set/strict agenda. I find it very useful to keep everyone up to date on what others are doing.
It would be particularly interesting to have a conversation of this sort that reflects on schedules and business goals.
Agile can be done remotely… daily standups are an expression of a communication need and a blockage management system, not a physically bound necessity. In fact, the ten minute rule is focused on getting people out of the room, and thus distributed, as fast as possible so they can get back to their tasks.
I like this approach and think it can work in certain contexts. I like the interview by capability rather than inquisition.
Andy, would love to chat further if you’re interested.
Jan Drake
Serial Software Entrepreneur
This was a great show, but there was one question that I wish you had asked Andy. He was so unenthusiastic about any kind of synchronous discussion, whether by conference call or video link. My question is: Are these asynchronous systems so effective that even people in adjacent offices stop talking about work together?
If face-to-face discussions are valuable at all, then maybe we just don’t have the right kind of synchronous connections, because of bandwidth or bad design or some other thing. But maybe these systems are demonstrating that face-to-face discussion is overrated even when it’s cheap due to co-location.
I am enthusiastic about chat. We do a lot of chat, all day, every day.
I like the other stuff, and I use it personally, but I don’t see teams picking it up.
I am not enthusiastic about audio, video, conference calls, and screen sharing, because I never see people using them. Those are things that have had many launches by many people for many reasons over many years. It’s hard to believe that after all of these tries, the problem is that it’s not the “right kind of synchronous connection.” The market has spoken.
In the case of online audio / video / screen sharing, they are really only used for 1-many presentations, or 1-1 (video calls). You never see many to many (team). In the case of conference calls there is a clear association with low productivity.
I’m not sure why that is true.
Chat all the time, screen-sharing on demand, weekly meetings. Skipping the interview is too radical and there is something to be said about skipping the estimate. Although both of these concepts will be unacceptable to the PM and team manager who get the fuzzy-warm from “agile.”