4 ms·

I am working remote for 3 and a half years now. Meeting the "week by week" expectations is the most important thing, period.

blazespin 7y ago
The fundamental problem with scrum is that bugs happen and nothing interesting from a development point of view can be predicted effort wise before hand, at least not accurately. The right way, is to do all velocity analysis backward-looking. Create a culture where code reviews are done constantly and long after they've been merged in. Use metrics like KLOC, duplicate lines of code, changes to code, stories completed, etc. That's the way to measure velocity. Measuring done done done by end of sprint, is really wasteful as some engineers get it into their head to pad their estimates to make sure it's completed by some arbitrary date. This just leads to a culture of padding estimates rather than completing work when it's done. That said, I do like letting engineers pull tasks as they like. If a more senior engineer in a certain area can complete a task better and more thoughtfully, than he should have a chance to pull it. This also does require technical PMs which can discuss and understand the cost of their stories. This is important regardless however.
- deleted 7y ago
  [deleted]
CameronBanga 7y ago
I'm about to add our first remote hire to our team, where 4 will be based out of office and one will be remote. Would love to hear your thoughts on this and get some feedback as to how I should best plan for this on our side, if you're willing to share? My contact info is in my profile.
- machiaweliczny 7y ago
  You just need to embrace async communication even with one remote worker. In short: all relevant problems/design/communication solved on project channel and not offline or private coversations.
- DoofusOfDeath 7y ago
  I've been the only remote worker on a team in the past, and it was a horrible experience. Ways you might be able to avoid that: - Treat communications as a first-class management consideration for yourself and every team member. Make sure your team gets the message. - Treat telecommunications issues, especially the quality of teleconference calls, as a top-level issue. Otherwise the remote worker will, again, be at an information disadvantage. He/she will have to choose between (a) repeatedly asking everyone in the meeting to repeat themselves, move closer to the mic, adjust the camera orientation, etc., or (b) miss some potentially important communication. - Remember that every fun perk for physically present staff (going out to lunch together, having an after-hours beer, etc.) runs the risk of making the remote worker feel left out and not an integral member of the team. Treat this as a management problem. If these problems are manifest, not only will you suffer the direct implications of missed communications, but you're likely to face a disengaged worker, which is fun for nobody.

blazespin 7y ago

The fundamental problem with scrum is that bugs happen and nothing interesting from a development point of view can be predicted effort wise before hand, at least not accurately. The right way, is to do all velocity analysis backward-looking. Create a culture where code reviews are done constantly and long after they've been merged in. Use metrics like KLOC, duplicate lines of code, changes to code, stories completed, etc. That's the way to measure velocity. Measuring done done done by end of sprint, is really wasteful as some engineers get it into their head to pad their estimates to make sure it's completed by some arbitrary date. This just leads to a culture of padding estimates rather than completing work when it's done. That said, I do like letting engineers pull tasks as they like. If a more senior engineer in a certain area can complete a task better and more thoughtfully, than he should have a chance to pull it. This also does require technical PMs which can discuss and understand the cost of their stories. This is important regardless however.

deleted 7y ago
[deleted]

CameronBanga 7y ago

I'm about to add our first remote hire to our team, where 4 will be based out of office and one will be remote. Would love to hear your thoughts on this and get some feedback as to how I should best plan for this on our side, if you're willing to share? My contact info is in my profile.

machiaweliczny 7y ago
You just need to embrace async communication even with one remote worker. In short: all relevant problems/design/communication solved on project channel and not offline or private coversations.
DoofusOfDeath 7y ago
I've been the only remote worker on a team in the past, and it was a horrible experience. Ways you might be able to avoid that: - Treat communications as a first-class management consideration for yourself and every team member. Make sure your team gets the message. - Treat telecommunications issues, especially the quality of teleconference calls, as a top-level issue. Otherwise the remote worker will, again, be at an information disadvantage. He/she will have to choose between (a) repeatedly asking everyone in the meeting to repeat themselves, move closer to the mic, adjust the camera orientation, etc., or (b) miss some potentially important communication. - Remember that every fun perk for physically present staff (going out to lunch together, having an after-hours beer, etc.) runs the risk of making the remote worker feel left out and not an integral member of the team. Treat this as a management problem. If these problems are manifest, not only will you suffer the direct implications of missed communications, but you're likely to face a disengaged worker, which is fun for nobody.