Live data from Hacker News

Chrome was delivered without any sprints at all (2021)

twitter.com

41–50 of 120 posts

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

#41

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

At every former company, where we tried to use Agile or sprints, we ended up reaching a system where we just had basically "one big rolling sprint". Every two weeks, only a few tasks were actually done, and every task got pulled into the next "sprint". Combine this with the fact that we weren't delivering any artifacts at the end of the sprint, so we didn't have any feedback from stakeholders and weren't really itera…

> we ended up reaching a system where we just had basically "one big rolling sprint".

But there’s no such thing as “one big rolling sprint” though. If it’s “one big rolling…” then it can’t be a sprint. It’s like dehydrated water. It’s conceptually incoherent.

To untangle the wording of this, when you say your process became “one big rolling sprint”, what you’re actually saying is that you stopped using sprints, aren’t you?

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

#42

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

At every former company, where we tried to use Agile or sprints, we ended up reaching a system where we just had basically "one big rolling sprint". Every two weeks, only a few tasks were actually done, and every task got pulled into the next "sprint". Combine this with the fact that we weren't delivering any artifacts at the end of the sprint, so we didn't have any feedback from stakeholders and weren't really itera…

Sounds like you would've been better off with kanban. Did you ever consider switching?

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

#43

Earlier quoted context omitted.

"Every" is a pretty big word, and it's a pretty immature attitude to write off whole groups of people. You also don't seem to have much understanding of any of the key concepts of Scrum, Agile, or Kanban beyond "merging code is all that matters!" News flash: you "merge code" for a business who has business requirements and customers, and if you ship the wrong stuff, all you've accomplished is lighting lots of money o…

> "Every" is a pretty big word, and it's a pretty immature attitude to write off whole groups of people. "Every" usually doesn't literally mean "every", but I'm sorry that my experience across several large companies is that the people that demand following "Agile Ceremonies" are by-and-large Project Managers, and (with rare exception) not the engineers or the technical eng managers. I've seen this at multiple large…

2-week sprints are neither always necessary nor required. And yes, there are unfortunately plenty of inflexible idiots pushing cookie-cutter methods like that in industry because they don't understand the deeper reasons behind what they're asking, such as empirical process control theory and the behavior of complex adaptive systems.

But what's equally ad hominem is this implication that every agilist is this incompetent, that no one who goes by that term has ever deployed code, or that Agile as an approach is always wrong and always inhibits delivering good software. THAT is immature. That's taking bad implementations and generalizing them to say that every implementation is automatically bad. Just because the Detroit Lions are historically horrible isn't empirical proof that it's impossible to play good football.

Agile is not two-week sprints. Agile is not daily standups. These are tools which may or may not be appropriate in a given context. Agile is a mindset, not a strict process, and it was originally developed by engineers for engineers. The fact that you're even bringing "Project Managers" into the discussion is telling, because that is not a role which exists in any credible Agile organization, and for good reason.

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

#44

Earlier quoted context omitted.

> "Every" is a pretty big word, and it's a pretty immature attitude to write off whole groups of people. "Every" usually doesn't literally mean "every", but I'm sorry that my experience across several large companies is that the people that demand following "Agile Ceremonies" are by-and-large Project Managers, and (with rare exception) not the engineers or the technical eng managers. I've seen this at multiple large…

2-week sprints are neither always necessary nor required. And yes, there are unfortunately plenty of inflexible idiots pushing cookie-cutter methods like that in industry because they don't understand the deeper reasons behind what they're asking, such as empirical process control theory and the behavior of complex adaptive systems. But what's equally ad hominem is this implication that every agilist is this incompet…

> Agile is a mindset, not a strict process, and it was originally developed by engineers for engineers. The fact that you're even bringing "Project Managers" into the discussion is telling,

I think true Agile and agile organization are big foot that common people like me have never seen. Only enlightened Agilist understand the meaning of:

