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.
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.
Don’t get me wrong, that image is dumb. I don’t know why they insist on promoting it so much.
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.
That image (and the rest of the gallery) screams "expensive low quality" with all its strength. I have never seen anything that uses an image like that to be worth one's time.
And yes, that style is fashionable on some circles. I usually prefer to avoid those circles.
> 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.
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 tech backlog just has to be justified among the technical contributors. Product is not involved at all.
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.
Sounds horrible. Product justified git [version] tagging should be done with names and not semver/other. It was very simple: "Marketing pitches it better so more sells". Threw devs and DevOps into the pits of hell, adding unnecessary cost to many tasks.
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.
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.
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.
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.
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...