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

111–120 of 120 posts

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

#111

Post by xeromal »

Cthulhu_ wrote: post #84
xeromal wrote: post #37

Earlier quoted context omitted.

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.

That sounds like heaven on earth. lol

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

#112

Post by antisthenes »

Cthulhu_ wrote: post #88
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

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

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

I think it's less about the language and more about being forward looking. You can't change what happened in the sprint, but you can do the next sprint better.

It's also about clear separation between identifying issues vs assigning blame. The latter doesn't help anyone, because blame is almost always backward-looking.

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

#113

Post by lamontcg »

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…

> If you don’t finish the work you had planned to during a sprint then you fail the sprint

that 'failure' bit right there is some bullshit that should get cut out.

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

#114

Post by lamontcg »

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…

Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.

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

#115

Post by jjav »

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 no sense, nobody works like that. And to be fair, shouldn't.

The next button is a 1 point story because the component is there already. Or not even 1 point, may get buried in a 1 point story to add ten new buttons.

> Scrum does NOT work with deadlines.

No true Scotsman, we're all holding it wrong.

Deadlines will be imposed from afar, in just about every company ever, and then the points will be attempted to be retrofitted to the predetermined plan.

When approximately everyone, for a couple decades now, is always "doing it wrong", it's time to acknowledge that the problem is the idea not the people holding it wrong.

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

This is how that goes:

PM: It'd be great if we had all the stories and their points in the place for the next quarter so we can predict good dates, get on that will you?

Eng: Awesome! So I'll need to plan out the work for the quarter, write stories and estimate them. Nice, will do that.

PM: NO! This is agile, don't ever look beyond this sprint. We don't do planning in agile. Just work on your microtask of the sprint, we'll worry about next sprint later.

Eng: Um, wait, what?

You might again say they're doing it wrong. There's no true agile scotsman.

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

#116

Post by zerbinxx »

lamontcg wrote: post #114
zerbinxx wrote: post #65

Earlier quoted context omitted.

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…

Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.

Sure. To me that sounds related to the “lack of backlog refinement” and “no AC” parts of this. If there’s no text on a ticket, there’s not even a map! Good luck with the territory, in that case.

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

#117

Post by zerbinxx »

rgblambda wrote: post #85
zerbinxx wrote: post #65

Earlier quoted context omitted.

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

Yeah. “We succeed and fail together” - unfortunately, unless this is true from a management and reward perspective, it can never be true at a team level. Additionally anything raised in a retro that contradicts a management edict will never see the light of day.

If your PM is appraised by Power Point quality or number of sprint points while engineers are managed by some other criteria, success and failure become asymmetrical and incentives clash.

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

#118

Post by lamontcg »

zerbinxx wrote: post #116
lamontcg wrote: post #114

Earlier quoted context omitted.

Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.

Sure. To me that sounds related to the “lack of backlog refinement” and “no AC” parts of this. If there’s no text on a ticket, there’s not even a map! Good luck with the territory, in that case.

That isn't really backlog refinement though. That is when you start actually doing the task and you realize that plan A and plan B of how to implement the fix or whatever can't work, and fixing it will necessarily be much more time intensive and some sort of plan C or plan D. Often this happens when you go to start changing code and you see how badly the tests blow up on you or something like that.

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

#119

Post by d3vmax »

JimDabell wrote: post #63
d3vmax wrote: post #62

You must understand that twitter is rewarding views/conversation to 'creators' 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. The blue tick also puts them on top of conversations; this is now used by Russians to create divisions in democrac…

This Twitter thread is two years old, posted long before Twitter’s current woes.

Yikes! My bad.

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

#120

Post by datadrivenangel »

janosdebugs wrote: post #105
Cthulhu_ wrote: post #89

Earlier quoted context omitted.

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

I don't think the 20% is a good solution because it requires engineers to compartmentalize. If the 20% is more interesting than the 80%, how are they going to do good work on the 80%? Plus, show me a manager that's happy to let an engineer take a few sprints of accrued 20% time off from the normal work. On the flip side, you can get most people to care about the engineering work they are doing if you don't burden the…

"we estimate that this project is 5000 story points"

"5000 story points Bob? What do you figure, is that a medium or a large t-shirt?, 2 or 3 quarters?"

"... Medium, but you know we don't like to acknowledge that quarters are 2500 story points... Agile, you know?"

"Oh I get it Bob"

Post reply on HN