5 ms·

edit: whoops, it seems the author uses "sprint" to say something else than the agile stuff [1]. So this comment is a bit out of topic. [1] https://news.ycombin

by jraph 3y ago

edit: whoops, it seems the author uses "sprint" to say something else than the agile stuff [1]. So this comment is a bit out of topic. [1] https://news.ycombinator.com/item?id=37142781 https://news.ycombinator.com/item?id=37142781 --- I strongly dislike sprints, but I would be open to discussion about them in a client project. For something like Chrome which isn't driven by client needs that are difficult to understand, whose roadmap constantly needs to be adjusted, etc, I think sprints make no sense at all and are purely harmful. Sprints are for having a fast feedback + adjustments loop with a customer whose needs are unclear / where the budget is a forever negotiation depending on how the project advances. If you are building a product for which you have full control over the roadmap, you don't need the 2 week sprints. You can still experiment and get fast feedback on new features as you like, but not everything requires this fast feedback. The two week sprints are a strong constraint on your product development that might kill its long term stability because they require you to shoehorn maintenance tasks that don't necessarily fit in two weeks… in two week chunks, and I don't see the need for this in such a setting. Even in a client project, sprints can be avoided. A regular (e.g. weekly) call with the client to discuss progress and adjustments + releases when there is a need for them can work very well. I actually strongly believe the two week sprints are overkill, not enough flexible and harmful in many projects. Task assignment of course needs to be done carefully, but this work can be done asynchronously or as-needed (which, agreed, might work better for very small teams).

demondemidi 3y ago
I dislike sprints but have not seen a better alternative for teams of 50+ people.
- HumanOstrich 3y ago
  What about smaller teams?
  - hanniabu 3y ago
    Rolling kanban
- jraph 3y ago
  I've only worked in small teams. Could one possible answer be to spit such big teams into smaller teams and organize / structure the project so that teams can be relatively autonomous?
- caskstrength 3y ago
  > I dislike sprints but have not seen a better alternative for teams of 50+ people. Team of 50+ people?! I wonder how do your Scrums look like. Is the work day over by the time you finish it?
- Cthulhu_ 3y ago
  That isn't a team, that's a department; I presume those people are either explicitly or implicitly divided into smaller teams / responsibilities?
dragonwriter 3y ago
> Sprints are for having a fast feedback + adjustments loop with a customer whose needs are unclear Do they add any value there compared to having the same cadence of customer contact, while dev happens in a flow-based (kanban, etc.) model with as-ready delivery of value-producing units of work (i.e., stories) as completed? I get that historically sprints were adopted as a way to do incremental, fast-feedback delivery as an alternative to “deliver at the end” project styles, and as an alternative to that, they seem to make sense. But they still incorporate the “deliver at the end” mindset, just with arbitrarily timeboxed aggregates of what is otherwise conceived as independent units of work. And if you’ve got independent, value-delivering units of work, its not too long until you realize that those are your natural and irreducible “deliver at the end” units.
- datadrivenangel 3y ago
  Kanban is the way. Keep things flowing.
- jraph 3y ago
  > having the same cadence of customer contact, while dev happens in a flow-based (kanban, etc.) model with as-ready delivery of value-producing units of work (i.e., stories) as completed? I'm currently on a project that works like this, without sprints, and clearly it works for us. Also, no standups. We communicate as soon as it's needed and not more (often) than needed.
- fnordpiglet 3y ago
  Planning should be a continuous and real time endeavor; and planning without your stakeholders input is a plan to fail.
- SkyPuncher 3y ago
  I've found them incredibly useful for getting teams to be realistic about their bandwidth and throughput. They bring data to conversations and help engineers, designers, and PMs put actual numbers to decisions and trade-offs. I think the formality of sprints is way overblown, but the cadence of them can be extremely valuable. Having stakeholders come together to discuss and tweak plans is super helpful. Ideally, _tweak_ is the keyword. If you have major changes sprint-to-sprint, something else is wrong. In most cases, the discussion goes something like this: * (A) We're on track. Everything is going well. Here's what's outstanding. If we get that done, what do we want to stretch for? * (B) We've had some problems/things aren't moving as fast as we thought. Here's why. What should we do about it.
