8 ms·

Tech companies are run by product managers these days and fixing a bug is not a product priority if the buggy software is still making money

booleandilemma 5y ago
Then let’s make it a priority. We can talk about it in the next sprint, after a story has been created and groomed. Then it’s just a matter of someone taking it off the backlog after they’ve gotten through their current workload and scheduled a meeting with product to make sure expectations are aligned.
mkl95 5y ago
This. At most companies Agile = delivering new buggy software on top of old buggy software every few weeks.
deleted 5y ago
[deleted]
marcosdumay 5y ago
I disagree with the "these days" part. Tech companies never fixed bugs. In fact, since I can remember, they have only improved on that (but they still aren't any good).
brightball 5y ago
One of many reasons I’m a fan of SAFe (Scaled Agile Framework). There are 2 backlogs, one run by product and one run by dev/ops/arch/sec. Over the course of a PI (about 1 quarter), capacity planning usually allocated 70/30 between the two backlogs. This allows your tech staff to prioritize things in their 30 without having to make a business case for people who don’t intimately understand why it’s important. It’s beautiful. They are called the Program and Solution backlogs. https://www.scaledagileframework.com/program-and-solution-backlogs/ https://www.scaledagileframework.com/program-and-solution-ba...
- sdoering 5y ago
  Interesting insight. I probably never was part of a real by the book SAFe environment then. In all SAFe projects I took part never was there a second backlog. Or if there was one (once) the reasoning was: "Let'sput everything from tech in there. We will revisit it once we have done the important/business-relevant stuff." My take away message is that no matter what, business either cares for security or it doesn't. No framework will help against the priorities of product/management if they are aligned against security.
  - brightball 5y ago
    Your description is really why it’s so important. The two backlogs combined with PI planning that lets developers lay out the best course of action based on the priorities they’ve been handed is core to the entire approach. Developers are expected to have a lot more control in SAFe. Like anything else though, it boils down to leadership understanding that giving up total control is more effective for the company. Usually technical leaders understand that.
    - kodah 5y ago
      A company and managers not respecting refactor is a culture problem, having two backlogs that are weighted differently is just a workaround to the culture problem. That culture usually isn't from managers being ignorant of the value of refactor, it's that incentives for them (bonuses, etc) are aligned against the latter backlog. If you fix the incentive, all the other pieces will fall into place.
- LoveGracePeace 5y ago
  This sounds pretty smart. It'd sound even better if it was made 50/50.
  - brightball 5y ago
    You can agree to make it whatever balance you want. 70/30 is a solid recommendation to start with though. I’ve found that in many cases, because the developers understand what needs to be done so clearly in that backlog that even big items go quickly. The biggest thing is just to make sure that you’re not in a situation of 100% features where everything else is being ignored until it all catches up to you. 70/30 at least forces the issue.
X6S1x6Okd1st 5y ago
this runs counter to the trend observed in the article.
saurik 5y ago
Yeah: Google employees routinely leave patches for bugs in the PR queue because someone hasn't either update the existing tests (which clearly were adding negative value if they fail on the fixed code) or write new regression tests, as if "the code is already known to be wrong shouldn't trump "maybe someone in the future will break it again".
deleted 5y ago
[deleted]

booleandilemma 5y ago

Then let’s make it a priority. We can talk about it in the next sprint, after a story has been created and groomed. Then it’s just a matter of someone taking it off the backlog after they’ve gotten through their current workload and scheduled a meeting with product to make sure expectations are aligned.

mkl95 5y ago

This. At most companies Agile = delivering new buggy software on top of old buggy software every few weeks.

deleted 5y ago

[deleted]

marcosdumay 5y ago

I disagree with the "these days" part. Tech companies never fixed bugs. In fact, since I can remember, they have only improved on that (but they still aren't any good).

brightball 5y ago

One of many reasons I’m a fan of SAFe (Scaled Agile Framework). There are 2 backlogs, one run by product and one run by dev/ops/arch/sec. Over the course of a PI (about 1 quarter), capacity planning usually allocated 70/30 between the two backlogs. This allows your tech staff to prioritize things in their 30 without having to make a business case for people who don’t intimately understand why it’s important. It’s beautiful. They are called the Program and Solution backlogs. https://www.scaledagileframework.com/program-and-solution-backlogs/ https://www.scaledagileframework.com/program-and-solution-ba...

sdoering 5y ago
Interesting insight. I probably never was part of a real by the book SAFe environment then. In all SAFe projects I took part never was there a second backlog. Or if there was one (once) the reasoning was: "Let'sput everything from tech in there. We will revisit it once we have done the important/business-relevant stuff." My take away message is that no matter what, business either cares for security or it doesn't. No framework will help against the priorities of product/management if they are aligned against security.
- brightball 5y ago
  Your description is really why it’s so important. The two backlogs combined with PI planning that lets developers lay out the best course of action based on the priorities they’ve been handed is core to the entire approach. Developers are expected to have a lot more control in SAFe. Like anything else though, it boils down to leadership understanding that giving up total control is more effective for the company. Usually technical leaders understand that.
  - kodah 5y ago
    A company and managers not respecting refactor is a culture problem, having two backlogs that are weighted differently is just a workaround to the culture problem. That culture usually isn't from managers being ignorant of the value of refactor, it's that incentives for them (bonuses, etc) are aligned against the latter backlog. If you fix the incentive, all the other pieces will fall into place.
LoveGracePeace 5y ago
This sounds pretty smart. It'd sound even better if it was made 50/50.
- brightball 5y ago
  You can agree to make it whatever balance you want. 70/30 is a solid recommendation to start with though. I’ve found that in many cases, because the developers understand what needs to be done so clearly in that backlog that even big items go quickly. The biggest thing is just to make sure that you’re not in a situation of 100% features where everything else is being ignored until it all catches up to you. 70/30 at least forces the issue.

X6S1x6Okd1st 5y ago

this runs counter to the trend observed in the article.

saurik 5y ago

Yeah: Google employees routinely leave patches for bugs in the PR queue because someone hasn't either update the existing tests (which clearly were adding negative value if they fail on the fixed code) or write new regression tests, as if "the code is already known to be wrong shouldn't trump "maybe someone in the future will break it again".

deleted 5y ago

[deleted]