1. WFH involves a slightly different relationship with working time - a working day has no beginning and no end, but load is distributed across more freely. That is, if the vast majority of people in the office work from 10 to 19, then on WFH we often can see something like: "I work from 11 to 15 while my wife looks over the child and then from 20 to 24 while the child sleeps". Such distribution of time might be mandatory, especially in the current situation of forced WFH.
2. WFH, especially in combination with quarantine measures such as the closure of fitness, very quickly lead to the lack of communication and feeling of loneliness. In many cases, an employee compensates for this with increased activity in personal chats/groups and increased time spent reading these chats. Moreover, a typical office pattern: "raise the head; make sure that a colleague is on his desk; ask a question; get an answer" is replaced by "writing in a chat; waiting for an answer".
3. WFH leads to fast growing distance from the team. As kitchen communication, joint lunch, etc. are lost, the employee quickly loses the sense of team and project, despite the daily scrum and other ceremonies. The pattern like "pick up the task from the air" or "help a stuck teammate in between of own tasks" is lost.
4. WFH job mainly attract people of a certain nature, often with some hard life circumstances, or contribute to the development of specific character traits, so you have to be very careful getting into the personal space of such people (happy birthday, pulling out on the team events and so on).
A few tips to deal with problems mentioned above:
1. Decrease the number of communication channels for developers. In some cases it is better to kill all chats altogether and move all communication to email.
2. Set some rather narrow intervals within a working day for chatting. At this time and only at this time, you can ask a question and expect an immediate answer. At any other time, the developer should not rush to answer immediately, but wait for a natural pause in the work. This agreement should be explained loudly to all team members, managers and developers.
3. Keep sending across the project digest (once or twice a week - depends on the intensity of the project), with the main non-technical events in the project and high-level plans for the next interval.
4. Ask developers to update their tasks daily and to put the task to correct status as soon as possible. In addition, more efforts should be made to develop DOD and to make tasks more atomic and clear. Checklists are useful here.