I'm sure sure we're talking about the same things: not communicating daily is obviously going to be a problem, such as not giving the team a chance to change yo

I'm sure sure we're talking about the same things: not communicating daily is obviously going to be a problem, such as not giving the team a chance to change your priorities. But a senior knows basic needs for a product to live on like stable production, continuous integrations, unit/functional tests, code reviews, continuous deployment, infra & application monitoring, alerting, backups, service & dependency versions upgrades, fix regressions introduced by new features, with test ... and all sorts of quick wins for the product that come out of a casual discussion with a product / sales person etc ... The kind of usual things that becomes a daily routine and may just take the day to the point where you couldn't move any new feature card in the kanban anyway. Is it necessary to create a kanban ticket every time they do a package update, fix an impediment or do something in 0day ? It can surely be useful, not sure if it's more useful than just reporting on a text based chat, can it be harmful by polluting the kanban with tickets that don't create any obvious value (tech debt treatment) ? as long as communication goes through it's fine with me unless someone wants to build a report at the end of the month (ie. billing), I believe the practice matters more than the tool. But I'm more trying to understand the point of this article, searching for conditions that would validate it, rather than defend it in all case. For me daily communication and the three questions are important (but I prefer async / text based, and even twice a day: when I check-in and check-out), for the rest it depends, I can understand why some seniors would feel like blindly applying procedures may seem un-necessary or harmful sometimes, like they say : it's the dose that makes a cure or a poison.