8 ms·

Chrome was delivered without any sprints at all (2021)

92 points by celadevra_ 3y ago

hoten 3y ago
Does "sprint" mean something other than "chunk of work, usually 2-4 weeks in duration"?
- etchalon 3y ago
  It depends. In theory, it means a process in terms of how work is assigned, resolved and reviewed. In reality, it's meeting seems to be completely different between different organizations.
- datadrivenangel 3y ago
  Scrum :TM: has a sprint delivering a new increment to a working piece of software.
- jay_kyburz 3y ago
  Yeah, seems the author is using the term "sprint" to mean working more than 8 hours a day, not in the agile sense of short review cycle.
- fulafel 3y ago
  Yes: https://en.wiktionary.org/wiki/sprint https://en.wiktionary.org/wiki/sprint "A short race at top speed" (etc)
jraph 3y ago
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 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 adjusted, etc, I think sprints make no sense at all and are purely harmful. Sprints are for having a fast feedback + adjustments loop with a customer whose needs are unclear / where the budget is a forever negotiation depending on how the project advances. If you are building a product for which you have full control over the roadmap, you don't need the 2 week sprints. You can still experiment and get fast feedback on new features as you like, but not everything requires this fast feedback. The two week sprints are a strong constraint on your product development that might kill its long term stability because they require you to shoehorn maintenance tasks that don't necessarily fit in two weeks… in two week chunks, and I don't see the need for this in such a setting. Even in a client project, sprints can be avoided. A regular (e.g. weekly) call with the client to discuss progress and adjustments + releases when there is a need for them can work very well. I actually strongly believe the two week sprints are overkill, not enough flexible and harmful in many projects. Task assignment of course needs to be done carefully, but this work can be done asynchronously or as-needed (which, agreed, might work better for very small teams).
- demondemidi 3y ago
  I dislike sprints but have not seen a better alternative for teams of 50+ people.
  - HumanOstrich 3y ago
    What about smaller teams?
    - hanniabu 3y ago
      Rolling kanban
  - jraph 3y ago
    I've only worked in small teams. Could one possible answer be to spit such big teams into smaller teams and organize / structure the project so that teams can be relatively autonomous?
  - caskstrength 3y ago
    > 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?
  - Cthulhu_ 3y ago
    That isn't a team, that's a department; I presume those people are either explicitly or implicitly divided into smaller teams / responsibilities?
- dragonwriter 3y ago
  > 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 delivery as an alternative to “deliver at the end” project styles, and as an alternative to that, they seem to make sense. But they still incorporate the “deliver at the end” mindset, just with arbitrarily timeboxed aggregates of what is otherwise conceived as independent units of work. And if you’ve got independent, value-delivering units of work, its not too long until you realize that those are your natural and irreducible “deliver at the end” units.
datadrivenangel 3y ago
Major software projects can't be built in 2-4 weeks. They're still inherently iterative though, so keeping iterations relatively small is valuable.
- SkyPuncher 3y ago
  Most major projects can have an iteration delivered in 2 to 4 weeks. It might be a trivial component of the entire system, but it's still progress. I'm on a multi-month project. Our first sprint's goal is: * Get the repos in place. * Get a dummy endpoint running and deployed * Derisk some things on the FE It's not much different than building, say a house. You can demonstrate progress in small pieces. Foundation poured, framing up, roof on, sheathing on, etc, etc.
  - khazhoux 3y ago
    Those sound exactly like the things any team would do on a new project, regardless of calling it Agile, Scrum, Kanban, or whatever. I just don't see any difference between this and just having the philosophy: "Do first things first; do the next most important things next; don't bite off giant chunks but instead break them up."
    - crazygringo 3y ago
      Because lots of teams don't break things up. They do give giant chunks to each person, not check in, and then magically expect them all to integrate on the end and on time. This is precisely the common/naive practice that Agile/Scrum/Kanban/etc. is specifically reacting to.
      - SkyPuncher 3y ago
        Yep. This is exactly my experience. You don't need to get crazy about things, but having the defined time periods forces people to actually think about how they're going to deliver things.
    - Cthulhu_ 3y ago
