Comment by kethinov | Hacker News Reader

Comment by kethinov | Hacker News Reader

Parent Full thread

Here is a repost of a comment I posted directly to the Ars Technica thread in reply to the author endorsing Agile/Scrum and expressing ambivalence towards telecommuting:

"That's 20th century thinking, Peter! Marshall McLuhan would be disappointed! https://www.youtube.com/watch?v=NNhRCRAL6sY

Spontaneous collaboration can happen just as effectively with a remote staff, but you have to default all your channels of communication to digital ones.

Instead of a culture of shoulder taps, use IM.

Instead of a culture of hallway conversations, get the entire team on a permanent group chat.

Skype is one of the best tools for this, so it's ironic that the company which owns it isn't making the best use of its own tools! ;)

The guys over at Basecamp did a great book recently on how to do this remote collaboration stuff right called "Remote: Office Not Required" http://37signals.com/remote

It's a great read. I read it recently while on the plane to a meeting that totally could have been over the internet. The irony was not lost on me.

It's also worth noting that Agile/Scrum is not universally well liked anyway. In fact it's incredibly divisive. People who love it seem to really love it and people who hate it seem to really hate it.

For example, here's a site parodying the Agile Manifesto, asking the world to adopt something more modern: http://asyncmanifesto.org

And here's a much saucier (and perhaps less serious) take on the same idea: http://programming-motherfucker.com

TL;DR: Agile/Scrum is a management fad. Collaboration can succeed or fail using any methodology. All the blind praise the media spews for Agile/Scrum is arguably harmful to discussing what is and isn't effective management."

Original post: http://arstechnica.com/information-technology/2014/08/how-mi...

"Spontaneous collaboration can happen just as effectively with a remote staff, but you have to default all your channels of communication to digital ones."

So, if you handicap your local staff to use only a fraction of their communications capability then your remote ones are just as good?

Seriously - I've spent a large amount of time dealing with offshort staff and onshore staff, and staff both in the different buildings, the same building but different rooms, and staff in the same room - and having people sitting right next to each other makes a massive difference to the communication bandwidth.

The ability to turn your screen towards a co-worker, say "What do you think of that?" and get a reply three seconds later is _fantastic_ - and simply impossible with remote communications. (Where you can ping them on IM, wait for them to notice the message, start a screen-share, wait for them to accept, and then wave your cursor over the bit of screen you want them to pay attention to. It's effective, but it's nowhere near as fluid as pointing and handwaving.)

I strongly recommend reading the "Remote" book. There are sections which detail why the "handicapping" argument you just made is a fallacy.

As for the workflow you describe being "impossible with remote communications," trust me, it's not! Just paste a screenshot into a group chat.

Often this is faster and more effective than physically showing someone a screen anyway, plus it broadcasts the info to a potentially larger group.

As for the "wait for them to notice" part, that's just bad collaboration and it happens whether people are there or not. If you're expecting your coworker to be interruptible, s/he can be whether it's IM or it's a shoulder tap if that's the expectation.

Meanwhile, in a big crowded open office plan, often times people are just as uninterruptible as remote is so often perceived to be. People put on headphones and strongly resist shoulder taps.

Whether you're all in one office or all collaborating over chat, success or failure is about proper communication, not which medium you're using.

Depends on what that other co-worker is doing. If you are both aligning buttons on a windows form, sure. If the person being interrupted has 10 minutes of debugging state in her head, well, there goes over 1/2 hour of work (10 minutes to build that state, 10-15 minutes to recover from the interruption, another 10 to get back to where you were).

Which is another good reason for in person communication- you can see if your coworker is intensely focusing and give them space. Pinging them on IM is distracting and interrupts them regardless of what they are doing. Pinging an entire team on the "team chat" is even worse.

Easy solution: set IM to do not disturb and mute notifications until you're done with the intense focus task.

I particularly like the async style stuff because I can go read back through what is effectively an audit trail and figure out how something happened. It's a nice alternative to heavier-weight up-front design and documentation, especially for small teams.

Then, sometimes, you have cases like yesterday where CTO comes in at the end of the day, reads a chat log, and flips out because he thinks we're going to rewrite his garbage co^H^H^H^Hprecious baby. Some nuance can be lost just skimming over chat histories.

Reply on news.ycombinator.com