I manage managers and managers of managers, so have years of seeing this play out over dozens of teams. At this point, I prefer my engineering teams to "locally optimize" their process. I tell them that I care about the following 4 things:
1. There is a clear way for stakeholders to provide you with their requirements and discuss them.
2. There is a clear decision made about what is going to be worked on.
3. There is a way to check on progress without asking individual engineers.
4. After work is complete, stakeholders get clear communication about what actually happened.
I strongly suggest that they accomplish this by using "sprints", because then it means that they only have to manage the communication before and after sprints instead of ongoing. I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
Almost every team ends up doing daily stand ups, and when they don't it is usually because of timezone issues, so they find a substitute. This seems to be something that many engineers fall into as a habit to help keep each other unblocked.
The one thing that is problematic for my approach is predictability. If teams don't have an inherent value of completing sprint goals, then work carries over from sprint to sprint, and stakeholders can't predict when things are going to be delivered.
> I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
This is where CI/CD integration of tickets and good commit hygiene comes in, in my opinion. If your pipeline updates the state of the ticket as it progresses and commits are both sensible (describing the work completed rather than 'WIP: did stuff') and viewable from the ticket's history, that /should/ be sufficient to gauge progress when viewed alongside the work spec.
I strongly suggest that they accomplish this by using "sprints", because then it means that they only have to manage the communication before and after sprints instead of ongoing. I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
Almost every team ends up doing daily stand ups, and when they don't it is usually because of timezone issues, so they find a substitute. This seems to be something that many engineers fall into as a habit to help keep each other unblocked.
The one thing that is problematic for my approach is predictability. If teams don't have an inherent value of completing sprint goals, then work carries over from sprint to sprint, and stakeholders can't predict when things are going to be delivered.