[anonymoushn]

> Even the heaviest weight version of this I can imagine (daily 30 min standups, 1 hour planning, 30 min retro, weekly sprints) adds up to 4 hours total for the week. So what you're describing is 80% something beyond that.

Pivotal Labs, well known for "doing Agile right," spends the entire Friday doing no work every week.

[adjkant]

Disclaimer: Defining and using a narrow definition agile IMO is a useless rabbit hole.

And the big names in tech also purport to use agile and spend maybe an hour every Friday or Monday doing "agile" type meetings. Which are we talking about here?

If it helps, add to my above post that I'm using "agile" to mean the philosophy of defined sprints with stand ups, planning, and retrospectives to help execute a larger, changing roadmap. There are many many other rules people can choose to add, but my experience across many companies is that this is the shared core in practicality.

When people say agile, 95%+ of the time they don't mean whatever Pivotal Labs is using for a standard. I've practiced "agile development" at F10, big tech, and under 250 person startups, and no one has ever referenced a strict spec definition like that, not even the F10 which basically said "here's some detailed guidelines some use, take what works". So what's the relevance of this strict definition?

[anonymoushn]

I agree that there's no use defining things so narrowly, but I think your experience about the meeting load involved in "doing agile" is atypically low for the industry in general.

[adjkant]

Maybe so, but it's varied across size and industry and matches with my friends experience in other broad areas. So I guess let's reframe: what is my meeting load estimate (the 4 hour a week high side) missing? How does that get to 4 hours a day, and if not there, what is the maximum?

To be clear, that's not to say that other meetings can't be used, but that they are not part of the "agile" process. I can easily imagine a dev ending up with 4 hours a day, but that's more related to company size and process. Things like design reviews, meeting with other teams, not being able to quickly find the right point of contact, using meetings to find out you have the wrong person, not defining clear agendas, inviting too many people to meetings, and so on. I'd bet some of these are affecting OP, but again, this has nothing to do with the style of development planning/process.

[anonymoushn]

It's easy to get to 4 hours a week of only standups.

[Volundr]

If your running strict scrum your stand-ups should be 15 minutes. In my current company as well as my last role that'd be a long stand. They were usually closer to 5.

[adjkant]

Okay, that's not what I said or what OP said though:

> How does that get to 4 hours a day

[cowtools]

Agile isn't just a workflow or philosphy. It's a way of life. No one has ever ben sucessful without triaging first.

[orwin]

Honestly, at my last company, in my first team we reserved the fridays afternoons for demo and short formations (the most complex, that also resonated the most with me, explained how and why the network architecture was made, while some were as basic as explaining how to make good PR).

It was way more productive than with my second team where we used one hour every two week for the retro. In big company, the time you actually spend on understanding how everything work is never really lost.