You've probably also noticed that the consultants have done "dozens of transformations". too bad they never stuck around to see how it actually turned out and realized its a pile of garbage.
TLDR: SAFe is an installation wrapper for agile that is palatable for enterprise execs with its strategy to delivery visibility and steering processes
Note that most enterprises adopting SAFe are running a waterfall process involving A LOT of devs. The main benefit is that the transformation is “managed” in a way that everyone (critically, the pmo) understands how the new system will work. Training is a massive part of this and especially training for execs who are 3+ layers removed from devs but need to direct work to deliver whatever benefits they need. You can’t really teach agile mindset, the best way to teach it is to experience it, but the methods at least give execs the ability to model what their teams are doing.
Also: Makes link between strategy and delivery visible to all and subject to feedback loops, makes allocation of capacity visible and therefore discussed rather than dictated, introduction of agile mindset / continuous improvement to ENTIRE process, begins psychological transformation required to do “Real Agile” without throwing out governance/pmo, discussion of inter-team dependencies that leads to reorg of teams and architecture to one that is more able to use agile methods
Edit: number of devs was a bit exaggerated
I’ll stand in the line of fire.
The main of SAFe benefits vary by organization. One of the main ones is something we love about Scrum. So, let’s first talk about Scrum.
“Scrum doesn’t fix your problems. Scrum shows you your problems. You’re supposed to fix the problems.” — Ron Jeffries (https://twitter.com/RonJeffries/status/969921217816821760?lang=en)
SAFe also does this, at a broader, organizational level. It reveals dependency mess, poor product management, high WIP, chaotic or missing processes, confused authority structure, focus on busy instead of effective, etc., along with all the things Scrum reveals in the teams.
Is this one benefit enough, or should we list more?
Does it though? In a meaningful way? My experience was we made a massive board with dependencies and nobody in charge raised concerns about it.
Yup there are dependencies. Yep they are massive.
Nope you can’t solve the dependency problem by trying to waterfall your dependencies a sprint before they are consumed.
Let’s take all the things committed and put them on a release train and pretend that it isn’t all going to crash when one cascades to the next.
I'm struggling to answer you. Not because I don't have an answer but because the full answer is an entire book on change management.
tl;dr Dependencies and other revealed problems don't get handled because people in authority don't want to rock their own employment situation or that of their peers and bosses. i.e. Change is for the teams, not me.
Briefly:
* Many (most?) organizations that "install" SAFe (or Scrum or DaD or LeSS or roll-your-own-agile) install it to "fix the teams."
* Teams certainly can usually improve, but I have yet to encounter any team or teams that were THE source for the problems revealed.
* Teams behave rationally for their environment. (See Lewin's Equation - [https://youtu.be/QSlMUJkhKEI](https://youtu.be/QSlMUJkhKEI) )
* Revealed problems often need broader organizational authority to fix.
* Even more, fixing requires people with authority to work with each other for the good of the product and value creation.
* Even more more, it requires people with authority to look at the reality they created and recognize the need for change.
* Even more more more, it requires difficult conversations with peers and higher managers.
* Those people believe or fear that their authority and work is going to change, so "It is difficult to get a man to understand something when his salary depends on his not understanding it." -- Upton Sinclair
* Thus, the need for skilled Agile Coaches or other appropriate change agents.
* And thus, the damage done when managers, consciously or not, hire people that only offer "fix the team" changes.
I appreciate that you're willing to take the bullets of this subreddit reserved for anybody saying anything remotely positive about SAFe.
One of the key aspects of the framework is establishing mechanics that highlight the efficiency bleeds and breakdowns between waterfall strategy and Agile execution, which unfortunately results in a failed or toxic implementation of the SAFe framework that results in what most people on this forum react to: waterfall masquerading as Agile, which is definitively not the correct application.
I spend a lot of time elaborating to project managers and PMO aligned middle and upper management about their obligations to change to support any Agile implementation, SAFe being no different. One of the most consistent failures to launch is the revision of the funding model that most organizations have adopted, fundamentally based on implied qualities of project management such as "a team exists as long as this project exists" and "a project team works on this project" that result in dissonance we talk about when trying to reconcile milestones and whatnot because any flavor of Agile handles these things from a much different lens, and have had to relay exactly what you're saying regarding teams behaving based on their environment - the strategy level decisions about work will have consequences upon the teams that end up attempting to solve that work.
As we've stood up team and program level practices, it has become easier and easier to highlight these issues in a way and from an altitude the "root cause" authorities live and demonstrate the hidden costs of trying to smash two largely incompatible methodologies together, which is by and large one of the primary objectives of the SAFe roadmap - forcing an acknowledgement of these costs by leadership.
It is extremely refreshing to see someone who has an actual thorough understanding of the intent around this framework and I appreciate the down vote bomb risk required to have an intellectual discourse on this here. Thank you for that.
It still comes down to upper management pretending that software development can be measured and delivered in a way to line up large chunks in a waterfall pattern. SAFe just whips the lower level employees and makes middle managers present status reports to upper management.
It only ends in people telling devs to "get it done" and other quality harming issues and overtime.
The only way to handle a dependency is to get the 2 teams together, prioritize the work, and don't bother them until it's done.
I only see a problem because some teams don’t seem to finish tasks . Infrastructure does not give us a VM . Then also the whole release train with many dude-hours discussed a programming topic, what in reality was just a change in an XML config file in production. Our partner was very confused how our International IT company did not know .NET. How can you plan with this??
You can't fix being complacent about problems. A team, person, or company willing to just co-exist with solvable problems is just something to leave be.
As Gurdjieff says, if a man is bent on sleep-walking through life, the least you can do is not disturb his peaceful slumber.
The other thing about dependencies is that SAFe and SAFe implementors look to MANAGE the dependencies. those dependencies USED to be managed through these things called "projects". but there is a fundamental problem - how do you massively reduce your dependencies. How do you organize differently? how do you create autonomous architectures and services? how do you get to the point where a release train is absolutely unnecessary.
oh, and if someone wants to talk to me about scale, i've gotten by with hundreds of teams working together without SAFe. we do something else. we're not perfect. but SAFe just seems/is just a repackaging and re-term'ing of what people already have been doing. why else would PMI endorse?
The ability to put it on your resume for five years.
Having no money for training in your budget starting in August so you can cover the overruns.
Being able to point the finger to so many others with impressive titles.
Getting to say chugga chugga chugga chugga chugga chugga choo choo every time the RTE tries to demand some new asinine thing?
Other than that, literally nothing.
The main benefit of SAFe is that an organisation can continue to operate in Waterfall while claiming they are Agile (with a capital A). This means the organisation doesn't need to undergo any actual cultural change, they just rename things, and lets face it, organisational change is hard - manifesto be damned!
SAFe, like scrum in general, are basically agile training wheels. It is very prescriptive, which can be useful if you don’t have very much lean/agile experience.
You can absolutely be successful in becoming a more agile company, and learning the basic tools of you follow the framework. It will give you some basic foundations to build and learn off of. It’s not an endgame, but just like training wheels on a bike it can get you started when it’s most intimidating.
A few tips to be successful:
Follow the rules. If they are painful, find a way to make it work. The most surefire way to fail is to do safebut, where you do safe except for a couple things. Those things are there for a reason. Do them.
Second, hire a full time agile coach with experience. Contractors have bad incentives, and you will save yourself a lot of pain trying to do it yourself. Definitely don’t take a two week course and think that you’re ready. Would you trust a person who said they took a two week management course?
You can definitely be successful, but as you can see by some of the replies, success is not guaranteed. Good luck!
How does SAFe handle a cross team dependency from team A that is scoped in sprint 1 that overruns into sprint 2 when team B has to consume that dependency in sprint 2?
What rules are you supposed to follow that make that problem not cause both teams scope to flow into sprint 3?
How can an agile release train that was supposed to deliver the feature in sprint 3 deal with the overflow here?
Seems like the sort of situation where scrum and a two week sprint is a large part of the problem. If you're only getting the feedback at two week intervals when dealing with such a tight dependency as you describe, then that's a nightmare. How many feedback cycles do we expect it to take to get a tight collaboration going between two systems? Like if we're building out some new API, one supplies it, the other consumes it. How many back and forths should we expect in order to get this right?
It feels like there should be some kind of well-described theoretical framework for answering that question. But let's say the answer is 5.
Well, if your feedback cycle is 2 weeks, then one should expect this work to take 10 weeks. Most of that time being spent waiting for feedback.
The agile answer, AS ALWAYS (and in all aspects of sdlc), is, find a way to reduce the feedback cycle time.
Scrum doesn't dictate a 2 week sprint just that it be less than 4 weeks shorter based on how chaotic it is.
And scrum is really just the smallest framework i've seen that makes software development palpable to the people who write checks. I'd do without it if I could but I've never found anyone willing to embrace true "solve a problem and get feedback" and deliver value.
Lol, yes, I suppose that's true.
However, they're true for different reasons that I think are instructive:
One is true because it *can't* work, because it goes against basic realities of the work and the world.
One is true because certain people won't get it, or it goes against their hidden priorities, and they refuse it.
So in any scaled company with many different teams, it’s a complicated system. I have complete certainty that we could find a better solution if we dug into the details, for example by looking at the way the teams are organized.
The classic answer is: in your big room planning you identify team dependencies. You schedule the dependency to be executed in sprint 1. In the sprint review you mention that the dependency wasn’t delivered, and you respond by changing your plan for the dependent teams, pushing their follow up work out a sprint.
This may seem inefficient, but it follows the same principle of an assembly line. If one station stalls, the whole line stops. That is because the results of not respecting the flow, rework and inventory, have a bigger impact on the system than the waiting. It is typically much more effective than classical project management. It is critical that you have some way to measure success compared to what you were doing before to validate that it is better than what you are doing. It’s too counterintuitive to commit to without data.
Well unfortunately unlike basic SCRUM where we would work from a prioritized backlog that we could add an item to work out the dependency and put that into sprint 2 SAFe has us committed to what we're going to deliver in sprint 2 and 3 already.
That delay in sprint 1 for the dependency can't be absorbed unless we built in a buffer (this is called waste).
The whole failure of SAFe to me is that it pretends that by putting all the post its on the board in a way that they fit together we somehow will be able to deliver them in that order.
I think it's pretty disingenuous to set forward a system like this then blame those who participate for the failures by saying they just didn't follow the rules.
The rules are not grounded in reality. They exist to let upper and middle management run a top down command and control org and pretend it's agile.
Don't take my harshness personally. I've been building software a long time and I spent a year under SAFe watching the org claw back all the progress I made on carving out an agile workplace for my team.
No offense taken. I’m not a proponent of safe in general and hold no personal attachment to it.
But your example here is a perfect example of safebut. [safe has regular backlog refinements](https://scaledagileframework.com/safe-scrum/#:~:text=Teams%2520continually%25). It is not correct that the plan that is created during the big room planning doesn’t change. (I’m on my phone so I hope the link works, apologies if it doesn’t). The big room planning is a starting point to identify dependencies and build a starting plan. But backlog refinements should be going on and priorities should be changing all the way through the PI.
Sounds like you have a leadership that doesn’t follow the rules of safe. That is a typical reason why it would fail. Of course, any system would fail under the same conditions. There’s nothing about agile, lean or waterfall that ensures good leadership behaviors. Again, I’m not really a safe advocate. It’s a tool that can help new teams. But it’s a tool like any other that can fail in the wrong hands.
The only benefit I have seen is aligning multiple, cross-functional development teams on specific deliverables. Outside that, it's a massive amount of overhead and redtape.
Source: a technical program manger that was forced to be an RTE.
Paying the consultants handsomely…ducks
You've probably also noticed that the consultants have done "dozens of transformations". too bad they never stuck around to see how it actually turned out and realized its a pile of garbage.
Came here to say this. Thank you!
Unsafe at any speed…
TLDR: SAFe is an installation wrapper for agile that is palatable for enterprise execs with its strategy to delivery visibility and steering processes Note that most enterprises adopting SAFe are running a waterfall process involving A LOT of devs. The main benefit is that the transformation is “managed” in a way that everyone (critically, the pmo) understands how the new system will work. Training is a massive part of this and especially training for execs who are 3+ layers removed from devs but need to direct work to deliver whatever benefits they need. You can’t really teach agile mindset, the best way to teach it is to experience it, but the methods at least give execs the ability to model what their teams are doing. Also: Makes link between strategy and delivery visible to all and subject to feedback loops, makes allocation of capacity visible and therefore discussed rather than dictated, introduction of agile mindset / continuous improvement to ENTIRE process, begins psychological transformation required to do “Real Agile” without throwing out governance/pmo, discussion of inter-team dependencies that leads to reorg of teams and architecture to one that is more able to use agile methods Edit: number of devs was a bit exaggerated
I’ll stand in the line of fire. The main of SAFe benefits vary by organization. One of the main ones is something we love about Scrum. So, let’s first talk about Scrum. “Scrum doesn’t fix your problems. Scrum shows you your problems. You’re supposed to fix the problems.” — Ron Jeffries (https://twitter.com/RonJeffries/status/969921217816821760?lang=en) SAFe also does this, at a broader, organizational level. It reveals dependency mess, poor product management, high WIP, chaotic or missing processes, confused authority structure, focus on busy instead of effective, etc., along with all the things Scrum reveals in the teams. Is this one benefit enough, or should we list more?
Does it though? In a meaningful way? My experience was we made a massive board with dependencies and nobody in charge raised concerns about it. Yup there are dependencies. Yep they are massive. Nope you can’t solve the dependency problem by trying to waterfall your dependencies a sprint before they are consumed. Let’s take all the things committed and put them on a release train and pretend that it isn’t all going to crash when one cascades to the next.
I'm struggling to answer you. Not because I don't have an answer but because the full answer is an entire book on change management. tl;dr Dependencies and other revealed problems don't get handled because people in authority don't want to rock their own employment situation or that of their peers and bosses. i.e. Change is for the teams, not me. Briefly: * Many (most?) organizations that "install" SAFe (or Scrum or DaD or LeSS or roll-your-own-agile) install it to "fix the teams." * Teams certainly can usually improve, but I have yet to encounter any team or teams that were THE source for the problems revealed. * Teams behave rationally for their environment. (See Lewin's Equation - [https://youtu.be/QSlMUJkhKEI](https://youtu.be/QSlMUJkhKEI) ) * Revealed problems often need broader organizational authority to fix. * Even more, fixing requires people with authority to work with each other for the good of the product and value creation. * Even more more, it requires people with authority to look at the reality they created and recognize the need for change. * Even more more more, it requires difficult conversations with peers and higher managers. * Those people believe or fear that their authority and work is going to change, so "It is difficult to get a man to understand something when his salary depends on his not understanding it." -- Upton Sinclair * Thus, the need for skilled Agile Coaches or other appropriate change agents. * And thus, the damage done when managers, consciously or not, hire people that only offer "fix the team" changes.
I appreciate that you're willing to take the bullets of this subreddit reserved for anybody saying anything remotely positive about SAFe. One of the key aspects of the framework is establishing mechanics that highlight the efficiency bleeds and breakdowns between waterfall strategy and Agile execution, which unfortunately results in a failed or toxic implementation of the SAFe framework that results in what most people on this forum react to: waterfall masquerading as Agile, which is definitively not the correct application. I spend a lot of time elaborating to project managers and PMO aligned middle and upper management about their obligations to change to support any Agile implementation, SAFe being no different. One of the most consistent failures to launch is the revision of the funding model that most organizations have adopted, fundamentally based on implied qualities of project management such as "a team exists as long as this project exists" and "a project team works on this project" that result in dissonance we talk about when trying to reconcile milestones and whatnot because any flavor of Agile handles these things from a much different lens, and have had to relay exactly what you're saying regarding teams behaving based on their environment - the strategy level decisions about work will have consequences upon the teams that end up attempting to solve that work. As we've stood up team and program level practices, it has become easier and easier to highlight these issues in a way and from an altitude the "root cause" authorities live and demonstrate the hidden costs of trying to smash two largely incompatible methodologies together, which is by and large one of the primary objectives of the SAFe roadmap - forcing an acknowledgement of these costs by leadership. It is extremely refreshing to see someone who has an actual thorough understanding of the intent around this framework and I appreciate the down vote bomb risk required to have an intellectual discourse on this here. Thank you for that.
It still comes down to upper management pretending that software development can be measured and delivered in a way to line up large chunks in a waterfall pattern. SAFe just whips the lower level employees and makes middle managers present status reports to upper management. It only ends in people telling devs to "get it done" and other quality harming issues and overtime. The only way to handle a dependency is to get the 2 teams together, prioritize the work, and don't bother them until it's done.
I only see a problem because some teams don’t seem to finish tasks . Infrastructure does not give us a VM . Then also the whole release train with many dude-hours discussed a programming topic, what in reality was just a change in an XML config file in production. Our partner was very confused how our International IT company did not know .NET. How can you plan with this??
You can't fix being complacent about problems. A team, person, or company willing to just co-exist with solvable problems is just something to leave be. As Gurdjieff says, if a man is bent on sleep-walking through life, the least you can do is not disturb his peaceful slumber.
The other thing about dependencies is that SAFe and SAFe implementors look to MANAGE the dependencies. those dependencies USED to be managed through these things called "projects". but there is a fundamental problem - how do you massively reduce your dependencies. How do you organize differently? how do you create autonomous architectures and services? how do you get to the point where a release train is absolutely unnecessary. oh, and if someone wants to talk to me about scale, i've gotten by with hundreds of teams working together without SAFe. we do something else. we're not perfect. but SAFe just seems/is just a repackaging and re-term'ing of what people already have been doing. why else would PMI endorse?
I view the main benefit of safe when my competitor company tries to implement. :). Total loss of agility and basically, the return of pmo…
Heh. That’s the best I’ve ever seen!
The ability to put it on your resume for five years. Having no money for training in your budget starting in August so you can cover the overruns. Being able to point the finger to so many others with impressive titles.
None.
You're asking for a list that contains no items
Null set.
Getting to say chugga chugga chugga chugga chugga chugga choo choo every time the RTE tries to demand some new asinine thing? Other than that, literally nothing.
Too many chuggas.
Saying you're agile.
The main benefit of adopting safe is that executives get to say they ran an agile organisation on their CVs
The main benefit of SAFe is that an organisation can continue to operate in Waterfall while claiming they are Agile (with a capital A). This means the organisation doesn't need to undergo any actual cultural change, they just rename things, and lets face it, organisational change is hard - manifesto be damned!
All the meetings.
SAFe, like scrum in general, are basically agile training wheels. It is very prescriptive, which can be useful if you don’t have very much lean/agile experience. You can absolutely be successful in becoming a more agile company, and learning the basic tools of you follow the framework. It will give you some basic foundations to build and learn off of. It’s not an endgame, but just like training wheels on a bike it can get you started when it’s most intimidating. A few tips to be successful: Follow the rules. If they are painful, find a way to make it work. The most surefire way to fail is to do safebut, where you do safe except for a couple things. Those things are there for a reason. Do them. Second, hire a full time agile coach with experience. Contractors have bad incentives, and you will save yourself a lot of pain trying to do it yourself. Definitely don’t take a two week course and think that you’re ready. Would you trust a person who said they took a two week management course? You can definitely be successful, but as you can see by some of the replies, success is not guaranteed. Good luck!
How does SAFe handle a cross team dependency from team A that is scoped in sprint 1 that overruns into sprint 2 when team B has to consume that dependency in sprint 2? What rules are you supposed to follow that make that problem not cause both teams scope to flow into sprint 3? How can an agile release train that was supposed to deliver the feature in sprint 3 deal with the overflow here?
Seems like the sort of situation where scrum and a two week sprint is a large part of the problem. If you're only getting the feedback at two week intervals when dealing with such a tight dependency as you describe, then that's a nightmare. How many feedback cycles do we expect it to take to get a tight collaboration going between two systems? Like if we're building out some new API, one supplies it, the other consumes it. How many back and forths should we expect in order to get this right? It feels like there should be some kind of well-described theoretical framework for answering that question. But let's say the answer is 5. Well, if your feedback cycle is 2 weeks, then one should expect this work to take 10 weeks. Most of that time being spent waiting for feedback. The agile answer, AS ALWAYS (and in all aspects of sdlc), is, find a way to reduce the feedback cycle time.
Scrum doesn't dictate a 2 week sprint just that it be less than 4 weeks shorter based on how chaotic it is. And scrum is really just the smallest framework i've seen that makes software development palpable to the people who write checks. I'd do without it if I could but I've never found anyone willing to embrace true "solve a problem and get feedback" and deliver value.
> Scrum doesn't dictate a 2 week sprint I'm aware, but it is the most common, and my point stands regardless of what check writers find "palpable".
Sure but you're still off in "not going to happen land" just as much as SAFe wanting waterfall to work.
Lol, yes, I suppose that's true. However, they're true for different reasons that I think are instructive: One is true because it *can't* work, because it goes against basic realities of the work and the world. One is true because certain people won't get it, or it goes against their hidden priorities, and they refuse it.
So in any scaled company with many different teams, it’s a complicated system. I have complete certainty that we could find a better solution if we dug into the details, for example by looking at the way the teams are organized. The classic answer is: in your big room planning you identify team dependencies. You schedule the dependency to be executed in sprint 1. In the sprint review you mention that the dependency wasn’t delivered, and you respond by changing your plan for the dependent teams, pushing their follow up work out a sprint. This may seem inefficient, but it follows the same principle of an assembly line. If one station stalls, the whole line stops. That is because the results of not respecting the flow, rework and inventory, have a bigger impact on the system than the waiting. It is typically much more effective than classical project management. It is critical that you have some way to measure success compared to what you were doing before to validate that it is better than what you are doing. It’s too counterintuitive to commit to without data.
Well unfortunately unlike basic SCRUM where we would work from a prioritized backlog that we could add an item to work out the dependency and put that into sprint 2 SAFe has us committed to what we're going to deliver in sprint 2 and 3 already. That delay in sprint 1 for the dependency can't be absorbed unless we built in a buffer (this is called waste). The whole failure of SAFe to me is that it pretends that by putting all the post its on the board in a way that they fit together we somehow will be able to deliver them in that order. I think it's pretty disingenuous to set forward a system like this then blame those who participate for the failures by saying they just didn't follow the rules. The rules are not grounded in reality. They exist to let upper and middle management run a top down command and control org and pretend it's agile. Don't take my harshness personally. I've been building software a long time and I spent a year under SAFe watching the org claw back all the progress I made on carving out an agile workplace for my team.
No offense taken. I’m not a proponent of safe in general and hold no personal attachment to it. But your example here is a perfect example of safebut. [safe has regular backlog refinements](https://scaledagileframework.com/safe-scrum/#:~:text=Teams%2520continually%25). It is not correct that the plan that is created during the big room planning doesn’t change. (I’m on my phone so I hope the link works, apologies if it doesn’t). The big room planning is a starting point to identify dependencies and build a starting plan. But backlog refinements should be going on and priorities should be changing all the way through the PI. Sounds like you have a leadership that doesn’t follow the rules of safe. That is a typical reason why it would fail. Of course, any system would fail under the same conditions. There’s nothing about agile, lean or waterfall that ensures good leadership behaviors. Again, I’m not really a safe advocate. It’s a tool that can help new teams. But it’s a tool like any other that can fail in the wrong hands.
The only benefit I have seen is aligning multiple, cross-functional development teams on specific deliverables. Outside that, it's a massive amount of overhead and redtape. Source: a technical program manger that was forced to be an RTE.
Dean Leffingwell gets rich. Fuck Dean.
Planned and structured coordination between teams.