JimDabell 3y ago
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 allocating work in the next sprint. You don’t ruin your marriage over it‽ As for the rest of it, it seems like you can summarise the whole thing as “it’s good to have experienced team members”? Sure, but I don’t see why that’s a particularly novel insight.
- psunavy03 3y ago
  And this is why many agilists prefer to use the term "iteration," because "sprint" can be conveniently "misinterpreted" by toxic managers.
  - fredrikholm 3y ago
    On that very note: https://www.youtube.com/shorts/liUiRfN9NzQ https://www.youtube.com/shorts/liUiRfN9NzQ
- audiodude 3y ago
  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 iterating either.
  - JimDabell 3y ago
    > 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?
cachvico 3y ago
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!
- mcny 3y ago
  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?
  - harshalizee 3y ago
    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
paxys 3y ago
A project may or may not use sprints for assigning and tracking tasks. A project may or may not have a lot of senior engineers with hands on involvement. A project team may or may not be worked to the bone to meet tight deadlines. A project may or may not be ultimately successful. These are all independent variables that the author seems to be conflating into one. As a counterexample I have worked on plenty of teams where we diligently used the agile methodology and everyone worked 9-5 and we were very successful with our product.
ergocoder 3y ago
I don't think that is what a death march means. A death march is a dead-end project where everyone thinks it likely fails, but nobody says anything. Everyone is still marching. This often happens with a migration-like project. Sprint is just a project management style which is appropriate when a lot of things are uncertain (e.g. user need, budget).
- hinkley 3y ago
  A death march is walking until you fall over dead. In code terms it’s busting your ass and hurting your health to try to push out a release - which may or may not connect with users.
- usefulcat 3y ago
  Disagree. I once worked at a place where 'death march' was an entirely appropriate description of a significant portion of the normal annual development cycle of a very successful product. Of course they didn't call it that, but that's exactly what it was nonetheless.
khazhoux 3y ago
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/complete tasks, whereas the other has a list view for your open/to-do/in-progress/complete tasks! "Agile" has bugged the hell out of me the last 13 years, and one of the main reasons is that the people who push for this the loudest, have never deployed a line of code in their lives: Project Managers and their ilk. Their livelihood depends on owning a process and reporting the state transitions of the actual engineering work. I'm forced to have 2-week sprints at my company, and I just realized today that the Sprint Planning calendar entry --which I own for my team-- had expired a couple of weeks ago. Of course, no one on the team noticed because we're actually heads down merging code. But I'm sure the PMs will freak out. Now, all that said, I do support teams meeting every 2 weeks to review tasks and priorities. That's fine. But do we have to pretend that's "Agile"?
- usefulcat 3y ago
  If you read TFA, it's abundantly clear that the author is talking about death marches (they even use that word), not the agile meaning of 'sprint'.
  - khazhoux 3y ago
    I'm talking about sprints, as is Boodman in the tweet. And having some proximal observation of the Chrome team at work, btw, Boodman is spot-on that that team kicked ass because they had awesome engineers and super-technical leadership.
- psunavy03 3y ago
  "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 on fire and wasting your professional life. It's a common attitude among immature devs who can't get beyond the whole "I have the most important job in the company" mindset. I'd expect it out of a junior dev, but someone who has 13 years of experience? That's not the flex you think it is.
deleted 3y ago
[deleted]
tgma 3y ago
Moral of the story: start with someone else's open source project.
- Cthulhu_ 3y ago
  Isn't that pretty much every software project these days? Be it language, libraries, frameworks, etc. It often feels like a lot of software development is duct taping different libraries together.
