[mmsimanga]

> This will interrupt programming flow.

This for me is the biggest drawback. When you are in the zone and interrupted it takes long to get back in the flow again.

Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me. This is hard to explain in Agile with a PM/scrum master present.

Edit: PM/scrum master because we have mixed environment.

[twic]

> This will interrupt programming flow.

This is why you do the standup first thing, before people have started working. There is no flow to interrupt.

> Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me.

If you're doing XP, or any kanban-flavoured variety of agile, you pick up one story/feature/etc and work on it until it's done. You might jump around in the codebase to build that feature, but you work on one feature. That's easy and natural to describe in a standup.

If you're not doing that, then indeed, it's going to be hard to talk about what you've done.

But to be honest, what you're doing is almost certainly not very effective, so maybe stop doing that?

[mnm1]

Having it be the first thing in the morning seems to be the least efficient option possible, way worse than being interrupted in flow. This is the peak working time for most people, peak alert time for the majority of the population, and therefore the most productive time for many people, even many of those who are not prone to waking up early. Starting with something that's mostly useless to the developer and taking focus away from what really needs to get done that morning sometimes kills the entire morning. I'd rather be interrupted mid-flow and I'm certain I'm not alone considering the majority of the population actually is most alert in the morning (along with the other peaks of energy throughout the day). The optimal time for such a meeting would probably be either right before or after lunch, with lunch being variable and taken based on the workload of that day.

[mmsimanga]

> But to be honest, what you're doing is almost certainly not very effective, so maybe stop doing that?

You most certainly don't have enough information to make such a recommendation.

[balfirevic]

> This is why you do the standup first thing, before people have started working. There is no flow to interrupt.

That requires all the people to come to work at the same time.

[mmsimanga]

This point is dealt with in the article. People have different traveling arrangements. In my case sometimes I have to drop off my child at school and head in after the morning rush hour. So daily stand up is not first thing in the morning.

[spzb]

I worked on a project where we had the daily scrum (by conference call) at 4pm, precisely because people all started work at different times. All that that achieved was to mean that I was unproductive from about 2pm because I was thinking "if I get into something now I'll get interrupted before I properly finish it"

[mcv]

There's no PM present in the Scrum daily. In fact, there's no PM in Scrum.

Jumping between different stories before finishing them is fine in solo projects, but if you're working with others, it means more code conflicts. That said, it is absolutely possible to work on multiple stories in Scrum.

[mmsimanga]

I work Business Intelligence (BI) using SQL and a reporting tool of choice. There are times when I just cannot write another peace of SQL. I can tell what I am churning out is long winded and likely to be slow. There are always other tasks such as setting up stylesheets, setting my templates, distribution lists for reports and so on. The problem I have is I don't know when I will be tired, typical issue is always the data quality that results in complex SQL.