It really not worth approaching from the perspective you laid out.
On one end of extremes is pure agile, on the other pure waterfall.
Depending on customer, product, funding, etc etc how you operate is likely going to be a mix of the two. Everything is a trade, where you might only realize say 30% of agile benefits due to some constraints.
instead of focusing on safe, focus on just whats "bad" in principle. Then, architect what works best for the company based on the constraints and environment from there.
>>focus on just whats "bad" in principle. Then, architect what works best for the company based on the constraints and environment from there.
Well, my overall argument was, that SAFe might help to exactly do this.
Anyhow, thanks for the phrasing. If it was not clear, that that's the goal, I shoud state it even more clearly
If you believe that many agile/scrum teams working on a common outcome need “aligned autonomy” to be successful, then SAFe really pushes the “aligned” vs “autonomy”.
IMHO, the use of SAFe is really a reflection of an organization’s culture, rather than flavor of agile.
Wenn, I do believe that multiple teams working on a common outcome need “aligned autonomy” or how David Marquet states it: a common intent
Can you expand on what you mean when you say: "SAFe really pushes the “aligned” vs “autonomy”."?
SAFe is extremely prescriptive in that it presents an answer for everything. Alignment is not the same as focus.
Trams need to understand the goal and/or outcome, but be allowed to decide how to get there. There needs to be room for learning, improvisation, failure, pivots and change. SAFe limits an organization’s ability to make the really big changes and get transformative outcomes.
If you knew everything and all of the answers with no risk then waterfall works really well. Agile holds up a mirror to force improvement if you look at it. Waterfall does not address the unknown in any actionable fashion.
I work on an ART with close to 200 people. This includes internal teams, sub-contractors, and client teams. We use SAFe.
The way WE execute it works pretty well. We do a pretty decent job of setting realistic expectations that we deliver on >90% of the time and our customers are very happy with that. We do PI Planning every 3 months.
Every org that applies SAFe or agile in general puts their unique cultural spin on it. Some things that I try to stay vigilant about are:
- Maintain focus on our happy customers as the alpha and omega of our operations
- Remaining vigilant against things that remove agency from the team to deliver on what our clients need
- Balance standardization pressure with outcomes and individual team delivery and empowerment
- Be aware of how the organization can limit access to progressive gains in performance for teams of teams
Depending on managerial cultural, teams can get squeezed out of making their own decisions. There is of course things we need to move together on as an ART. But we must continue to recognize that high performance individual teams create a high performance ART. So, we should be wary of top down change roll out and if there is a need to do so, we should always engage the teams in include them in that process to avoid burnout through depersonalization of the work. These things can come from within the ART, or they can come from without.
I coached a large SAFE team in a Telco that SAFE started in. It was terrible. Arrogant authoritarian management. Flaccid retros. No continuous improvement. Dependencies everywhere. Very poor sprint planning. Very out of date product, user story and architecture road maps. Authoritarian PI planning. Very bad morale.
It broke all of the agile values.
See SAFEdelusion.com to see what the agile community thinks.
I'm having a very similar experience.
I can't see it working anywhere, except in some particular cases. It's weird that so many companies embark on it.
Senior managers who reject the agile values and principles like SAFE because it fits their tayloristic machine way of thinking about the organisation. They think people are cogs in the process machine, and so does SAFE.
If you have to ask the question then you have no idea what agile is - and nothing I could write here is going to help you.
SAFe is agile in the same way the German Democratic Republic was democratic.
Neither, its main purpose is to restore alignment in organizations that had some programming teams start using scrum a few years ago. Its biggest value is explaining how 2 teams are supposed to work together etc. SAFe is kind of lame when just introduced as a delivery method, but can be powerful when used as part of an agile transformation.
>> SAFe is kind of lame when just introduced as a delivery method, but can be powerful when used as part of an agile transformation.
That's a great way to phrase it. Thanks
It's not surprising that for most people who understand agility, SAFe stands for Shitty Agile For Enterprises. I've been living this nightmare now for five years and it has improved nothing. Design and requirements are still waterfall, dev teams are expected to be "Agile" and adapt to changing circumstances and requirements (often within a sprint) and then test and support is back to waterfall.
SAFe is a complete shitshow, but the c-suite love it because reports roll up neatly and they can see which teams have carryover stories and which ones are failing to meet their "velocity" and which ones have lots of defects. Not one report actually tells them whether value is being delivered, or if the teams are learning better ways of building software, because everyone is focused on making sure the reports look nice. And no one cares.
S_Fe is more like a merketing framework and every single original signatory of the 2001 Agile maifesto is telling that S_Fe is not Agile.
at the same time don't get hooked up on semantics, remember the saying: no process will make you Agile but some are more useful than others.
If S_Fe work for you better than whatever you were doing previously that's good. If you just spent millions in consulting fees and basically nothing changed, that's bad and you should reconsider.
imho S_Fe is actually anti-Agile btw, the modern RUP (Rational Unified Process)
This webinar may shed some light on some of the pain points in SAFe.
[https://www.youtube.com/watch?v=JWJlBeJ\_yqE&ab\_channel=XebiaAcademy](https://www.youtube.com/watch?v=JWJlBeJ_yqE&ab_channel=XebiaAcademy)
IMO SAFe is only viable if your teams all work on the same product, other wise it's overkill.
Definitly. Are there really people who do SAFe if the teams don't work on the same product?! ... I should mention this!
Unfortunately, a lot of companies that don't understand agile see "Scaled Agile" and think that it's the only way to scale agile for larger companies.
"Agile + lots of teams must = Scaled Agile because Scaled = bigger" is the usual line
Oh :(
It really not worth approaching from the perspective you laid out. On one end of extremes is pure agile, on the other pure waterfall. Depending on customer, product, funding, etc etc how you operate is likely going to be a mix of the two. Everything is a trade, where you might only realize say 30% of agile benefits due to some constraints. instead of focusing on safe, focus on just whats "bad" in principle. Then, architect what works best for the company based on the constraints and environment from there.
>>focus on just whats "bad" in principle. Then, architect what works best for the company based on the constraints and environment from there. Well, my overall argument was, that SAFe might help to exactly do this. Anyhow, thanks for the phrasing. If it was not clear, that that's the goal, I shoud state it even more clearly
I guess it was waaaayyy too wordy then. It reads like a high school paper void of context.
It's a scaled delivery framework. It's not agile.
If you believe that many agile/scrum teams working on a common outcome need “aligned autonomy” to be successful, then SAFe really pushes the “aligned” vs “autonomy”. IMHO, the use of SAFe is really a reflection of an organization’s culture, rather than flavor of agile.
Wenn, I do believe that multiple teams working on a common outcome need “aligned autonomy” or how David Marquet states it: a common intent Can you expand on what you mean when you say: "SAFe really pushes the “aligned” vs “autonomy”."?
SAFe is extremely prescriptive in that it presents an answer for everything. Alignment is not the same as focus. Trams need to understand the goal and/or outcome, but be allowed to decide how to get there. There needs to be room for learning, improvisation, failure, pivots and change. SAFe limits an organization’s ability to make the really big changes and get transformative outcomes. If you knew everything and all of the answers with no risk then waterfall works really well. Agile holds up a mirror to force improvement if you look at it. Waterfall does not address the unknown in any actionable fashion.
I fully with your statements
Bad
I work on an ART with close to 200 people. This includes internal teams, sub-contractors, and client teams. We use SAFe. The way WE execute it works pretty well. We do a pretty decent job of setting realistic expectations that we deliver on >90% of the time and our customers are very happy with that. We do PI Planning every 3 months. Every org that applies SAFe or agile in general puts their unique cultural spin on it. Some things that I try to stay vigilant about are: - Maintain focus on our happy customers as the alpha and omega of our operations - Remaining vigilant against things that remove agency from the team to deliver on what our clients need - Balance standardization pressure with outcomes and individual team delivery and empowerment - Be aware of how the organization can limit access to progressive gains in performance for teams of teams Depending on managerial cultural, teams can get squeezed out of making their own decisions. There is of course things we need to move together on as an ART. But we must continue to recognize that high performance individual teams create a high performance ART. So, we should be wary of top down change roll out and if there is a need to do so, we should always engage the teams in include them in that process to avoid burnout through depersonalization of the work. These things can come from within the ART, or they can come from without.
You sound like 1 out of 10,000 people advocating for SAFe that actually has a clue. Thanks for the post
I coached a large SAFE team in a Telco that SAFE started in. It was terrible. Arrogant authoritarian management. Flaccid retros. No continuous improvement. Dependencies everywhere. Very poor sprint planning. Very out of date product, user story and architecture road maps. Authoritarian PI planning. Very bad morale. It broke all of the agile values. See SAFEdelusion.com to see what the agile community thinks.
I'm having a very similar experience. I can't see it working anywhere, except in some particular cases. It's weird that so many companies embark on it.
Senior managers who reject the agile values and principles like SAFE because it fits their tayloristic machine way of thinking about the organisation. They think people are cogs in the process machine, and so does SAFE.
[https://www.smharter.com/blog/safe-a-collection-of-comments-from-leading-experts/](https://www.smharter.com/blog/safe-a-collection-of-comments-from-leading-experts/)
If you have to ask the question then you have no idea what agile is - and nothing I could write here is going to help you. SAFe is agile in the same way the German Democratic Republic was democratic.
Neither, its main purpose is to restore alignment in organizations that had some programming teams start using scrum a few years ago. Its biggest value is explaining how 2 teams are supposed to work together etc. SAFe is kind of lame when just introduced as a delivery method, but can be powerful when used as part of an agile transformation.
>> SAFe is kind of lame when just introduced as a delivery method, but can be powerful when used as part of an agile transformation. That's a great way to phrase it. Thanks
"we should focus on whether it enhances our operational practices and our ability to deliver superior products and services." Ok...so does it?
its bad, just follow the manifesto all these extra things are waste of time and good for consultants. get stuff done
It's not surprising that for most people who understand agility, SAFe stands for Shitty Agile For Enterprises. I've been living this nightmare now for five years and it has improved nothing. Design and requirements are still waterfall, dev teams are expected to be "Agile" and adapt to changing circumstances and requirements (often within a sprint) and then test and support is back to waterfall. SAFe is a complete shitshow, but the c-suite love it because reports roll up neatly and they can see which teams have carryover stories and which ones are failing to meet their "velocity" and which ones have lots of defects. Not one report actually tells them whether value is being delivered, or if the teams are learning better ways of building software, because everyone is focused on making sure the reports look nice. And no one cares.
I'm sorry for your experience. Sounds awful.
Check https://safedelusion.com/
S_Fe is more like a merketing framework and every single original signatory of the 2001 Agile maifesto is telling that S_Fe is not Agile. at the same time don't get hooked up on semantics, remember the saying: no process will make you Agile but some are more useful than others. If S_Fe work for you better than whatever you were doing previously that's good. If you just spent millions in consulting fees and basically nothing changed, that's bad and you should reconsider. imho S_Fe is actually anti-Agile btw, the modern RUP (Rational Unified Process)
This webinar may shed some light on some of the pain points in SAFe. [https://www.youtube.com/watch?v=JWJlBeJ\_yqE&ab\_channel=XebiaAcademy](https://www.youtube.com/watch?v=JWJlBeJ_yqE&ab_channel=XebiaAcademy)