Chrome was delivered without any sprints at all (2021)(twitter.com)
twitter.com
Chrome was delivered without any sprints at all (2021)
https://twitter.com/aboodman/status/1427137725119959046
119 comments
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.
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.
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.
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.
How typical to blame it on the devs instead of leadership.
I don't see where parent puts blame but let's not act like all devs are angels
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.
In my experience I’ve found (1) some teams don’t embrace it, (2) some teams don’t break down large tasks or (3) it’s not suited to the work. Each of these result in your rolling sprint. I absolutely hate seeing buzzwords for the sake of them but often the work simply doesn’t work well with sprints.
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.
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.
> 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.
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.
From my experience it can work. I've worked on a team where we got really good at estimating, had really useful planning sessions, a good backlog. Worked pretty well and had some advantages in terms of getting the team to be engaged and take ownership.
The problem with Agile in general is that it can easily be twisted around to make anything you want. A great team doesn't need agile methods, but it can use them and still be great, and possibly even get some improvement with careful use. Agile intended to fix organizations but organizations don't want to be fixed, and certainly not by a bunch of software people...
The problem with Agile in general is that it can easily be twisted around to make anything you want. A great team doesn't need agile methods, but it can use them and still be great, and possibly even get some improvement with careful use. Agile intended to fix organizations but organizations don't want to be fixed, and certainly not by a bunch of software people...
> 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?
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?
Also known as the No True Scotsman argument https://en.m.wikipedia.org/wiki/No_true_Scotsman. "You weren't doing real Agile™".
The only reason I'm posting this is because we have had similar things happen in almost every attempt at using sprints. They're just not suited for any sort of formal/business context where you don't have absolute and frankly religious buy-in to the concept.
The only reason I'm posting this is because we have had similar things happen in almost every attempt at using sprints. They're just not suited for any sort of formal/business context where you don't have absolute and frankly religious buy-in to the concept.
It is a fallacy only if in support of "Trying to use sprints will improve your organization", it would not be a fallacy if in support of "The benefit of sprints are real but only if used properly" where properly is defined in some clear a priori way.
The “No true Scotsman” fallacy is when you introduce unrelated criteria to disqualify something that would ordinarily be a member of a group. It’s perfectly reasonable to point out that somebody who was not born in Scotland, does not have Scottish family, does not hold any kind of British citizenship, and has never even set foot in Scotland is not, in fact, a Scotsman. That’s not a fallacy.
A sprint is a discrete period of time in which discrete software development tasks happen. A “rolling sprint” is conceptually void. You can’t have a discrete period of time that lasts indefinitely any more than you can have dehydrated water. The “rolling” part and the “sprint” part are mutually exclusive.
I’m not even saying that they weren’t “doing real Agile” – I’m pointing out that what is being described has literally no meaning at all. You can’t be good or bad at it because it’s a meaningless term.
A sprint is a discrete period of time in which discrete software development tasks happen. A “rolling sprint” is conceptually void. You can’t have a discrete period of time that lasts indefinitely any more than you can have dehydrated water. The “rolling” part and the “sprint” part are mutually exclusive.
I’m not even saying that they weren’t “doing real Agile” – I’m pointing out that what is being described has literally no meaning at all. You can’t be good or bad at it because it’s a meaningless term.
The purpose of language is to communicate, and audiodude did that quite effectively given the fact I chuckled when I read their comment, because I knew exactly what they meant. A "rolling sprint" might be an oxymoron, but it certainly isn't conceptually void. It quite literally does have meaning considering I and many others clearly understood the point he was making through his personal anecdote.
How can it be a sprint if nobody is running? /s
> 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 "velocity" constantly. If that's not a death march, what is.
> Sprints are just a way of breaking up work into discrete periods of time.
There is not rational purpose to this. If the work takes 4 days, there's no reason to fabricate an artificial sprint boundary that forces you to break it down into two 2-day tasks just to fit into the confines of this imaginary sprint. It'll still be done four days from now.
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 "velocity" constantly. If that's not a death march, what is.
> Sprints are just a way of breaking up work into discrete periods of time.
There is not rational purpose to this. If the work takes 4 days, there's no reason to fabricate an artificial sprint boundary that forces you to break it down into two 2-day tasks just to fit into the confines of this imaginary sprint. It'll still be done four days from now.
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 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.
Nobody, least of all proponents of scrum / agile methodologies, is saying that you should work harder, do a death march, etc. It acknowledges that software development is an infinite and long term process.
Scrum does NOT work with deadlines. It works with predictability; your team's average velocity and the story points of upcoming stories are known, it's then up to the product owner to set priorities if they need a feature live at a certain point in time. Missed deadlines then become bad planning and prioritization more than employees not working fast enough.
> There is not rational purpose to this.
Just to highlight this: 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". It doesn't mean that a 4 day task should be done in 2 weeks. A sprint is just a unit of time, it isn't a promise.
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 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.
Nobody, least of all proponents of scrum / agile methodologies, is saying that you should work harder, do a death march, etc. It acknowledges that software development is an infinite and long term process.
Scrum does NOT work with deadlines. It works with predictability; your team's average velocity and the story points of upcoming stories are known, it's then up to the product owner to set priorities if they need a feature live at a certain point in time. Missed deadlines then become bad planning and prioritization more than employees not working fast enough.
> There is not rational purpose to this.
Just to highlight this: 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". It doesn't mean that a 4 day task should be done in 2 weeks. A sprint is just a unit of time, it isn't a promise.
> 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 absolutely no sense to me and it is not how we do things at work. When the second task is estimated it will get a story point count of 1 because it's just copy pasting a button, not 5 which requires implementing a button from scratch.
This makes absolutely no sense to me and it is not how we do things at work. When the second task is estimated it will get a story point count of 1 because it's just copy pasting a button, not 5 which requires implementing a button from scratch.
> 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.
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.
"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.
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.
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....
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....
The name sprint comes from rugby, and just refers to what the team would be doing together to succeed (sprinting to the other end of the field with the ball).
So what part is the dirty ruck where the people on the bottom get their eyes gouged, their heads stomped, and their nut sacks torn open?
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.
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.
> 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.
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.
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.
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.
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.
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.
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
> They seem to be using “sprint” and “death march” interchangeably.
That’s absolutely not what’s written there and I’m surprised the context - and the narrative goal of the article - is not being grasped.
To put it more simply and distill it even more the gist is: “senior professionals know how to work and can manage their work structure/pace”.
That’s absolutely not what’s written there and I’m surprised the context - and the narrative goal of the article - is not being grasped.
To put it more simply and distill it even more the gist is: “senior professionals know how to work and can manage their work structure/pace”.
And this is why many agilists prefer to use the term "iteration," because "sprint" can be conveniently "misinterpreted" by toxic managers.
On that very note:
https://www.youtube.com/shorts/liUiRfN9NzQ
https://www.youtube.com/shorts/liUiRfN9NzQ
> 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.
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.
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 engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done.
As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing.
The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.
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 engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done.
As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing.
The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.
> 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 middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?".
Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job.
But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.
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 middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?".
Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job.
But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.
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.
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.
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.
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 underestimated", "there were unforseen circumstances", or "what can we do better".
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. "We failed" is giving up, "what can we improve" is taking ownership and action.
You never use language like "the sprint failed" or "what went wrong", you say "we underestimated", "there were unforseen circumstances", or "what can we do better".
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. "We failed" is giving up, "what can we improve" is taking ownership and action.
> 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.
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.
>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".
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".
As someone who developes software I can tell you that I have seen those three work:
A) if I am motivated, in the mood and it is my project I can program a thing in one go (e.g. if I have no dayjob, healthy breaks, time for sports, etc)
B) One of my employers wanted software, while my dayjob was something else. I told them I can do it if I get a fixed day on which my other responsibilities don't need to be taken care of. After half a year the project was finished. The biggest delaying factor were external partners who used the "sprint" model.
C) I do my current private project on two mornings in the week before work when I have time, it makes good progress.
If you need to constantly crunch to finish things you are either bad at management or you have perpetual bad luck, one of which is more likely.
Everything if done well takes a certain amount of time. And because things never go as planned and requirements change you can multiply that time by the value of pi. Additionally you should ensure that time is actually available for your employees and not something where they need to fulfill other crap (especially not your crap). If your employees are not totally incompetent (your responsibility again), you should be able to finish that project without a single hour overtime or any need to crunch at all.
The problem starts when managers confuse how long they wish something would take with how long something actually takes. Often managers promise things go faster because they don't dare to break the illusions of their superiours (or gamble on the slim chance that they can whip their team into finishing faster to then reap the fruit of that success).
Things take as long as they take. Multiply by arbitrary, pessimistic safety factors, you will finish it slow and steady on time, while still leaving space to try some things out.
A) if I am motivated, in the mood and it is my project I can program a thing in one go (e.g. if I have no dayjob, healthy breaks, time for sports, etc)
B) One of my employers wanted software, while my dayjob was something else. I told them I can do it if I get a fixed day on which my other responsibilities don't need to be taken care of. After half a year the project was finished. The biggest delaying factor were external partners who used the "sprint" model.
C) I do my current private project on two mornings in the week before work when I have time, it makes good progress.
If you need to constantly crunch to finish things you are either bad at management or you have perpetual bad luck, one of which is more likely.
Everything if done well takes a certain amount of time. And because things never go as planned and requirements change you can multiply that time by the value of pi. Additionally you should ensure that time is actually available for your employees and not something where they need to fulfill other crap (especially not your crap). If your employees are not totally incompetent (your responsibility again), you should be able to finish that project without a single hour overtime or any need to crunch at all.
The problem starts when managers confuse how long they wish something would take with how long something actually takes. Often managers promise things go faster because they don't dare to break the illusions of their superiours (or gamble on the slim chance that they can whip their team into finishing faster to then reap the fruit of that success).
Things take as long as they take. Multiply by arbitrary, pessimistic safety factors, you will finish it slow and steady on time, while still leaving space to try some things out.
> 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.
that 'failure' bit right there is some bullshit that should get cut out.
The word "sprint" has meanings outside of Scrum, I think it's used here in the dictionary meaning.
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"?
... 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"?
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.
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.
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.
Scrum practices, if done right, offer predictability. Management loves predictability. You should love predictability as well because it means you won't have to do overtime / stress.
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.
Scrum practices, if done right, offer predictability. Management loves predictability. You should love predictability as well because it means you won't have to do overtime / stress.
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.
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.
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.
"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.
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.
> "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.
"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.
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 incompetent, that no one who goes by that term has ever deployed code, or that Agile as an approach is always wrong and always inhibits delivering good software. THAT is immature. That's taking bad implementations and generalizing them to say that every implementation is automatically bad. Just because the Detroit Lions are historically horrible isn't empirical proof that it's impossible to play good football.
Agile is not two-week sprints. Agile is not daily standups. These are tools which may or may not be appropriate in a given context. 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, because that is not a role which exists in any credible Agile organization, and for good reason.
But what's equally ad hominem is this implication that every agilist is this incompetent, that no one who goes by that term has ever deployed code, or that Agile as an approach is always wrong and always inhibits delivering good software. THAT is immature. That's taking bad implementations and generalizing them to say that every implementation is automatically bad. Just because the Detroit Lions are historically horrible isn't empirical proof that it's impossible to play good football.
Agile is not two-week sprints. Agile is not daily standups. These are tools which may or may not be appropriate in a given context. 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, because that is not a role which exists in any credible Agile organization, and for good reason.
> 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 if scrum of scrum is not enough have scrum of scrum of scrums (duh).
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 if scrum of scrum is not enough have scrum of scrum of scrums (duh).
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).
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).
psunavy03(1)
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.
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.
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.
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
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
"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"
"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"
I have experienced this too.
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
---
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).
[1] 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).
> 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.
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.
I've found them incredibly useful for getting teams to be realistic about their bandwidth and throughput. They bring data to conversations and help engineers, designers, and PMs put actual numbers to decisions and trade-offs.
I think the formality of sprints is way overblown, but the cadence of them can be extremely valuable. Having stakeholders come together to discuss and tweak plans is super helpful. Ideally, _tweak_ is the keyword. If you have major changes sprint-to-sprint, something else is wrong.
In most cases, the discussion goes something like this:
* (A) We're on track. Everything is going well. Here's what's outstanding. If we get that done, what do we want to stretch for?
* (B) We've had some problems/things aren't moving as fast as we thought. Here's why. What should we do about it.
I think the formality of sprints is way overblown, but the cadence of them can be extremely valuable. Having stakeholders come together to discuss and tweak plans is super helpful. Ideally, _tweak_ is the keyword. If you have major changes sprint-to-sprint, something else is wrong.
In most cases, the discussion goes something like this:
* (A) We're on track. Everything is going well. Here's what's outstanding. If we get that done, what do we want to stretch for?
* (B) We've had some problems/things aren't moving as fast as we thought. Here's why. What should we do about it.
>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.
The root of most of what we call 'Agile' today goes back to a method for managing difficult clients when doing (primarily web development) consulting.
If you're not a consultant or you're not trying to defensively manage a difficult client then it's a poor set of processes for your development work to follow.
The root of most of what we call 'Agile' today goes back to a method for managing difficult clients when doing (primarily web development) consulting.
If you're not a consultant or you're not trying to defensively manage a difficult client then it's a poor set of processes for your development work to follow.
> 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'm currently on a project that works like this, without sprints, and clearly it works for us. Also, no standups. We communicate as soon as it's needed and not more (often) than needed.
I'm currently on a project that works like this, without sprints, and clearly it works for us. Also, no standups. We communicate as soon as it's needed and not more (often) than needed.
Kanban is the way. Keep things flowing.
Planning should be a continuous and real time endeavor; and planning without your stakeholders input is a plan to fail.
Counterpoint: The other reason for scrum style sprints is predictability.
You can set deadlines like "feature X needs to be done by August", but that leads to overworking, cutting corners, etc.
You can instead set the scope / features - like you said, a browser has a long list of features that need to be built - apply a score / weight to them (story points), work in iterations, see how much of that relative score is done per iteration, then plot that so you can say "If we keep going like this, feature X will be done by August".
And if it needs to be done sooner, the project manager just has to put it higher up in the list.
You can set deadlines like "feature X needs to be done by August", but that leads to overworking, cutting corners, etc.
You can instead set the scope / features - like you said, a browser has a long list of features that need to be built - apply a score / weight to them (story points), work in iterations, see how much of that relative score is done per iteration, then plot that so you can say "If we keep going like this, feature X will be done by August".
And if it needs to be done sooner, the project manager just has to put it higher up in the list.
I see an argument for estimating tasks here, not for sprints.
You can track progress on these tasks without sprint. Of course, this tracking needs to happen regularly and sprints is a possible implementation of this but you can do it without them.
You can track progress on these tasks without sprint. Of course, this tracking needs to happen regularly and sprints is a possible implementation of this but you can do it without them.
If you have a technical client, they will understand. If you don't, nothing in the world will make them understand. Ship a build too early and they will start complaining about superficial things that are on your todo list. Plus, nothing prevents you from shipping regular builds to the client without sprints either. It's often a good idea to set up nightly builds and make sure they are never broken. As you said, your PM or whatever you call them can still have calls with them, but there is no point in wasting the time of however many engineers work on it to regularly attend those calls.
I dislike sprints but have not seen a better alternative for teams of 50+ people.
That isn't a team, that's a department; I presume those people are either explicitly or implicitly divided into smaller teams / responsibilities?
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?
> 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?
Team of 50+ people?! I wonder how do your Scrums look like. Is the work day over by the time you finish it?
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.
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.
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!
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?
Why is there so much difference in work load in different teams?
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
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
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.
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.
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/
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/
I am glad to hear that you use 3-week sprints. 2 week sprints are too short, yet everyone uses them without questioning.
Does "sprint" mean something other than "chunk of work, usually 2-4 weeks in duration"?
Yes: https://en.wiktionary.org/wiki/sprint "A short race at top speed" (etc)
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.
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.
Scrum :TM: has a sprint delivering a new increment to a working piece of software.
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.
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.
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.
This is the internet in a nutshell, and why crafting headlines and titles is an art, frequently used in "propaganda" to sway public opinion.
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.
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.
[deleted]
Major software projects can't be built in 2-4 weeks.
They're still inherently iterative though, so keeping iterations relatively small is valuable.
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 poured, framing up, roof on, sheathing on, etc, etc.
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.
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."
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.
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.
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.
It's that a lot of people don't have (didn't have?) this philosophy. My previous employer worked in telecom; it wasn't uncommon to have one major feature be under development by one or two guys for eight months at a time.
It was specialist work, sure, and the guys knew what they were doing (20-40 years in the business) but then integrating and releasing it was a big job.
It was specialist work, sure, and the guys knew what they were doing (20-40 years in the business) but then integrating and releasing it was a big job.
No one is expecting you to build the entire thing in 2-4 weeks (1-4 weeks to be accurate if we're talking Scrum). The intent is to have a potentially shippable increment at the end of 1-4 weeks which you can demo to a customer (or someone who can credibly speak for them) and get feedback.
The idea is that when you combine software, markets, and people's opinions, you're now in a complex adaptive system, where you acting within the system changes the system, and where you can never know enough about it to make long-term plans any more than you can forecast what the weather will be on management's "due date." So you use fast feedback loops to learn as you go and build the right thing as it's needed now, not two years ago.
The idea is that when you combine software, markets, and people's opinions, you're now in a complex adaptive system, where you acting within the system changes the system, and where you can never know enough about it to make long-term plans any more than you can forecast what the weather will be on management's "due date." So you use fast feedback loops to learn as you go and build the right thing as it's needed now, not two years 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).
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).
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.
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.
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.
Of course they didn't call it that, but that's exactly what it was nonetheless.
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).
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).
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.