I think a scrum/kanban board is a very strong instrument in implementing a healthy development process. There should be an explicit method to updating the board - even if the method is just "you can move only your own tickets". If there is an intact development process that lacks a board&ticket system I don't see it is necessary to implement one. However, broken development processes often have a problem of priorization and communication and discplined ticket and board tracking system can help there a lot.
Now, the daily standup is one method of updating the board with the added benefit that it provides maximum bandwidth of information of team status in a brief time to all team members.
The author stipulated that in their team everyone else already knows what others are doing. If so, great. However, I think it is really naive to think this would hold for all teams. For teams that lack this amount of coordination and transparency I would see a healthy standup that is brief and to the point improves teamwork as it helps synchronize work.
Not all teams are composed of equal members. There can be coherent products whose team members work on completely different areas of the code and the product to implement the feature and in those instances I would imagine it would slow down total velocity if everyone would need to keep tabs on what everyone else is doing. For instance, a dedicated tester might be a part of the team, who is not so interested in explicit submits but rather what is the current end-user interface status.
Not all people are comfortable in asking support due to shyness and so on. Having an explicit process of synchronizing work and announcing impediments can help there a lot. Since impediment removal is part of the process, the person asking for help does not need to feel like a bother (and they notice others need help too), the work progresses and everyone is more relaxed. The counter argument is that people should already be good at teamwork - sadly this is not true, great teamwork is not inbread to humans, but, everyone can learn it and having a teamwork supporting process in place helps to maintain a healthy culture.
So, I suppose, in the end, it's not necessarily about standup vs. no standup, it's about having processes that helps supporting a healthy team culture, whatever it is. For small teams with long term stability this is less of an issue but the more ephemeral the team constitution is and the larger it is the more value a healthy standup process can bring (healthy as in by-the-book-scrum healthy - to follow the manifesto style - I prefer a by-the-book-scrum standup that is about bringing value to the team to a standup that is converted to a managerial status update).
Now, the daily standup is one method of updating the board with the added benefit that it provides maximum bandwidth of information of team status in a brief time to all team members.
The author stipulated that in their team everyone else already knows what others are doing. If so, great. However, I think it is really naive to think this would hold for all teams. For teams that lack this amount of coordination and transparency I would see a healthy standup that is brief and to the point improves teamwork as it helps synchronize work.
Not all teams are composed of equal members. There can be coherent products whose team members work on completely different areas of the code and the product to implement the feature and in those instances I would imagine it would slow down total velocity if everyone would need to keep tabs on what everyone else is doing. For instance, a dedicated tester might be a part of the team, who is not so interested in explicit submits but rather what is the current end-user interface status.
Not all people are comfortable in asking support due to shyness and so on. Having an explicit process of synchronizing work and announcing impediments can help there a lot. Since impediment removal is part of the process, the person asking for help does not need to feel like a bother (and they notice others need help too), the work progresses and everyone is more relaxed. The counter argument is that people should already be good at teamwork - sadly this is not true, great teamwork is not inbread to humans, but, everyone can learn it and having a teamwork supporting process in place helps to maintain a healthy culture.
So, I suppose, in the end, it's not necessarily about standup vs. no standup, it's about having processes that helps supporting a healthy team culture, whatever it is. For small teams with long term stability this is less of an issue but the more ephemeral the team constitution is and the larger it is the more value a healthy standup process can bring (healthy as in by-the-book-scrum healthy - to follow the manifesto style - I prefer a by-the-book-scrum standup that is about bringing value to the team to a standup that is converted to a managerial status update).