Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome was delivered without any sprints at all (2021)

twitter.com

Post reply on HN
Print view View original

11–20 of 120 posts

Re: Chrome was delivered without any sprints at all (2021)

#11

Post by HumanOstrich »

demondemidi wrote: post #6
jraph wrote: post #2

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 --- 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.

What about smaller teams?

Re: Chrome was delivered without any sprints at all (2021)

#13

Post by JimDabell »

They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. Sprints are just a way of breaking up work into discrete periods of time. There’s nothing about them that implies “drama, broken marriages, or broken families”. If you don’t finish the work you had planned to during a sprint then you fail the sprint, talk about why during the retro, then do a better job of allocating work in the next sprint. You don’t ruin your marriage over it‽

As for the rest of it, it seems like you can summarise the whole thing as “it’s good to have experienced team members”? Sure, but I don’t see why that’s a particularly novel insight.

Re: Chrome was delivered without any sprints at all (2021)

#14

Post by jraph »

demondemidi wrote: post #6
jraph wrote: post #2

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 --- 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.

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?

Re: Chrome was delivered without any sprints at all (2021)

#16

Post by fnordpiglet »

dragonwriter wrote: post #5
jraph wrote: post #2

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 --- 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…

Planning should be a continuous and real time endeavor; and planning without your stakeholders input is a plan to fail.

Re: Chrome was delivered without any sprints at all (2021)

#17

Post by cachvico »

Note: "sprints" in this context means "crunch".

From the tweetstorm the article quotes:

> The Internet Explorer team was the hardest-working team I’ve ever been on. And I’ve worked at multiple start-ups. It was a sprint, not a marathon. We ate every meal at the office. We often held foosball tournaments at 2 am, just to get the team energy back up to continue working!

Re: Chrome was delivered without any sprints at all (2021)

#18

Post by paxys »

A project may or may not use sprints for assigning and tracking tasks.

A project may or may not have a lot of senior engineers with hands on involvement.

A project team may or may not be worked to the bone to meet tight deadlines.

A project may or may not be ultimately successful.

These are all independent variables that the author seems to be conflating into one.

As a counterexample I have worked on plenty of teams where we diligently used the agile methodology and everyone worked 9-5 and we were very successful with our product.

Re: Chrome was delivered without any sprints at all (2021)

#19

Post by ergocoder »

I don't think that is what a death march means.

A death march is a dead-end project where everyone thinks it likely fails, but nobody says anything. Everyone is still marching. This often happens with a migration-like project.

Sprint is just a project management style which is appropriate when a lot of things are uncertain (e.g. user need, budget).

Re: Chrome was delivered without any sprints at all (2021)

#20

Post by SkyPuncher »

dragonwriter wrote: post #5
jraph wrote: post #2

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 --- 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…

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.

Post reply on HN