fzeindl 3y ago
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 parts, but not at all for systems and backend programming, which are much harder to divide into a workable backlog.
- Cthulhu_ 3y ago
  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 features accordingly. Everybody happy. We work with SAFe where that process of inter-team dependencies are formalized in quarterly "sprints" subdivided into 3-4 3-week team sprints. That's easy enough to explain at least, it's a shame the website makes it look so bad: https://scaledagileframework.com/ https://scaledagileframework.com/
  - fzeindl 3y ago
    I am glad to hear that you use 3-week sprints. 2 week sprints are too short, yet everyone uses them without questioning.
Spiwux 3y ago
Reading the comments to this submission made painfully clear that a significant portion of HN commenters are posting their opinions without even reading the linked article first.
- Cthulhu_ 3y ago
  This is the internet in a nutshell, and why crafting headlines and titles is an art, frequently used in "propaganda" to sway public opinion.
janosdebugs 3y ago
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 Scrum was forced on them or they decided to switch themselves.
- Sosh101 3y ago
  I have experienced this too.
- Cthulhu_ 3y ago
  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.
  - janosdebugs 3y ago
    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 https://www.valvesoftware.com/en/publications
d3vmax 3y ago
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 democracies with paid and useful idiot(s) accounts. For Elon, who is living in a selfish bubble, that is free speech and he keeps reposting conspiracy theorist. In short, the whole platform is going to the gutter. Being a champion of the Internet from the late 90's, I can't believe where we are at now and how non-scientific fervor has grabbed every aspect of discourse (anti vax, flat earth, soros/gates, Q/Pizza/MAGA, etc).
- modeless 3y ago
  What relevance does this have to a tweet from 2021?
- JimDabell 3y ago
  This Twitter thread is two years old, posted long before Twitter’s current woes.
  - d3vmax 3y ago
    Yikes! My bad.
- abwizz 3y ago
  we are experimenting with ways to have an inclusive global conversation. there will be many more failures
miked85 3y ago
I'm not a big fan of agile, but right off the bat it seems clear that the author doesn't know what sprints are.
chalcolithic 3y ago
Not as a counterpoint but just to add some context: I used Chrome when it just came out. For a week. Couldn't stand it any longer - it was buggy as hell. Of course, now it is polished and the user experience is completely different.
Cthulhu_ 3y ago
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.

92 points by celadevra_ 3y ago

hoten 3y ago

Does "sprint" mean something other than "chunk of work, usually 2-4 weeks in duration"?

etchalon 3y ago
It depends. In theory, it means a process in terms of how work is assigned, resolved and reviewed. In reality, it's meeting seems to be completely different between different organizations.
datadrivenangel 3y ago
Scrum :TM: has a sprint delivering a new increment to a working piece of software.
jay_kyburz 3y ago
Yeah, seems the author is using the term "sprint" to mean working more than 8 hours a day, not in the agile sense of short review cycle.
fulafel 3y ago
Yes: https://en.wiktionary.org/wiki/sprint https://en.wiktionary.org/wiki/sprint "A short race at top speed" (etc)

jraph 3y ago

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 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 adjusted, etc, I think sprints make no sense at all and are purely harmful. Sprints are for having a fast feedback + adjustments loop with a customer whose needs are unclear / where the budget is a forever negotiation depending on how the project advances. If you are building a product for which you have full control over the roadmap, you don't need the 2 week sprints. You can still experiment and get fast feedback on new features as you like, but not everything requires this fast feedback. The two week sprints are a strong constraint on your product development that might kill its long term stability because they require you to shoehorn maintenance tasks that don't necessarily fit in two weeks… in two week chunks, and I don't see the need for this in such a setting. Even in a client project, sprints can be avoided. A regular (e.g. weekly) call with the client to discuss progress and adjustments + releases when there is a need for them can work very well. I actually strongly believe the two week sprints are overkill, not enough flexible and harmful in many projects. Task assignment of course needs to be done carefully, but this work can be done asynchronously or as-needed (which, agreed, might work better for very small teams).

demondemidi 3y ago
I dislike sprints but have not seen a better alternative for teams of 50+ people.
- HumanOstrich 3y ago
  What about smaller teams?
  - hanniabu 3y ago
    Rolling kanban
