Moral of the story: start with someone else's open source project.
Chrome was delivered without any sprints at all (2021)
31–40 of 120 posts
Re: Chrome was delivered without any sprints at all (2021)
#32They 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, 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 usually mostly a manager issue, and sometimes IC's.
Ideally you only have spillovers because of things that were not under your control - power outages, 3rd party vendor outages, etc.
Re: Chrome was delivered without any sprints at all (2021)
#33Major software projects can't be built in 2-4 weeks. They're still inherently iterative though, so keeping iterations relatively small is valuable.
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 pour…
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."
Re: Chrome was delivered without any sprints at all (2021)
#34What 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…
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'.
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.
Re: Chrome was delivered without any sprints at all (2021)
#35Earlier quoted context omitted.
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 pour…
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."
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.
Re: Chrome was delivered without any sprints at all (2021)
#36Note: "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!
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?
Re: Chrome was delivered without any sprints at all (2021)
#37They 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.
Re: Chrome was delivered without any sprints at all (2021)
#38What 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…
"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 o…
> "Every" is a pretty big word, and it's a pretty immature attitude to write off whole groups of people.
"Every" usually doesn't literally mean "every", but I'm sorry that my experience across several large companies is that the people that demand following "Agile Ceremonies" are by-and-large Project Managers, and (with rare exception) not the engineers or the technical eng managers. I've seen this at multiple large companies. And I remember clearly how much awesome, robust software we shipped before Agile creeped in around 2008-2010, to then be told we were "doing it wrong" because our work wasn't broken down into 2-week sprints.
> if you ship the wrong stuff
Two-Week Sprints are neither necessary nor sufficient to avoid this.
> 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.
That's super ad hominem. I'd rather hear a specific counter-argument on the necessity of Agile sprints.
Re: Chrome was delivered without any sprints at all (2021)
#39It 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.
Re: Chrome was delivered without any sprints at all (2021)
#40Earlier quoted context omitted.
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."
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.
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.