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

71–80 of 120 posts

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

#71

Post by mjfisher »

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…

The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery.

However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one.

It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E.g. if an engineer has ten days available to work in a sprint, no more than 7 days of estimated work are pushed their way. The other 30% is assumed to be code reviews, meetings, pairing, bugfixing etc.

If that 70% is too high or low, it can be adjusted.

For everything else, there's Kanban.

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

#72

Post by Sosh101 »

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…

I have experienced this too.

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

#73

Post by fulafel »

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…

The word "sprint" has meanings outside of Scrum, I think it's used here in the dictionary meaning.

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

#74

Post by jjav »

mjfisher wrote: post #71
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 rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery. However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one. It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E…

> If it won't fit comfortably in the sprint it waits for the next one.

That will never be how it's done. You work on it however long you can on this sprint and then finish it in the next one. So now you have two choices: either break it down in a completely arbitrary way into two stories, one for each sprint. Or just completely ignore the sprint boundary nonsense and just work on it.

Either way, it highlights how dumb it is to put silly boundaries on work delivery. Accomplishes nothing other than to waste people's time.

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

#76

Post by memefrog »

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…

You're confusing etymology and meaning. The fact that 'sprint', in completely different usage, has that meaning, does not mean any of that connotation carries over to this context.

There is a clear rational purpose to breaking tasks up into parts. There are atomic units of work. Very few tasks can't be broken up into two-week segments.

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

#77

Post by js8 »

jimbob45 wrote: post #70
BaseballPhysics wrote: post #42

Earlier quoted context omitted.

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

In my experience, the people choosing between Scrum and Kansan are not the ones participating in the Scrum/Kanban. Modern leadership attempts to take away as much agency as possible and wonders why everyone hates them.

> Modern leadership attempts to take away as much agency as possible and wonders why everyone hates them.

Not that I disagree, but I think it's not modern. In the past, it was probably simply much more accepted that the agency is taken away by authorities, that's just how life is. I think people grew much less tolerant of that recently (which honestly I think is a good development), and more willing to question authorities in general. The hate part then comes from nostalgia.

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

#78

Post by mjfisher »

jjav wrote: post #74
mjfisher wrote: post #71

Earlier quoted context omitted.

The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery. However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one. It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E…

> If it won't fit comfortably in the sprint it waits for the next one. That will never be how it's done. You work on it however long you can on this sprint and then finish it in the next one. So now you have two choices: either break it down in a completely arbitrary way into two stories, one for each sprint. Or just completely ignore the sprint boundary nonsense and just work on it. Either way, it highlights how dum…

Sorry, but that blanket statement is just wrong. That is _exactly_ how it's done when I run a scrum team. If it stops being a good fit or working well for any number of reasons, we stop and look at the process.

It works because your stakeholders see that you're actually delivering what you said you would _when_ you would, and that gets you the buy in and authority to run the team in a sane and sustainable manner.

For what it's worth, I prefer Kanban in most cases - but both are just different ways of managing WIP, utilisation and delivery time.

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

#79

Post by Cthulhu_ »

audiodude wrote: post #29
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…

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…

That sounds like a lack of discipline and retrospection. This is also the problem I have with scrum; people don't stick to the process, and cite how the agile manifesto says that the process isn't important.

But this is a misconception. Stick to the process (religiously) at first, then assess how it works.

In this case: you did not meet your sprint goals, which either meant you overcommitted (meaning the next sprint you pick up less work), the tasks did not meet the definition of ready (that is, they could not be finished in a single sprint), or you had impediments that weren't solved on time. All of those need to be spoken out loud during a retrospective session, and action undertaken.

Not having any artifacts isn't the issue, you still need to set a moment to stop your work, review what has been done, consider what went well and what could be better, learn and improve.

If the learning is that scrum doesn't work for you - and you can show that you did it properly - then there's other processes that might work better for you, as suggested.

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

#80

Post by siva7 »

audiodude wrote: post #29
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…

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…

That’s a sign of ineffective product management and bad feedback culture. When the foundation lacks, agile can’t be done successfully. I’ve seen what you described a few times but also many times where it works as long as the foundation is good.
Post reply on HN