The only thing consistent about Agile is that everyone is doing it wrong. @fwip
So you're telling me that engineers get 12 weeks off per year to surf and paint? How would that ever work in a world where 996 is becoming the norm?
I think your team should take as much time off as it's comfortable with.
I will point out that the 40 hour work week was once considered a radical idea. Google started 80% time, we're at 75% time here, I'd like to get that down to 10% time (the Ferris method) by the end of the 2020s.
996 (9am-9pm 6 days per week) is working on the other side of that, seeking to extend the 40 hour work week to a 72 hour work week. I see this as a regression and think people should stop fetishizing long hours. It's not actually more productive.
It's also up to you whether the "week off" is a week for vacation or for a lighter work load or for whatever else. The answer might depend on the particular week.
Maybe "light week" is easier for people to stomach than "week off". Use whichever you're more comfortable with.
Surfing and painting are in no way required, they were merely cited as examples. In fact, I don't even surf OR paint.
Are people committing to issues in a sprint or are they forecasting the issues they'll get to in a sprint?
They are forecasting. It is not a moral failing if your estimates are off. It's all part of the process and everyone's on the same team.
Can we call them iterations instead of sprints?
Sure! I'm going to stick with "sprint" myself.
Can we do a kanban style rolling iteration where start dates and end dates vary and depend on circumstances?
I really value the concept of the work cycle having a defined start date and stop date and being defined by a single block of tasks. Rolling iterations not synced to a specific cycle would mess that up.
Why 3 week sprints?
Because development work plus recovery time then fits into 13 slots per year. When the cycle is over, a new cycle begins. The "week off" allows a reset before the new sprint begins. It's about achieving a cadence and having clear and consistent intervals.
Does this mean sprint start dates and end dates will often fall in the middle of the calendar month?
Yes.
Are developers included in sprint planning?
Yes. They are not banned from the meeting. They just don't need to attend, especially if they've kept the Issue Tracking System current and the team has discussed some of the items for the next sprint during the course of the previous sprint.
I'm all for less meetings. Are you a rare person that enjoys meetings? As long as I don't have to attend, don't let me stop you.
Does it really take a week to plan a sprint?
No, that's the point. It's a light week.
Are standups really a problem?
In my experience, yes. It's usually everyone standing in a circle listening to one person talk for 20 minutes. Of course, this is "doing standups wrong", but I haven't seen any teams that do them right and I'd just as soon not do them at all. It is also harder (or at least more inconvenient) to do them when you have a geographically distributed team. But if standups are your thing and you get a ton of value from them, don't let me stop you.
Do we have to do it this way?
No. Nobody is forcing you to do anything. They're guidelines, not rules.
This is not a religion.
It is political only in the sense that advocating a 40 hour work week was political.
Are you aware that what works for you might not work for others?
I sure am!
You shouldn't estimate because estimates are impossible.
Estimates are regarded as estimates, not as blood contracts. Therefore, if they are off, that's ok. Do the best you can and estimate in increments of 4 hours.
Developers cannot be trusted and must account for all their time because that's how work works.
I really disagree but can't explain why quickly. We have a fundamental difference in world views.
This isn't agile.
Sure it is, it's right there in the name.
This will never work.
And yet it does.
You're doing agile wrong.
Unfortunately the problem with agile is that it cannot be done correctly.