That may be true in some truly well organized (usually “legacy big corpo” companies).
Where I’ve worked it’s more like:
Requirements only cover user-facing features, if that. (Not so) senior engineers are left to bridge the gap between UI mockups and literally everything else.
Implementation issue is accidentally introduced
Priority on the bug is lower than new features so no-one has any way to justify working on it
One day a dev might be personally annoyed enough by the issue that they fix the part as part of some tangentially related work. Else it stays like that forever.
That is a basic side-effect of Agile development. If you have implementation details figured out to such an extent before writing the code, you are not doing agile, you are doing waterfall. Which has a time and a place, but that time and place is typically banking or medical or wherever you’re okay with spending several times the time and money to get maximum reliability (which is a different metric than quality!).
I bet NVIDIA has driver crashes to figure out, and I know which of those issues I’d want them to focus on first if I used their windows driver.
Agile in corpo is usually the soul-crushing, not working kind, where the participants don’t get the decision power they need for it to be working and not soul-crushing.
I’ve been a PM for about 7 years and God do I miss waterfall. My team is lucky to get a week or two of testing now and that usually puts us right at code freeze so any issues we find we now have to justify to multiple teams and dev on why it needs to be fixed.
How much of it is due to Agile (which is a very broad concept even though some people mistakenly equate it with scrum), and how much is it due to corporate pressures and inadequate processes though?
I find Agile conceptually meshes a lot better with “standard” product and solutions development thanks to the tighter feedback loops and increased reliance on local expertise over centralized planning. This only gets truer as project complexity grows.
However some companies try to make Agile work with top-down decision making and/or hard deadlines, which are deadly antipatterns. As for lack of time/resources and/or timesheet micro-management, this isn’t a problem unique to Agile nor something that waterfall is exempt from.
Good agile teams are mostly independent and can define their own testing/release cycle as required for a given project; though of course when that happens there are at least a couple layers of management who feel a burning itch to stuff their dirty nosed where they don’t belong because if the team succeeds despite their lack of direct involvement then everyone might realize the emperor has no pants.
That may be true in some truly well organized (usually “legacy big corpo” companies).
Where I’ve worked it’s more like:
That is a basic side-effect of Agile development. If you have implementation details figured out to such an extent before writing the code, you are not doing agile, you are doing waterfall. Which has a time and a place, but that time and place is typically banking or medical or wherever you’re okay with spending several times the time and money to get maximum reliability (which is a different metric than quality!).
I bet NVIDIA has driver crashes to figure out, and I know which of those issues I’d want them to focus on first if I used their windows driver.
Agile in corpo is usually the soul-crushing, not working kind, where the participants don’t get the decision power they need for it to be working and not soul-crushing.
Sure, but I don’t think Waterfall is going to save you from the soul-crushingness in such an environment.
I’ve been a PM for about 7 years and God do I miss waterfall. My team is lucky to get a week or two of testing now and that usually puts us right at code freeze so any issues we find we now have to justify to multiple teams and dev on why it needs to be fixed.
How much of it is due to Agile (which is a very broad concept even though some people mistakenly equate it with scrum), and how much is it due to corporate pressures and inadequate processes though?
I find Agile conceptually meshes a lot better with “standard” product and solutions development thanks to the tighter feedback loops and increased reliance on local expertise over centralized planning. This only gets truer as project complexity grows.
However some companies try to make Agile work with top-down decision making and/or hard deadlines, which are deadly antipatterns. As for lack of time/resources and/or timesheet micro-management, this isn’t a problem unique to Agile nor something that waterfall is exempt from.
Good agile teams are mostly independent and can define their own testing/release cycle as required for a given project; though of course when that happens there are at least a couple layers of management who feel a burning itch to stuff their dirty nosed where they don’t belong because if the team succeeds despite their lack of direct involvement then everyone might realize the emperor has no pants.