- jraph 3y ago
  I've only worked in small teams. Could one possible answer be to spit such big teams into smaller teams and organize / structure the project so that teams can be relatively autonomous?
- caskstrength 3y ago
  > 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?
- Cthulhu_ 3y ago
  That isn't a team, that's a department; I presume those people are either explicitly or implicitly divided into smaller teams / responsibilities?
dragonwriter 3y ago
> 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 delivery as an alternative to “deliver at the end” project styles, and as an alternative to that, they seem to make sense. But they still incorporate the “deliver at the end” mindset, just with arbitrarily timeboxed aggregates of what is otherwise conceived as independent units of work. And if you’ve got independent, value-delivering units of work, its not too long until you realize that those are your natural and irreducible “deliver at the end” units.

datadrivenangel 3y ago

Major software projects can't be built in 2-4 weeks. They're still inherently iterative though, so keeping iterations relatively small is valuable.

SkyPuncher 3y ago
Most major projects can have an iteration delivered in 2 to 4 weeks. It might be a trivial component of the entire system, but it's still progress. I'm on a multi-month project. Our first sprint's goal is: * Get the repos in place. * Get a dummy endpoint running and deployed * Derisk some things on the FE It's not much different than building, say a house. You can demonstrate progress in small pieces. Foundation poured, framing up, roof on, sheathing on, etc, etc.
- khazhoux 3y ago
  Those sound exactly like the things any team would do on a new project, regardless of calling it Agile, Scrum, Kanban, or whatever. I just don't see any difference between this and just having the philosophy: "Do first things first; do the next most important things next; don't bite off giant chunks but instead break them up."
  - crazygringo 3y ago
    Because lots of teams don't break things up. They do give giant chunks to each person, not check in, and then magically expect them all to integrate on the end and on time. This is precisely the common/naive practice that Agile/Scrum/Kanban/etc. is specifically reacting to.
    - SkyPuncher 3y ago
      Yep. This is exactly my experience. You don't need to get crazy about things, but having the defined time periods forces people to actually think about how they're going to deliver things.
  - Cthulhu_ 3y ago

JimDabell 3y ago

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 allocating work in the next sprint. You don’t ruin your marriage over it‽ As for the rest of it, it seems like you can summarise the whole thing as “it’s good to have experienced team members”? Sure, but I don’t see why that’s a particularly novel insight.

psunavy03 3y ago
And this is why many agilists prefer to use the term "iteration," because "sprint" can be conveniently "misinterpreted" by toxic managers.
- fredrikholm 3y ago
  On that very note: https://www.youtube.com/shorts/liUiRfN9NzQ https://www.youtube.com/shorts/liUiRfN9NzQ
audiodude 3y ago
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 iterating either.
- JimDabell 3y ago
  > 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?

cachvico 3y ago

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!

mcny 3y ago
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?
- harshalizee 3y ago
  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

paxys 3y ago

A project may or may not use sprints for assigning and tracking tasks. A project may or may not have a lot of senior engineers with hands on involvement. A project team may or may not be worked to the bone to meet tight deadlines. A project may or may not be ultimately successful. These are all independent variables that the author seems to be conflating into one. As a counterexample I have worked on plenty of teams where we diligently used the agile methodology and everyone worked 9-5 and we were very successful with our product.

ergocoder 3y ago

I don't think that is what a death march means. A death march is a dead-end project where everyone thinks it likely fails, but nobody says anything. Everyone is still marching. This often happens with a migration-like project. Sprint is just a project management style which is appropriate when a lot of things are uncertain (e.g. user need, budget).

hinkley 3y ago
A death march is walking until you fall over dead. In code terms it’s busting your ass and hurting your health to try to push out a release - which may or may not connect with users.
usefulcat 3y ago
Disagree. I once worked at a place where 'death march' was an entirely appropriate description of a significant portion of the normal annual development cycle of a very successful product. Of course they didn't call it that, but that's exactly what it was nonetheless.

