3 ms·

In my team if someone needs to pick up the kids he just says it in chat or even in a video meeting and gets them. I think webex meetings work better than real l

In my team if someone needs to pick up the kids he just says it in chat or even in a video meeting and gets them. I think webex meetings work better than real live ones. If they are tiring that's positive because meetings last too long. If only one person can speak at a time it prevents people from interrupting and makes them conscious not to hog the mic. Async communication? How would you do that? If you have a question and can't find an answer, what do you do? Make a jira user story to document this specific scenario and put yourself as the reporting too? Then assign to a colleague and hope he does something with it? I mean it could possibly work if everyone is accustomed to it, is of a very high level and is also a high level technical writer. But it just seems to me that in practice junior might be too dumb to understand seniors writing. Or senior just writes something that's not legible. Or senior ignores his new assigned story because junior created it and not the product owner. Or scrum master sees the story and thinks: that's not part of sprint goals and throws it out of the board. It seems really slow to work this way.

eXpl0it3r 6y ago
I think it really depends on the project size and the kind of work. If you're more in a waterfall model, where the specs are clear and you just got to do it, I can understand how being able to work uninterrupted is a nice-to-have. But if you work very closely with the business and often run into things that could be done or understood in different ways, having to wait a day or more to get a clarifying response would not work. And this is know-how that can't be written down easily if at all, since a lot of decisions are purely based on experience and historical knowledge. I used to have this illusionary vision of how everything should be neatly documented, but if you operate on a constantly changing code base, it's really hard to find a good balance. Documentation gets outdated every few weeks and sometimes days, plus most of the time, you don't even know that said documentation has been written. As such, you can't fully trust the documentation and you always have to check out at least part of the code. What seems to work for me, is documentation that gives a broad overview of a topic and then gives certain pointers into the code. That way you capture the essence of functionality that is likely to remain for a longer time and the transition from documentation to code is made easier. And finally, if someone is stuck or doesn't understand something, I find it problematic to have the expectation that nobody may be available to read your message for the next few hours or whole day. What is more efficient, someone spending a couple of minutes to provide assistance or someone googling/search Jira/wiki/Confluence for half a day and not making any progress?
AceyMan 6y ago
hence the classic: <remote_tz_projectmate> do you have time for a question? <me> ... that's one. TTYL [iterate] Yahoo! had a TLA for it or something. It was the "hey, are you there" syndrome, coined back when their IM was king. [edit: may have been AOL / same upshot]

eXpl0it3r 6y ago

I think it really depends on the project size and the kind of work. If you're more in a waterfall model, where the specs are clear and you just got to do it, I can understand how being able to work uninterrupted is a nice-to-have. But if you work very closely with the business and often run into things that could be done or understood in different ways, having to wait a day or more to get a clarifying response would not work. And this is know-how that can't be written down easily if at all, since a lot of decisions are purely based on experience and historical knowledge. I used to have this illusionary vision of how everything should be neatly documented, but if you operate on a constantly changing code base, it's really hard to find a good balance. Documentation gets outdated every few weeks and sometimes days, plus most of the time, you don't even know that said documentation has been written. As such, you can't fully trust the documentation and you always have to check out at least part of the code. What seems to work for me, is documentation that gives a broad overview of a topic and then gives certain pointers into the code. That way you capture the essence of functionality that is likely to remain for a longer time and the transition from documentation to code is made easier. And finally, if someone is stuck or doesn't understand something, I find it problematic to have the expectation that nobody may be available to read your message for the next few hours or whole day. What is more efficient, someone spending a couple of minutes to provide assistance or someone googling/search Jira/wiki/Confluence for half a day and not making any progress?

AceyMan 6y ago

hence the classic: <remote_tz_projectmate> do you have time for a question? <me> ... that's one. TTYL [iterate] Yahoo! had a TLA for it or something. It was the "hey, are you there" syndrome, coined back when their IM was king. [edit: may have been AOL / same upshot]