Rethinking Agile in an office-less world | Hacker News Reader

Rethinking Agile in an office-less world

37signals.com

43 pointsmh_23 comments

Perhaps the point of the article was to stir conversation, but I'd prefer it if they'd actually propose some ideas, rather than saying that it's different now.

I'm not a huge fan of Agile, but I do think it encourages some good ideas. That said, I'd love to hear what the analogs are for remote work from the perspective of a company that really does it.

To me, the point of the article is to promote the upcoming book

This is just a fluff article to tangentially promote their upcoming book, Remote. Why this is going to be upvoted is beyond me.

It is getting up voted because it is a real question for people. I've worked in a 100% remote environment for 5 years, and a part-time remote environment for another 4 on top of that.

Creating great software in those environments is a challenge, and worth discussion, regardless of the motivation of the original author.

One of the odd misconceptions I've had to deal with, 1/3 of one of my teams is offsite, is the idea that Daily Stand Up has to be in the morning. We change the question from "What did I do yesterday?" to "What did I do in the last 24 hours?"

Easy.

The next mountain is to change what is said from status to communication, which is the point of the meeting in the first place.

These are largely solved issues. Standups can be done over a web chat, and may actually be even better with todays screen sharing capabilities, where you can actually SHOW everyone what you are working on. Tools like tmux have had the remote pairing issue solved as well. Face to face is good here and there, but I see no reason why agile cannot be practiced just as effectively remotely.

Or Hangout / Skype / GTM for standup.

We have standups and occasional pairing done remotely (via tmux/wemux). We've been doing this for at least a year and a half now.

Seems like DHH is late to the party. What he says are currently competitive advantages for the companies that already practice it. But I suppose, the bulk of workplaces still have yet to try this out.

I believe this is what he means when he says "the hacks that makes that setup more workable". Your technological solutions assume synchronous work, which limits the pool of employable people to those with similar preferred workdays, where DHH would ostensibly like to work with people around the world.

Email or Voxer work for async communication.

I actually find 37s' Campfire works for both async and synchronous communication.

It's obviously a chat-room for immediate talking, but the highlighting and ease of scrollback (without having to have irssi or similar running constantly) mean you can easily catch up and pick out messages left for you when you were offline.

Which makes me think the post is just about the upcoming book.

Not all communication can be async, for example for brainstorming or getting a complicated point across the instant feedback is very important.

As an example (and to toot my own horn), my shared whiteboard tool http://awwapp.com/ is often used by remote-working teams to quickly sketch something. Users could just as easily fire up a drawing program and email the picture, but having the instant feedback makes all the difference.

I thought agile was supposed to be a preference for useful flexibility, rather than a fixed set of practices?

The canonical remote collaboration tools are IRC and mailing lists.

There are various sites that allow some sort of remote pair programming, I'm not sure if it's just screen sharing plus audio chat or if there's more structure to it.

At work we have conference calls, often with presenter-to-group screen sharing. (We use cisco webex, does anyone know an open alternative?)

For larger meetings we've been experimenting with videoconferencing between meeting rooms in different cities. Since being on video is annoying, maybe this would be an alternative to stand-up meetings? (I'm pretty sure whatever we use for this is proprietary as well, what's a good open alternative?)

The point of many Agile practices is to increase communication. How can you best capture the ease of walking 2 cubes over to have a chat with your coworker? If everyone's remote you don't have as good a natural indication of how busy or available everyone is. If you build something to provide that indication, the boss can monitor it and it will stop working right.

If people are talking in the next cube over, I can ignore it or jump in if I hear something interesting or that I can help with. But in some cases the discussions are things that wouldn't be discussed where certain other people might be able to overhear. How do you capture when communications should be available to some part of the group without interrupting them (so no acknowledgement needed from the recipient), but hidden from some other part of the group? And without requiring the people initiating the communications to explicitly bother to set this up? This is naturally baked in to physical-world interactions, is it useful enough to try to duplicate?

I've heard suggestions of a "virtual office" for voice chat, where you have a grid layout with cubes or conference rooms or whatnot and people have locations on that grid and can hear eachother (or not) based on how close they are. Is there anything that actually does this? Is it useful (or if it doesn't exist, would it be useful to have or is it just gimmicky)?

From what I understand, electronic text-based communications tend to be archived for a long time for legal reasons. How far does this apply to voice communications, and does VoIP vs telephones make a difference? How far does this affect what is or isn't said? I know at work, some conversations only happen in person or over the phone rather than IM or email. How important is this effect, and how does it impact getting work done?

> I thought agile was supposed to be a preference for useful flexibility, rather than a fixed set of practices?