janosdebugs 3y ago
If you have a technical client, they will understand. If you don't, nothing in the world will make them understand. Ship a build too early and they will start complaining about superficial things that are on your todo list. Plus, nothing prevents you from shipping regular builds to the client without sprints either. It's often a good idea to set up nightly builds and make sure they are never broken. As you said, your PM or whatever you call them can still have calls with them, but there is no point in wasting the time of however many engineers work on it to regularly attend those calls.
Cthulhu_ 3y ago
Counterpoint: The other reason for scrum style sprints is predictability. You can set deadlines like "feature X needs to be done by August", but that leads to overworking, cutting corners, etc. You can instead set the scope / features - like you said, a browser has a long list of features that need to be built - apply a score / weight to them (story points), work in iterations, see how much of that relative score is done per iteration, then plot that so you can say "If we keep going like this, feature X will be done by August". And if it needs to be done sooner, the project manager just has to put it higher up in the list.
- jraph 3y ago
  I see an argument for estimating tasks here, not for sprints. You can track progress on these tasks without sprint. Of course, this tracking needs to happen regularly and sprints is a possible implementation of this but you can do it without them.

by jraph 3y ago

demondemidi 3y ago

I dislike sprints but have not seen a better alternative for teams of 50+ people.

HumanOstrich 3y ago
What about smaller teams?
- hanniabu 3y ago
  Rolling kanban
jraph 3y ago
I've only worked in small teams. Could one possible answer be to spit such big teams into smaller teams and organize / structure the project so that teams can be relatively autonomous?
caskstrength 3y ago
> I dislike sprints but have not seen a better alternative for teams of 50+ people. Team of 50+ people?! I wonder how do your Scrums look like. Is the work day over by the time you finish it?
Cthulhu_ 3y ago
That isn't a team, that's a department; I presume those people are either explicitly or implicitly divided into smaller teams / responsibilities?

dragonwriter 3y ago

> Sprints are for having a fast feedback + adjustments loop with a customer whose needs are unclear Do they add any value there compared to having the same cadence of customer contact, while dev happens in a flow-based (kanban, etc.) model with as-ready delivery of value-producing units of work (i.e., stories) as completed? I get that historically sprints were adopted as a way to do incremental, fast-feedback delivery as an alternative to “deliver at the end” project styles, and as an alternative to that, they seem to make sense. But they still incorporate the “deliver at the end” mindset, just with arbitrarily timeboxed aggregates of what is otherwise conceived as independent units of work. And if you’ve got independent, value-delivering units of work, its not too long until you realize that those are your natural and irreducible “deliver at the end” units.

datadrivenangel 3y ago
Kanban is the way. Keep things flowing.
jraph 3y ago
> having the same cadence of customer contact, while dev happens in a flow-based (kanban, etc.) model with as-ready delivery of value-producing units of work (i.e., stories) as completed? I'm currently on a project that works like this, without sprints, and clearly it works for us. Also, no standups. We communicate as soon as it's needed and not more (often) than needed.
fnordpiglet 3y ago
Planning should be a continuous and real time endeavor; and planning without your stakeholders input is a plan to fail.
SkyPuncher 3y ago
I've found them incredibly useful for getting teams to be realistic about their bandwidth and throughput. They bring data to conversations and help engineers, designers, and PMs put actual numbers to decisions and trade-offs. I think the formality of sprints is way overblown, but the cadence of them can be extremely valuable. Having stakeholders come together to discuss and tweak plans is super helpful. Ideally, _tweak_ is the keyword. If you have major changes sprint-to-sprint, something else is wrong. In most cases, the discussion goes something like this: * (A) We're on track. Everything is going well. Here's what's outstanding. If we get that done, what do we want to stretch for? * (B) We've had some problems/things aren't moving as fast as we thought. Here's why. What should we do about it.

janosdebugs 3y ago

If you have a technical client, they will understand. If you don't, nothing in the world will make them understand. Ship a build too early and they will start complaining about superficial things that are on your todo list. Plus, nothing prevents you from shipping regular builds to the client without sprints either. It's often a good idea to set up nightly builds and make sure they are never broken. As you said, your PM or whatever you call them can still have calls with them, but there is no point in wasting the time of however many engineers work on it to regularly attend those calls.

Cthulhu_ 3y ago

Counterpoint: The other reason for scrum style sprints is predictability. You can set deadlines like "feature X needs to be done by August", but that leads to overworking, cutting corners, etc. You can instead set the scope / features - like you said, a browser has a long list of features that need to be built - apply a score / weight to them (story points), work in iterations, see how much of that relative score is done per iteration, then plot that so you can say "If we keep going like this, feature X will be done by August". And if it needs to be done sooner, the project manager just has to put it higher up in the list.

jraph 3y ago
I see an argument for estimating tasks here, not for sprints. You can track progress on these tasks without sprint. Of course, this tracking needs to happen regularly and sprints is a possible implementation of this but you can do it without them.