So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine.

The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.

Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time.

The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.

As for second paragraph, I prefer management style that accepts that things sometimes take longer then estimated. I don't want to stay longer because made up deadline.

Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful.

The point of the meeting is often…

I maintain that is this happens, you are in a bad environment.

That's what retrospectives, demos, and stories are for.

If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.

The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.

Here’s one example:

* Moving functionality from a legacy^2 to legacy (mainframe to client-server)

* Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years.

* Source and target systems inherently un- unit testable

* Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some

* Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories

* Culture of fear reinforced by performance reviews, stack ranking and PIPs

* Locked down QA systems and silo’d resources

Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.

IMO, only for a small minority of tasks.

The vast majority of projects I've seen and worked on are measured in dev years of effort.

My current project is well over a thousand dev years.

In comparison a few days is meaningless.

Most often it's a trust issue.

Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter.

Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.

Kind of. It's upper-medium.

It's nothing compared to Microsoft Office, a web browser, etc.

Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year.

> Typical project size is somewhere around 500 to 1000 man days.

That's roughly 2 devs for a year. That's hardly even a prototype where I work.

It is fascinating to see the difference in scale in our industry.

It depends on the team.

We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.

Tracking progress goes on a Kanban board (or digital equivalent).

www.scrumguides.org/scrum-guide.html#events-daily

Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team.

Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)