Chrome was delivered without any sprints at all (2021)
1–10 of 120 posts
Re: Chrome was delivered without any sprints at all (2021)
#2edit: 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
---
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).
Re: Chrome was delivered without any sprints at all (2021)
#3Does "sprint" mean something other than "chunk of work, usually 2-4 weeks in duration"?
Re: Chrome was delivered without any sprints at all (2021)
#4Does "sprint" mean something other than "chunk of work, usually 2-4 weeks in duration"?
It depends. In theory, it means a process in terms of how work is assigned, resolved and reviewed. In reality, it's meeting seems to be completely different between different organizations.
Re: Chrome was delivered without any sprints at all (2021)
#5edit: 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 --- 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 adjus…
> 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.
Re: Chrome was delivered without any sprints at all (2021)
#6edit: 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 --- 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 adjus…
I dislike sprints but have not seen a better alternative for teams of 50+ people.
Re: Chrome was delivered without any sprints at all (2021)
#7Major software projects can't be built in 2-4 weeks.
They're still inherently iterative though, so keeping iterations relatively small is valuable.
Re: Chrome was delivered without any sprints at all (2021)
#8edit: 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 --- 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 adjus…
> 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 deliver…
Kanban is the way. Keep things flowing.
Re: Chrome was delivered without any sprints at all (2021)
#9Does "sprint" mean something other than "chunk of work, usually 2-4 weeks in duration"?
Scrum :TM: has a sprint delivering a new increment to a working piece of software.
Re: Chrome was delivered without any sprints at all (2021)
#10edit: 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 --- 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 adjus…
> 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 deliver…
> 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.