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
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-ba...
https://www.scaledagileframework.com/
It has a section "agile release train" which is a literal train! Everybody loves trains. It also has an icon with the text "Built-in quality", so you can sleep soundly knowing that you will not have quality issues anymore.
/s of course, but that image is really something. It's so vague it can be anything you want it to; a middle managers' dream.
Whenever I teach a class or tell people about SAFe I always let them know 2 things:
1. All of the principles are sound and amounts to a smooth combination of best practices working together. Many companies are doing a lot of what’s involved because of that.
2. There are a lot of buzzwords. You can just assume you’re putting “lean-agile” in front of anything like they do with “quantum” in movies. It’s exhausting if you don’t let yourself chuckle. Because of it, reading the documentation can be confusing if you haven’t taken a class.
" The more alignment you have, the more autonomy you can grant. The one enables the other.
© Scaled Agile, Inc. Include this copyright notice with the copied content.
Read the FAQs on how to use SAFe content and trademarks here: https://www.scaledagile.com/about/about-us/permissions-faq/ Explore Training at: https://www.scaledagile.com/training/calendar/ "
Note that I copied only the quote. But you can see this quote is eminently copyrightable. Hence the copyright notice.
And yes, that style is fashionable on some circles. I usually prefer to avoid those circles.
Does "run by" mean that dev has to justify their projects to product and vice versa? Or is this a "this is our area, we'll take care of it thank you" kind of thing?
In my team at AWS we have ~5 backlogs each planning cycle, which includes areas like 'operational risk reduction,' 'operational burden reduction,' and 'adoption'. What makes it work in our case is that both dev and product jointly own all the backlogs, and have to come to a single recommendation on allocation they put forward to the service GM. Dev has to defend projects they want to do in the more engineering focused backlogs, while product has to do the same for the feature oriented backlog. Over time, allocations have shifted significantly depending on where the service is and what customers are asking for. What I like about this is that it forces everybody to get along and to keep their eye on what's actually important (the customer). This does require that both product and dev are experienced enough to see the other perspective. Product will have to understand that it's not in the customer's interest if dev has a super high burden, while dev will have to accept that a perfect solution is usually worse than a good enough one.
The only place where there may be some crossover is “architectural runway” which works to ensure that your future goals are possible on the system that you have. This could mean that if you know you’re going to have a need to scale a system based on a near-future feature request from product that you put the work into the tech backlog to get things ready in advance.
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.
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.
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.
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.