Chrome was delivered without any sprints at all (2021) • Hacker News Board

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

#101

Post by Cthulhu_ » Wed, Aug 16, 2023, 8:31 AM UTC

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

This differentiates senior developers from the rest I think. Mind you, I can also understand why a lot of people - myself included - think "what's the point", given how (in my own experience), a lot of software - mainly front-end - is replaced every 5 years, and major architecture overhauls every 10.

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's an improvement, because there's more transparency and performance measurement instead of things hidden behind a GUI, but it's also a risk because it's set up by consultants who will eventually move on to somewhere else.

Already there was suddenly a presentation that came across as Authoritative about how they have Chosen to use Kotlin. I don't know for sure if that was to replace typescript but... it really doesn't matter to me tbh.

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

#102

Post by eternityforest » Wed, Aug 16, 2023, 8:51 AM UTC

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 purpose, as I've seen(I've never done true formal agile but I think it influenced some of the people I worked) is that some businesspeople seem to like to see constant visible progress.

4 days is too long for them to wait, they get antsy and think nothing is happening if you can't actually show them something they can understand in a day or two.

I think it actually affects the code, everything has to be taped together tiny bits, because you can never do anything that doesn't show results fast, so you if you need a framework or an architecture or a plugin system, it's really hard.

But agile says that's fine because you're going to be doing first drafts and throwing away code anyway....

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

#103

Post by fzeindl » Wed, Aug 16, 2023, 10:39 AM UTC

Cthulhu_ wrote: post #95

fzeindl wrote: post #39

It seems that the main and only problem "solved" 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. So now SCRUM has a feedback cycle that prevents that from happening. It makes sense for UX and interaction-heavy part…

It makes sense for back-end too though, especially in the context of a larger organization. Teams A, B and C need features X, Y and Z from the back-end team. Back-end team says they will cost 3, 5 and 8 story points respectively. Back-end team's product owner talks to the teams to ask about priority. Z is planned for next sprint, X and Y for the one after. Teams A, B and C plan their work that depends on those featur…

I am glad to hear that you use 3-week sprints. 2 week sprints are too short, yet everyone uses them without questioning.

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

#104

Post by yc-kraln » Wed, Aug 16, 2023, 10:56 AM UTC

Cthulhu_ wrote: post #94

khazhoux wrote: post #22

What a bogus claim. No piece of working software of any merit was ever written before Agile! ... um, I joke, but this is the attitude I see from every proponent of agile. "How can a team possibly deliver a product on time without sprints and ceremonies"? I've seen serious discussions about whether to use "Kanban" or "Scrum." They're completely different, you see: one has 4 columns for your open/to-do/in-progress/comp…

Counterpoint, the people that strongly oppose agile practices the loudest have never managed a software project in their lives. In your case, you've CHOSEN to ignore the scrum practices in favor of nose-to-the-grindstone death march. If your company says "we do scrum", that gives you and your team ammunition to say "no". Or in other words, poor planning on management's side does not constitute an emergency on yours.…

Hey, so, I have managed a ton of software projects. I strongly oppose Agile, "agile" and nearly every variation thereof (SAFe is the worst). Not every software project is a website contracted to an agency for the lowest possible cost, and any software of any consequence has a lifetime of decades, not minutes, so "working code over documentation" is a fundamentally flawed basis, before getting into any of the other bullshit cargo-culting nonsense that flows from the agile methodology.

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

#105

Post by janosdebugs » Wed, Aug 16, 2023, 12:07 PM UTC

Cthulhu_ wrote: post #89

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

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 them with unnecessary red tape. A good example for how this can work is how Valve [1] supposedly works: true multidisciplinary teams that are empowered to organize and work on a project as they see fit. This was the only way I saw teams work truly efficiently.

If management needs to know exactly when a project is finished, they just need to agree on a deadline with the team. Scrum isn't there to provide that, nor did I ever see it work. However, I have seen a lot of wishful thinking and make-believe metrics such as managers making up a project to be "5000 story points" out of thin air (based on 1-2% of the project being spec'ed out, even less being completed) and then doing deadline calculations based on that.

[1]: Valve handbook for new employees, page 16, https://www.valvesoftware.com/en/publications

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

#106

Post by 9659 » Wed, Aug 16, 2023, 12:41 PM UTC

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…

"an increase in velocity should come natural as your codebase expands"

you may not respect academic software engineering, but if this is true you have just created a perpetual motion machine.

