3 ms·

I don't understand this. I have worked remote and semi-remote for several years at large and small US companies, with internationally distributed teams. General

I don't understand this. I have worked remote and semi-remote for several years at large and small US companies, with internationally distributed teams. Generally, we have run loose SCRUM/agile processes with good results. There is really nowhere to hide. Either the bug is fixed or it's not. The new feature is there, or it's not! You make stories/tickets. You run sprints. You check in code. You see passing or broken builds. You demo to customers or management that serving as proxies for customer interest. There is much imperfection in our processes, but basic visibility is good. The stakeholders can see Jira, Github, Jenkins/Teamcity. The devs cannot hide, so the work gets done.

shitgoose 9y ago
i guess it depends on the project. if business side is not too complex and can easily be translated into jiras and stories, then developers should have a good grip on what needs to be done and why. then remote is fine. but if business requirements, on the other hand, are complex, poorly understood or fluid, then developer will be absolutely lost and will start cranking up patterns instead of solutions. teamcity will be building alright and scrums will roll, but project will be a complete mess heading for a disaster. face to face will not save the day, but to some degree will mitigate lack of communication and understanding of common goal.