khazhoux 3y ago

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/complete tasks, whereas the other has a list view for your open/to-do/in-progress/complete tasks! "Agile" has bugged the hell out of me the last 13 years, and one of the main reasons is that the people who push for this the loudest, have never deployed a line of code in their lives: Project Managers and their ilk. Their livelihood depends on owning a process and reporting the state transitions of the actual engineering work. I'm forced to have 2-week sprints at my company, and I just realized today that the Sprint Planning calendar entry --which I own for my team-- had expired a couple of weeks ago. Of course, no one on the team noticed because we're actually heads down merging code. But I'm sure the PMs will freak out. Now, all that said, I do support teams meeting every 2 weeks to review tasks and priorities. That's fine. But do we have to pretend that's "Agile"?

usefulcat 3y ago
If you read TFA, it's abundantly clear that the author is talking about death marches (they even use that word), not the agile meaning of 'sprint'.
- khazhoux 3y ago
  I'm talking about sprints, as is Boodman in the tweet. And having some proximal observation of the Chrome team at work, btw, Boodman is spot-on that that team kicked ass because they had awesome engineers and super-technical leadership.
psunavy03 3y ago
"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 on fire and wasting your professional life. It's a common attitude among immature devs who can't get beyond the whole "I have the most important job in the company" mindset. I'd expect it out of a junior dev, but someone who has 13 years of experience? That's not the flex you think it is.

deleted 3y ago

[deleted]

tgma 3y ago

Moral of the story: start with someone else's open source project.

Cthulhu_ 3y ago
Isn't that pretty much every software project these days? Be it language, libraries, frameworks, etc. It often feels like a lot of software development is duct taping different libraries together.

fzeindl 3y ago

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 parts, but not at all for systems and backend programming, which are much harder to divide into a workable backlog.

Cthulhu_ 3y ago
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 features accordingly. Everybody happy. We work with SAFe where that process of inter-team dependencies are formalized in quarterly "sprints" subdivided into 3-4 3-week team sprints. That's easy enough to explain at least, it's a shame the website makes it look so bad: https://scaledagileframework.com/ https://scaledagileframework.com/
- fzeindl 3y ago
  I am glad to hear that you use 3-week sprints. 2 week sprints are too short, yet everyone uses them without questioning.

Spiwux 3y ago

Reading the comments to this submission made painfully clear that a significant portion of HN commenters are posting their opinions without even reading the linked article first.

Cthulhu_ 3y ago
This is the internet in a nutshell, and why crafting headlines and titles is an art, frequently used in "propaganda" to sway public opinion.

janosdebugs 3y ago

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 Scrum was forced on them or they decided to switch themselves.

Sosh101 3y ago
I have experienced this too.
Cthulhu_ 3y ago
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.
- janosdebugs 3y ago
  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 https://www.valvesoftware.com/en/publications

d3vmax 3y ago

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 democracies with paid and useful idiot(s) accounts. For Elon, who is living in a selfish bubble, that is free speech and he keeps reposting conspiracy theorist. In short, the whole platform is going to the gutter. Being a champion of the Internet from the late 90's, I can't believe where we are at now and how non-scientific fervor has grabbed every aspect of discourse (anti vax, flat earth, soros/gates, Q/Pizza/MAGA, etc).

modeless 3y ago
What relevance does this have to a tweet from 2021?
JimDabell 3y ago
This Twitter thread is two years old, posted long before Twitter’s current woes.
- d3vmax 3y ago
  Yikes! My bad.
abwizz 3y ago
we are experimenting with ways to have an inclusive global conversation. there will be many more failures

miked85 3y ago

I'm not a big fan of agile, but right off the bat it seems clear that the author doesn't know what sprints are.

chalcolithic 3y ago

Not as a counterpoint but just to add some context: I used Chrome when it just came out. For a week. Couldn't stand it any longer - it was buggy as hell. Of course, now it is polished and the user experience is completely different.

Cthulhu_ 3y ago

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.