It is. To too many people "Agile" means "Scrum" (or, whatever particular set of fixed practices they've adopted, but Scrum seems far and away the most common.)

> The point of many Agile practices is to increase communication. How can you best capture the ease of walking 2 cubes over to have a chat with your coworker? If everyone's remote you don't have as good a natural indication of how busy or available everyone is. If you build something to provide that indication, the boss can monitor it and it will stop working right.

I saw a tool the other week (I think from here) that shows you live webcam views of all your co-workers in a grid like fashion. Clicking on one of them starts a video conversation straight away. If they are busy or AFK it just shows a static profile picture. Regarding the boss monitoring it, I think in that case you need to find a better boss.

EDIT: I think this is actually better than going over and straight up talking to someone. What if they are deep in the zone and don't want to be disturbed?

It is, but the Agile Manifesto isn't, on the face of it, remote-worker friendly.

  6. Close, daily cooperation between business people and developers

  7. Face-to-face conversation is the best form of communication (co-location)

So, I can see why people think there's a need to work out how to do remote working in an Agile manner or to find a viable alternative.

Remote working is always a trade-off sacrificing communication bandwidth for some other gain. Mitigating that cost -- because the gains to be purchased with it are often attractive -- has long been an issue in Agile circles, and its not really a "rethinking" of Agile to address that.

Sure, the Manifesto states that Face-to-face conversation is the best form of communication -- that doesn't mean you can't use other forms of communication in an agile process, it means that you need to be aware of the costs and to do it only as a conscious decision weighing the communication costs against the benefits, and ideally doing what can be done to mitigate the communication costs.

What I've found that works rather good is having your own internal IRC server, so you can have as many rooms as you need. Everywhere I've worked has tended to have rooms per group/project with the needed overlap. It's also easy to pop someone a PM to join your channel if you need their thoughts. There's also usually a "watercooler" room for that non-work interaction that helps build team camaraderie. Some places have also had bots that display all new commits in the channels, as well as having other custom functionality. I'm not sure if they still do, but Facebook used to have IRC bots that managed deployments.

<rant>This is nerd-bait, and I'm quickly getting my fill of "hey, we need to rethink things!" without there actually being any rethinking going on.

Yes, we need to rethink things. We constantly need to rethink things. Introspection is the root of all improvement. I think we've got that by now.

I don't mean to vent, but what the tech community is really interested in is results, not more bloggers with opinions. Got plenty of these guys already. So show me you've tried something and it works, I'll collect the details, and over time and hundreds of experiments, we can start to draw some correlations. A few stories and an upcoming book ain't going to cut it.

What I'm seeing in the tech community is this rise of, for lack of a better term, dimestore pundits. Some guy gets a big contract for XCorp, tries working with people dressed up like chickens. Now he has a website and a book on how we're all supposed to dress up like chickens when we work.

It's always been like this -- the folks with the megaphones drowning out the folks who plod along trying to spot patterns and share stories without becoming dogmatic. But lately people are climbing on this bandwagon where in order to grow, you should be teaching something. So hell, everybody with a keyboard is now a teacher. That's not a recipe for helping folks, that's a recipe for generating widespread cynicism.

I wish the 37Signals the best of luck in these marketing efforts. I understand they're quite awesome. I just get tired of being baited with half-assed conjecture sitting on top of a few anecdotes. Things have changed. The world moves on. We're the tech community. We get that. So show me the startups that are changing the world with remote teams. Show me the consulting companies that are killing the competition by using distributed teams. Show me the companies that are clamoring for distributed and remote teams because they're finding them so efficient. Show me a bunch of data. Then you can wave your hands around and we can all have a nice sing-a-long about the brave new world we're headed into. Otherwise it's just self-gratifying noise.</rant>

Not nerd-bait...really you bring up some good points.

We have being doing Agile in distributed teams since 2006.

This is bit late, no?

No. Many people are have a bias against distributed teams, especially in the case of startups, since they believe that it's harder to collaborate, and because they prefer the feeling or appearance that comes with having an office.

Funny, that you give startups as example.

As stated on my previous comment, I have been doing Agile projects, with distributed team across the globe, in the enterprise world since 2006.

While it is true, that it had its share of issues while we were discovering how to apply agile concepts in a distributed manner, I would expect most of the issues would be quite known in 2013.

Specially in the startup world, which tends to be more flexible in regards to the enterprises.

The human factor is actually quite important, but in many cases it is not possible at all to have everyone on the same place.

Please stop posting DHH shit. Going to his articles feels like I'm being Rick Rolled.

Reply on news.ycombinator.com