Hacker News Reader

Comment by crazygringo | Hacker News Reader

I think you're being overly literal with "sprint".

And no, developers are not expected to be "in a sprint more or less at all times".

To the contrary -- in between each sprint, there's a review, a retrospective, often a weekend, then regrouping and feature analysis, planning poker, decision on which features to impement, and getting it up on the board.

That's the whole point. Instead of a long marathon without revision/reassessment/regrouping, it's a series of short sprints interspersed with revision/reassessment/regrouping. The metaphor here is the distance traveled, not the speed. Sprints are shorter distances, that's all.

Nobody has ever intended "sprint" to mean that engineers are going faster than in a marathon, anymore than "waterfall" means engineers are all tumbling down white water to their deaths at the bottom. :)

View on HN

Perhaps the word "sprint" translates primarily to "short distance" in your mind, but I suspect if that's the case you are unusual in that regard, and most people think of the defining characteristic of "sprint" as "moving fast", not "short distance". To suggest that the choice of that word does not imply a sense of urgency and moving quickly seems, to me, totally implausible on its face.

> And no, developers are not expected to be "in a sprint more or less at all times"

Again, perhaps this is your experience. In my experience, in every company I've worked for that uses sprints, the end of one sprint is separated from the start of the next by, at best, a few hours, and often less than that. Planning meetings generally take place during sprints.

And to point out that sprints may be separated by a weekend seems, at best, totally irrelevant, as in my working life, weekends are not part of working time. "You are in a constant sprint at work, but hey, you get to rest at the weekend" is not a compelling proposition to me.

> To the contrary -- in between each sprint, there's a review, a retrospective

"in between" is overstating things a bit. The current norm seems to be two week sprints and all these things are done at the beginning and end of them. To be honest, I personally do feel like this gives the feeling of 'sprinting' because it usually means at least 2-3 days of the sprint are 'wasted' on meetings and that counts for a lot when it's 2/10 or 3/10.

And a lot of the terminology around this kind of process are geared to give you a sense of urgency. Right back to "Extreme Programming".

> The current norm seems to be two week sprints and all these things are done at the beginning and end of them.

Everywhere I've worked that did "agile" did it this way. The ending of a sprint is always the start of the next one; teams are always in a sprint. If that part of the process can't be changed or removed then one of the best things to do is decouple the sprint cadence from other events. Eg don't put demo, pointing, planning, and retro on the same day. Try to do pointing mid-sprint, if you know what's coming up, so that you're not cramming it in at the end. Don't release to staging/prod at sprint boundaries, do that mid-sprint. The worst is to clump all the meetings, distractions, and stresses together.

I mean whether you clump them or not they're still time taken out of a very short period. I wouldn't (and haven't) minded so much with longer sprints, but 2 weeks minus planning/retro minus "one person takes a Friday off and another person is out one of the weeks" always leaves me feeling cramped.

I think the best structure I ever had was 3wk "actual work" sprints and 1wk to address tech-debt and do planning.

Every activity happens in a sprint including retro, planning and so on. At least in Scrum. Everything should be planned for.

Reply on news.ycombinator.com