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

81–90 of 120 posts

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

#81

Post by sirwhinesalot »

psunavy03 wrote: post #49
geodel wrote: post #44

Earlier quoted context omitted.

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

Agile is like communism, the only reason it never works is that Real(tm) Agile has never been tried. This is the argument you have been making this whole time while accusing the other commenter of flinging shit like a monkey.

(Edit: just to be clear, I'm a big proponent of the original agile manifesto. I'm pointing out what you are doing.)

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

#82

Post by verve_rat »

kanzenryu2 wrote: post #68
jjav wrote: post #58

Earlier quoted context omitted.

> They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. I don't think so. That's why sprints are so toxic. It's even right in the name. A 100m run is a "sprint", but nobody expects you to maintain that pace for a marathon. Much less for a multi-decade career. But in software you're expected to be in a sprinting pace all life long. And even increasing your "veloci…

The name sprint comes from rugby, and just refers to what the team would be doing together to succeed (sprinting to the other end of the field with the ball).

So what part is the dirty ruck where the people on the bottom get their eyes gouged, their heads stomped, and their nut sacks torn open?

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

#83

Post by Cthulhu_ »

jjav wrote: post #58
JimDabell wrote: post #13

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…

> They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. I don't think so. That's why sprints are so toxic. It's even right in the name. A 100m run is a "sprint", but nobody expects you to maintain that pace for a marathon. Much less for a multi-decade career. But in software you're expected to be in a sprinting pace all life long. And even increasing your "veloci…

But the term "sustainable pace" is also mentioned a lot in the literature.

An increase in velocity does NOT mean "work harder"; an increase in velocity should come natural as your codebase expands, you get more reusable components, your team gains experience, etc.

Example. New feature, estimated at 5 story points. One part is a button, takes you half a day to build it.

Next feature, very similar to the other one, 5 story points. But this time you have a button component already, so you can just reuse it. Same points delivered, less time spent, meaning you have time to pick up another story, meaning your velocity goes up.

Nobody, least of all proponents of scrum / agile methodologies, is saying that you should work harder, do a death march, etc. It acknowledges that software development is an infinite and long term process.

Scrum does NOT work with deadlines. It works with predictability; your team's average velocity and the story points of upcoming stories are known, it's then up to the product owner to set priorities if they need a feature live at a certain point in time. Missed deadlines then become bad planning and prioritization more than employees not working fast enough.

> There is not rational purpose to this.

Just to highlight this: The rational purpose to sprints is for project management to be able to look ahead and be able to say "we expect this feature to be done in X weeks time". It doesn't mean that a 4 day task should be done in 2 weeks. A sprint is just a unit of time, it isn't a promise.

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

#84

Post by Cthulhu_ »

xeromal wrote: post #37
JimDabell wrote: post #13

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…

I've been working since 2010 and every single company that drinks the agile coolaide has turned into a death march.

Same, but my experience isn't the same; in my experience it becomes boring because every sprint is the same, predictable, stable, little pressure, churn out one feature after the next. The companies may have drank the kool-aid but didn't let go of their existing management structures involving deadlines. And the developers / scrum masters / product owners / coaches did not protect their teams or processes.

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

#85

Post by rgblambda »

zerbinxx wrote: post #65
lionkor wrote: post #53

Earlier quoted context omitted.

Or you might have spillover because the team is very new and hasnt quite agreed on the value of a story point yet

There are a lot of reasons for spillover in my experience. They’re all interrelated. First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. They may love the glory of leading or assisting a team of software eng…

> First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results.

In my experience this rings true. Whenever I see a ticket with no description or acceptance criteria, a ticket that's blocked by another ticket in the middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?".

Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job.

But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.

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

#86

Post by sirwhinesalot »

Cthulhu_ wrote: post #83
jjav wrote: post #58

Earlier quoted context omitted.

> They seem to be using “sprint” and “death march” interchangeably. These are two entirely different concepts. I don't think so. That's why sprints are so toxic. It's even right in the name. A 100m run is a "sprint", but nobody expects you to maintain that pace for a marathon. Much less for a multi-decade career. But in software you're expected to be in a sprinting pace all life long. And even increasing your "veloci…

But the term "sustainable pace" is also mentioned a lot in the literature. An increase in velocity does NOT mean "work harder"; an increase in velocity should come natural as your codebase expands, you get more reusable components, your team gains experience, etc. Example. New feature, estimated at 5 story points. One part is a button, takes you half a day to build it. Next feature, very similar to the other one, 5 s…

> Next feature, very similar to the other one, 5 story points. But this time you have a button component already, so you can just reuse it. Same points delivered, less time spent, meaning you have time to pick up another story, meaning your velocity goes up.

This makes absolutely no sense to me and it is not how we do things at work. When the second task is estimated it will get a story point count of 1 because it's just copy pasting a button, not 5 which requires implementing a button from scratch.

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

#87

Post by caskstrength »

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

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

#88

Post by Cthulhu_ »

lionkor wrote: post #53
antisthenes wrote: post #32

Earlier quoted context omitted.

> 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 even "fail" the sprint, that's a bad attitude. You just consider work spilled over and take on less work + spillover work next sprint. There's only cause for concern if you repeatedly have spillovers every sprint - that's usu…

Or you might have spillover because the team is very new and hasnt quite agreed on the value of a story point yet

Whichever the reason: you don't use negative language. You didn't fail the sprint, you didn't have bad developers; you sit down and discuss what you can do better next time, for example: reduce your commitment, spend more time refining and preparing a story before estimating it, take up courses / do knowledge sharing, etc.

You never use language like "the sprint failed" or "what went wrong", you say "we underestimated", "there were unforseen circumstances", or "what can we do better".

I'm sure there's cynics in here that will have a benny about "soft language" and "the tofu-eating wokerati are at it again" or something, but it's not so much about language but mindset. "We failed" is giving up, "what can we improve" is taking ownership and action.

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

#89

Post by Cthulhu_ »

janosdebugs wrote: post #60

I think the main issue with sprints is that people start feeling like robots. This hampers creativity and drive immensely. I'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've had the displeasure of witnessing several teams die once Sc…

That was one of my early experiences with scrum too. That said, I get it; from a higher up management position point of view, scrum gives you stability and predictability, which is what you build businesses with. Unfortunately, most companies are like this.

But there should be space for creativity and originality as well. Since this article is about Google, back when they were still considered a great place to work, one major factor was their "20% time"; they acknowledge that most of the work is boring, so they gave you a day a week to work on more creative endeavours. Every software company should do this. Don't make it an occasional hackathon kinda thing, make it part of every sprint or week or month or whichever unit. Give people freedom to create, without expectations.

Because if you don't give them that space, they will take it.

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

#90

Post by Cthulhu_ »

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…

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.

Post reply on HN