Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint."
I do think it's useful to have some cadence for important meetings, but the arbitrary timeframe should not be treated as a goal or even something worth dignifying in and of itself. It's simply a tool, nothing more and nothing less, and we should expressly state its purpose and discard it in situations where it ceases to be useful.
I actually do like the default Agile meetings, but I think they're usually implemented haphazardly. I would prefer standups at the end of the day so that they run no risk of destroying the context of a programming task or block me from starting my work day. I like IPM/sprint planning to refine stories and make sure they're ready to work. I like having a "definition of done" to create a shared agreement of what my commitments are and whether I've met them. I like retro to evaluate how we're doing as a team and to improve processes and working culture. I like technical retros to share learning and troubleshoot architectural problems and identify useful areas of research.
All of these things are great when done well and for the right reason. All of them can be sources of misery when they are done ineptly or as mere formalities, with no underlying sense of purpose.
Do standups just before lunch. People tend to work on different schedules, start/finish early, start/finish late, but most tend to have their "middle of the day meal" at around the same time. So instead of 9 or 10am, or 4 or 5pm, do it at the "natural" break time, eg 12:00-12:15.
Two advantages, people that have got "into" the work flow in the morning need to break anyway, people that use the morning for "admin" and then afternoon for work can finish their housekeeping with the standup.
Same applies at the next order of magnitude, start/finish sprints in the middle of the week, not the beginning or end. No one wants to sit in a review on a Friday afternoon.
Retrospectives make sense at the end of the working week. Planning makes sense at the beginning.
> Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint."
As a both a runner and a developer, I find this quite funny and a bit wrong. The fact that we call them sprints can be a bit wrong or confusing if you put them in a different context, but what I can say is that almost every serious runner will constantly check their laps, be it miles, be it km, you will always look at your watch to see how you performed in your last km and if you are on track.
That's what I see useful in sprints, the fact that you stop for a bit and see where you are, you have the time to discuss things that might have gone wrong and try to fix them before it gets out of hand. But in the end I can understand people who dislike the system, because I've worked with a lot of managers with no technical knowledge trying to manage technical projects.
Unlike in a run, where I know the exact moment and location I have reached my halfway point, in a real software project I don’t even know what the actual distance to be covered will be.
What sprints force you to do is basically make sure you’re running full tilt for every 400m distance, which is fine if the eventual distance ends up being 800m for example, but if it ends up being 26 miles instead, you’re just gonna burn out well before.
I do think it's useful to have some cadence for important meetings, but the arbitrary timeframe should not be treated as a goal or even something worth dignifying in and of itself. It's simply a tool, nothing more and nothing less, and we should expressly state its purpose and discard it in situations where it ceases to be useful.
I actually do like the default Agile meetings, but I think they're usually implemented haphazardly. I would prefer standups at the end of the day so that they run no risk of destroying the context of a programming task or block me from starting my work day. I like IPM/sprint planning to refine stories and make sure they're ready to work. I like having a "definition of done" to create a shared agreement of what my commitments are and whether I've met them. I like retro to evaluate how we're doing as a team and to improve processes and working culture. I like technical retros to share learning and troubleshoot architectural problems and identify useful areas of research.
All of these things are great when done well and for the right reason. All of them can be sources of misery when they are done ineptly or as mere formalities, with no underlying sense of purpose.