Chrome was delivered without any sprints at all (2021)

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‽<p>As for the rest of it, it seems like you can summarise the whole thing as <i>“it’s good to have experienced team members”</i>? Sure, but I don’t see why that’s a particularly novel insight.

What a bogus claim. <i>No piece of working software of any merit was ever written before Agile!</i><p>... um, I joke, but this is the attitude I see from every proponent of agile. &quot;How can a team <i>possibly</i> deliver a product on time without sprints and ceremonies&quot;? I&#x27;ve seen serious discussions about whether to use &quot;Kanban&quot; or &quot;Scrum.&quot; They&#x27;re completely different, you see: one has 4 columns for your open&#x2F;to-do&#x2F;in-progress&#x2F;complete tasks, whereas the other has a list view for your open&#x2F;to-do&#x2F;in-progress&#x2F;complete tasks!<p>&quot;Agile&quot; has bugged the hell out of me the last 13 years, and one of the main reasons is that the people who push for this the loudest, have never deployed a line of code in their lives: Project Managers and their ilk. Their livelihood depends on owning a process and reporting the state transitions of the actual engineering work.<p>I&#x27;m forced to have 2-week sprints at my company, and I just realized today that the Sprint Planning calendar entry --which I own for my team-- had expired a couple of weeks ago. Of course, no one on the team noticed because we&#x27;re actually heads down merging code. But I&#x27;m sure the PMs will freak out.<p>Now, all that said, I do support teams meeting every 2 weeks to review tasks and priorities. That&#x27;s fine. But do we have to pretend that&#x27;s &quot;Agile&quot;?

I think the main issue with sprints is that people start feeling like robots. This hampers creativity and drive immensely. I&#x27;ve been in ste software industry for a good 15+ years and I have never observed the opposite. People start doing pointless busywork like ticket engineerinf instead of being enthusiastic about what they do and working towards that. I&#x27;ve had the displeasure of witnessing several teams die once Scrum was forced on them or they decided to switch themselves.

edit: whoops, it seems the author uses &quot;sprint&quot; to say something else than the agile stuff [1]. So this comment is a bit out of topic.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37142781">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37142781</a><p>---<p>I strongly dislike sprints, but I would be open to discussion about them in a client project.<p>For something like Chrome which isn&#x27;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.<p>Sprints are for having a fast feedback + adjustments loop with a customer whose needs are unclear &#x2F; 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&#x27;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.<p>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&#x27;t necessarily fit in two weeks… in two week chunks, and I don&#x27;t see the need for this in such a setting.<p>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).

A project may or may not use sprints for assigning and tracking tasks.<p>A project may or may not have a lot of senior engineers with hands on involvement.<p>A project team may or may not be worked to the bone to meet tight deadlines.<p>A project may or may not be ultimately successful.<p>These are all independent variables that the author seems to be conflating into one.<p>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.

Note: &quot;sprints&quot; in this context means &quot;crunch&quot;.<p>From the tweetstorm the article quotes:<p>&gt; 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!

It seems that the main and only problem &quot;solved&quot; by SCRUM is the awkward situation where a freelance-team or solo developer happily present the result of their (web-, ux-, app-)implementation that took them half a year, the customer realizes they wanted something else and both are angry at each other.<p>So now SCRUM has a feedback cycle that prevents that from happening.<p>It makes sense for UX and interaction-heavy parts, but not at all for systems and backend programming, which are much harder to divide into a workable backlog.

Does &quot;sprint&quot; mean something other than &quot;chunk of work, usually 2-4 weeks in duration&quot;?

It&#x27;s a big project; they had senior developers with experience in building browsers, who realised that this would all of that plus the rest. They also knew that the 1.0 release would only be the beginning of the project, so the setup needed to be good, and the development practices needed to be sustainable.<p>This differentiates senior developers from the rest I think. Mind you, I can also understand why a lot of people - myself included - think &quot;what&#x27;s the point&quot;, given how (in my own experience), a lot of software - mainly front-end - is replaced every 5 years, and major architecture overhauls every 10.<p>My current employers is currently replacing their SAP-to-API middleware with some commercial point-and-click software to, drumroll please, AWS lambda functions written in Typescript. It&#x27;s an improvement, because there&#x27;s more transparency and performance measurement instead of things hidden behind a GUI, but it&#x27;s also a risk because it&#x27;s set up by consultants who will eventually move on to somewhere else.<p>Already there was suddenly a presentation that came across as Authoritative about how they have Chosen to use Kotlin. I don&#x27;t know for sure if that was to replace typescript but... it really doesn&#x27;t matter to me tbh.

Reading the comments to this submission made painfully clear that a significant portion of HN commenters are posting their opinions without even reading the linked article first.

I&#x27;m not a big fan of agile, but right off the bat it seems clear that the author doesn&#x27;t know what sprints are.

Not as a counterpoint but just to add some context: I used Chrome when it just came out. For a week. Couldn&#x27;t stand it any longer - it was buggy as hell. Of course, now it is polished and the user experience is completely different.

Moral of the story: start with someone else&#x27;s open source project.

Major software projects can&#x27;t be built in 2-4 weeks.<p>They&#x27;re still inherently iterative though, so keeping iterations relatively small is valuable.

I don&#x27;t think that is what a death march means.<p>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.<p>Sprint is just a project management style which is appropriate when a lot of things are uncertain (e.g. user need, budget).

You must understand that twitter is rewarding views&#x2F;conversation to &#x27;creators&#x27; via subscription. You must have noticed an uptick of blue tick accounts who drivel lame information but packed to stroke a conversation. This way they get payouts from twitter creator program due to engagement and impressions.<p>The blue tick also puts them on top of conversations; this is now used by Russians to create divisions in democracies with paid and useful idiot(s) accounts. For Elon, who is living in a selfish bubble, that is free speech and he keeps reposting conspiracy theorist.<p>In short, the whole platform is going to the gutter. Being a champion of the Internet from the late 90&#x27;s, I can&#x27;t believe where we are at now and how non-scientific fervor has grabbed every aspect of discourse (anti vax, flat earth, soros&#x2F;gates, Q&#x2F;Pizza&#x2F;MAGA, etc).