Agile is Nothing, Nothing is Agile. If scrum is not enough have scrum of scrums if scrum of scrum is not enough have scrum of scrum of scrums (duh).

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

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

The root of most of what we call 'Agile' today goes back to a method for managing difficult clients when doing (primarily web development) consulting.

If you're not a consultant or you're not trying to defensively manage a difficult client then it's a poor set of processes for your development work to follow.

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

#46
post #36

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!

Microsoft is such a strange company. For the people I know who worked there, it was allegedly almost a vacation. Why is there so much difference in work load in different teams?

It's a very large company. Each org/vertical might as well be it's own company, and it was just that disconnected and isolated from each other.

There are entire teams maintaining ancient products that I've never heard of and there are teams working on cutting edge stuff in their vertical or industry.

Culture similarly varied widely between orgs. I moved from a very chill team to one in azure. It was the same as moving to a different industry altogether

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

#47

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

As someone who developes software I can tell you that I have seen those three work:

A) if I am motivated, in the mood and it is my project I can program a thing in one go (e.g. if I have no dayjob, healthy breaks, time for sports, etc)

B) One of my employers wanted software, while my dayjob was something else. I told them I can do it if I get a fixed day on which my other responsibilities don't need to be taken care of. After half a year the project was finished. The biggest delaying factor were external partners who used the "sprint" model.

C) I do my current private project on two mornings in the week before work when I have time, it makes good progress.

If you need to constantly crunch to finish things you are either bad at management or you have perpetual bad luck, one of which is more likely.

Everything if done well takes a certain amount of time. And because things never go as planned and requirements change you can multiply that time by the value of pi. Additionally you should ensure that time is actually available for your employees and not something where they need to fulfill other crap (especially not your crap). If your employees are not totally incompetent (your responsibility again), you should be able to finish that project without a single hour overtime or any need to crunch at all.

The problem starts when managers confuse how long they wish something would take with how long something actually takes. Often managers promise things go faster because they don't dare to break the illusions of their superiours (or gamble on the slim chance that they can whip their team into finishing faster to then reap the fruit of that success).

Things take as long as they take. Multiply by arbitrary, pessimistic safety factors, you will finish it slow and steady on time, while still leaving space to try some things out.

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

#48

Earlier quoted context omitted.

At every former company, where we tried to use Agile or sprints, we ended up reaching a system where we just had basically "one big rolling sprint". Every two weeks, only a few tasks were actually done, and every task got pulled into the next "sprint". Combine this with the fact that we weren't delivering any artifacts at the end of the sprint, so we didn't have any feedback from stakeholders and weren't really itera…

> we ended up reaching a system where we just had basically "one big rolling sprint". But there’s no such thing as “one big rolling sprint” though. If it’s “one big rolling…” then it can’t be a sprint. It’s like dehydrated water. It’s conceptually incoherent. To untangle the wording of this, when you say your process became “one big rolling sprint”, what you’re actually saying is that you stopped using sprints, aren’…

How can it be a sprint if nobody is running? /s

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

#49
post #44

Earlier quoted context omitted.

2-week sprints are neither always necessary nor required. And yes, there are unfortunately plenty of inflexible idiots pushing cookie-cutter methods like that in industry because they don't understand the deeper reasons behind what they're asking, such as empirical process control theory and the behavior of complex adaptive systems. But what's equally ad hominem is this implication that every agilist is this incompet…

> Agile is a mindset, not a strict process, and it was originally developed by engineers for engineers. The fact that you're even bringing "Project Managers" into the discussion is telling, I think true Agile and agile organization are big foot that common people like me have never seen. Only enlightened Agilist understand the meaning of: Agile is Nothing, Nothing is Agile. If scrum is not enough have scrum of scrums…

[flagged]

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

#50

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

And this is why many agilists prefer to use the term "iteration," because "sprint" can be conveniently "misinterpreted" by toxic managers.

On that very note:

https://www.youtube.com/shorts/liUiRfN9NzQ

Post reply on HN