changing / adding software to a system becomes more expensive (takes more time) as the size of the system increases. and it is not linear.

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

#107

Post by 9659 » Wed, Aug 16, 2023, 12:51 PM UTC

yc-kraln wrote: post #104

Cthulhu_ wrote: post #94

Earlier quoted context omitted.

Counterpoint, the people that strongly oppose agile practices the loudest have never managed a software project in their lives. In your case, you've CHOSEN to ignore the scrum practices in favor of nose-to-the-grindstone death march. If your company says "we do scrum", that gives you and your team ammunition to say "no". Or in other words, poor planning on management's side does not constitute an emergency on yours.…

Hey, so, I have managed a ton of software projects. I strongly oppose Agile, "agile" and nearly every variation thereof (SAFe is the worst). Not every software project is a website contracted to an agency for the lowest possible cost, and any software of any consequence has a lifetime of decades, not minutes, so "working code over documentation" is a fundamentally flawed basis, before getting into any of the other bu…

you identified the exact problem. developing a website with very inexperienced people? requirements very fluid from the customer (they know what they want when they see it)?

agile, as practiced today, is the way to go.

building a defined system with performance requirements? with a budget? using staff that understands the technology?

something else, is the way to go.

in my experience, a short requirements exercise (say 10% of the expected project duration), followed by development iterations, is the way to go. how long are the iterations? between 2 weeks and 3 months.

take time for design. have milestones where the system is functional and stakeholders can interact. but not continuously.

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

#108

Post by mgarstecki » Wed, Aug 16, 2023, 1:15 PM UTC

geodel wrote: post #44

psunavy03 wrote: post #43

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…

I think it is wrong to look for "true agile", as it's not a set of checkboxes to fill. I agree with other comments that sprints, backlogs, etc. are just tools to pick from based on the problems you're facing. You see them proposed time and again because many organizations face the same, boring problems as everyone.

To me, the only one true principle of Agile is to: - Always take time to reflect on the way you and your team work - Discuss openly if it's appropriate or not - Be ready to accept ANY solution that is discussed, be it organizational, technical, or self-improvement.

I would even go as far as calling it a basic principle of engineering. It is very simple to state, but very hard to implement due to our human nature (ego and feelings get in the way of open discussion and self-change) and budgets (taking time to discuss and implement change feels like a cost to most management, not added value).

There were examples of this principle and mindset in many organizations long before Agile was codified, and it can actually cause valuable results in organizations that look nothing like the stereotype of Agile !

For example, the NASA software department was famous for stopping all developments any time their QA detected any bug, and taking the time needed to ensure this kind of bug can never be committed again in the future. This kind of behavior is extremely Agile to me : continually improving your process to match your requirements. It is very slow and expensive for them, but it matches the stakes (potential loss of lives).

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

#109

Post by BaseballPhysics » Wed, Aug 16, 2023, 1:49 PM UTC

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.

First, that wasn't my question, nor was it you I was asking. But sure, let's go with this.

Frankly, this reeks of empty cynicism and we can do better than that around here.

Your experience is also far from universal. In my previous company I was part of the leadership core and not only did teams have agency to decide what process to use, we were actively encouraging teams to consider alternatives since our practices had become pretty frozen over time (old habits, etc).

Maybe your problem is you just found yourself at shitty companies. The world is a big one out there.

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

#110

Post by coldtea » Wed, Aug 16, 2023, 2:29 PM UTC

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. Sprints are just a way of breaking up work into discrete periods of time.

That's already the same as saying "A, B, and C parts will be done in that period of time, then C, D, E, F" and so on.

So you already pressupose what's to be done by when. And even if you roll-over tasks that haven't been completed to the next sprint, you still have this concept of falling behind (which is what "talking about why you failed the Sprint doing the retro" reinforces - and that invariably will lead to death marches and the fool's errand of "doing a better job of allocating work in the next sprint").

Whereas what they describe is "A (or B or C...) will be done when it is done, and the same holds for the whole project".

So they work everyday 9-5, give it their best shot, and it is completed day by day, with no arbitrary deadline to have A, B, C parts completed by.

If by using sprints you're going to do the exactly same thing (just work 9-5 everyday, and your project is ready when it's ready), then you don't need sprints.

Sprints only make sense when you don't plan on doing that, but to use them as a yardstick of being on some schedule or falling behind, and as a way to force developers to work overtime to "keep up with the planning".