My IT shop tried working from home for a couple of years and the team fragmented, we lost a sense of teamwork, and we started wondering what each other are doing. A new CIO mandated working from the office and it has made for a much better culture and collaboration environment. There's definitely something you lose when you don't work in the office with your fellow team members.
I think that depends on your process and team culture. My current team is remote and we aren't fragmented. For most remote teams all it seems to take is a daily status meeting and a chat room.
I am beginning to feel even a daily status meeting is too much - I would much prefer to take on tasks of around a couple of days, and when done, demo.
I feel the same way. Often times I really have nothing meaningful or relevant to share with the team on a daily basis.
"So yeah, that feature we all agreed would take about 3 days to complete? Welp, it's day 2 and I'm still working on it. Progress is good."
Any other details further than that are not of any significant interest to anyone else in the meeting because they all have their own tasks that they're focused on that week. People argue that these daily status meetings help identify problems early on but whenever I run into an issue, big or small, I don't wait for tomorrow's status meeting to rectify it I just immediately start a discussion in the chat room. Obviously this requires trusting your co-workers to not hide potential issues/blockers but if you're not trusting your team than there's bigger issues to deal with that daily status meetings aren't going to help you with.
That said, the benefits of a daily status meeting is all very dependent on the type of project and the amount of collaboration the tasks require.
1. The managers way of finding out what is going on instead of seeing git, running latest code.
2. A way of giving developers bi-polar disorder as they either happen to have just checked in a working piece of code (up) or are still ploughing through on what they said they would do yesterday (down).
It can be good - but only when it requires execution not thought.
My solutions:
1. A selenium / CLI recorder. We make changes to a piece of code - which is covered by ten tests. You fill in the bug report and the recorder does video grab of the selenium web broswer doing the ten tests. Then anyone who is non technical can see what the actually results are - on Youtube!
I heard of some "developer lead development" in a job ad - I think it was Sky. The idea was github like I suppose - devs think "what we really need is" and go do it.
The boss effectively has a veto not a driver. The boss becomes a government.
Agreed. I can definitely see how a team that's used to working in physical proximity would need time and good direction to get used to such a drastic change in methods and environment, but that's simply a matter of acclimation, not an indictment of remote engagement.
We've been experimenting with remote workers for the last two years or so. Our team was used to work in the same place (in Paris), so it took a little bit of time to get used to, as we tried different ideas. Now it works really well with phone/video conferences, trello boards, github, remote pairing, and a (few) permanent chat rooms (thank you Freenode <3), etc.
I think the biggest complaint is that the offices sometimes feel empty to those who chose to work "on site". My take on this is "let's get smaller office space". Plus it costs less. :)
