12 ms·

The SAFe Delusion

304 points by clockworksoul 4y ago

29athrowaway 4y ago
I like this take on SAFe. Steve Denning has great talks about what agile is, and what it is not. https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/ https://www.forbes.com/sites/stevedenning/2019/05/23/underst... The SAFe training is predominantly a bunch of pointless games, marketing, and baseless claims. Leaving all that aside, it's just fake agile.
- synu 4y ago
  It’s agile for companies that absolutely do not want to adopt agile but want to be able to tell their (prospective) employees that they have.
  - 29athrowaway 4y ago
    That is a nice way to describe it. SAFe puts a bunch of layers between you and the customer. Agile is about removing layers between you and the customer.
  - ResearchCode 4y ago
    Are employees looking for "agile" companies? Seems more like a red flag for micromanagement nowadays.
    - synu 4y ago
      My personal experience is that, while you’re absolutely right for startups, large multinationals and companies that don’t see themselves as necessarily tech-first still use it as a selling point. I don’t know if it is effective to do so or not, but I do see it highlighted on job ads/recruiting landing pages.
    - 29athrowaway 4y ago
      Better to be micromanaged by 1 person than 10.
yborg 4y ago
I was originally trained as a lad in classic waterfall and was a CMM auditor at one point - I got SAFe certification a few years ago and my overwhelming impression was that they had replicated all of the flaws of these methodologies, just with the word "agile" inserted wherever possible. I suppose that it is the final representation of the principle that any revolution becomes the new orthodoxy in a generation and ends up as ritualized as what preceded it.
- onli 4y ago
  I thought Scrum would be more a candidate for that, when the rituals from there become useless orthodoxy. If (since) SAFe implementations are just waterfall with all its flaws rebranded, it's more the counter-revolution disguising itself.
  - roguecoder 4y ago
    As soon as people forgot that Agile was about organizing workers & having management trade its power for more-valuable software, it was basically doomed. Executives would rather give money to the people who promised that they could get the more-valuable software without giving up any of their power and control.
rileyphone 4y ago
I strongly agree with this, but you need some more editing, especially to convince the leadership types that keep making this mistake.
- nvr219 4y ago
  Agreed. The decision makers at my company would not read this.
- cpeterso 4y ago
  And if you’re going to say “Don’tdo SAFe, you sure suggest some alternatives.
brightball 4y ago
I'm a SAFe certified SPC and RTE. Also a programmer with 20+ years of experience. IMO the only real issue with SAFe is that the quality of trainers have probably become diluted. If you have a SAFe instructor without a programming background to go along with it who can understand how all of the pieces involved will affect the people and the process, you're going to end up with pure by-the-book rigid implementer...because they probably don't know any better. I was drawn to SAFe after posting a lot of venting thoughts on my blog, that got picked up here and somebody on this forum recommended a fantastic book to me. The Principles of Product Development Flow: 2nd Generation Lean Product Development by Donald Reinertsen. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 This book is not rigid, nor are the principles within it. I used those principles to very successfully run a development group, but I was failing at consistently involving the business side of the house effectively. I looked around for something more formal that was based on his work and I found SAFe. Going through the training, it's about 80% based on that book. You'll recognize all of the underlying principles. But I took so many classes on it because I wanted to make sure I understood SAFe well enough to know the goals of it's structures so that I knew how to adapt effectively. I don't think a lot of SAFe instructors do that. So here's what you need to know about SAFe. They flat out tell you, you are NOT trying to fit the organization into this structure. You're trying to see how the principles of this structure can benefit your organization. If you want an effectively summed up list of the keys of SAFe from everything I've learned it's this: 1. Continuous Delivery & Deployment are the primary goals of this structure. There is a huge focus on development pipeline automation and all of the efficiencies that come from it. I have no idea why anyone would think otherwise based on comments in that link, because it's absolutely core to the entire process. 2. Prioritization without emotion. SAFe prescribes a formula based approach to prioritization that is essentially a dressed up Return on Investment formula called Weighted Shorted Job First. It recommends structures to get a lot of representatives from the business side of the house to go through and apply relative weights to 3 different factors to establish a Value metric called Cost of Delay and then counts on the technical side of the house to estimate the workload. This helps you prioritize in a way that factors in Opportunity Cost. You have X amount of developer time, if you spend it on this you can't spend it on that. This process is FANTASTIC for everyone involved except the person at the company who is used to getting things prioritized by yelling the loudest. On the business side, everybody has a clear place to have a voice in the company priorities. On the dev side, you never get the "everything is top priority" answer that is so common. 3. Feature Flags. This is one of the absolute keys from a best practices perspective and it also critical for a continuous delivery environment. It allows dev to deploy to production behind a flag rather than hold stale branches while waiting for marketing, product, etc to give feedback, documentation etc. Product gets the benefit of being able to show features to specific clients, gather feedback, etc in a production environment while everyone else can prepare to release when they are ready...without having to bog down development with that entire process. The idea of separating Deployment from Release is hard for a lot of people to wrap their heads around. The biggest complaints that I see around SAFe are that it's too rigid and/or that it's waterfall. It's neither of these things. It's made to be adapted to your company and all it involves is a collection of best practices that work really effectively together. They adopted a lot of current practices, like Scrum, into Reinertsen's work because it's easier for an organization to adopt it if they think they're already doing a lot of it. Each team within a SAFe environment can use Lean, Scrum, Kanban, etc. It's up to the TEAM entirely. Scrum structures are just there because a lot of people are already using them. As for the waterfall bit, I reject this entirely. There's a large group of people out there that seem to think even acknowledging a dependency means you have a waterfall process and I bristle every time I hear it. The PI Planning structure allows you to coordinate team planning over 8-12 weeks. Have you ever been in a scrum environment where the teams didn't have a clear path to coordinating? It's awful. Moreover, the structure allows (and insists) that your developers actually provide the plan. This means nobody else has handed you a deadline and your entire team gets to have a dialog about what can be done in what amount of time. You discuss tradeoffs with management if they ask for the world and they only really need a piece and then discuss how to get that piece. How many environments leave developers out of this process entirely? Just handing you tasks? I'm a huge fan of SAFe because it's goal is to provide an environment where developers can thrive. Every time I see comments about SAFe and ask questions about it, I get responses like "they didn't do that in our SAFe implementation." That's because your upper management nixed it. It's not because it wasn't supposed to be there. Personally, I'm a huge SAFe with Kanban advocate. If you have questions about SAFe at your company or you simply want a second opinion on what you're being told, feel free to hit me up. I'll be happy to answer any questions that I can.
orzig 4y ago
I read as much of the site as I could, but could somebody explain: how is SAFe different than the original agile manifesto?
- fidrelity 4y ago
  The agile manifesto does not dictate any team or organisational structure. SAFe prescribes a bunch of structures, councils and processes. It is by design anti agile. Edit: this image highlights the paradox: https://www.agilest.org/wp-content/uploads/2018/03/scaled-agile-framework-4-5-big-picture.png https://www.agilest.org/wp-content/uploads/2018/03/scaled-ag... Just try to count all the roles and processes prescribed.
  - gherkinnn 4y ago
    Very lean indeed.
  - isoprophlex 4y ago
    If anyone comes and tries to sell you stuff using a chart that looks like that, better show them the door immediately. That thing seems optimized to cause upper management hypnosis by its expertly designed cavalcade of hollow bullshit terminology.
    - FridgeSeal 4y ago
      I've never seen this chart before, but I've worked with people previously that I know would get instantly giddy with excitement looking at this. The meaningless terms, the disconnected-flow-chart-but-not-a-flow-chart, the deluge of acronyms, the weird visuals and the inscrutable words and relationships, it's all there. It's a document I'd attempt to create if I was trying to parody consultants and business shenanigans, but it's real.
  - db48x 4y ago
    I’m having an allergic reaction after looking at that chart. Where did I put that epipen?
  - 4y ago
flerchin 4y ago
The thoughtworks case study is repeated. Otherwise wholeheartedly agree. I have delivered plenty of software during 10 PIs, but that was in-spite of SAFe, and the whole thing was harder and slower because of it. Since then, I reorganized a team of ninjas away from the trains and have delivered at 3x the velocity using kanban methodology.
swagtricker 4y ago
Don't forget the classic parody of SAFe which shows it as the overblown "waterfall in agile clothing" that it is: LAFABLE. https://www.lafable.com/ https://www.lafable.com/
mindwok 4y ago
I view the implementation of SAfe anywhere as a huge red flag. To me it suggests that the decision makers read about Agile and what it proposes and decided that for whatever reason they don’t want it, in its unfettered form it scares them, or they don’t understand how to adopt it. As someone who prefers working in Agile workplaces, that tells me all I need to know.
- JamesSwift 4y ago
  My experience in an org that introduced SAFe during my time there, was that it was actually a misguided bottom-up introduction. A couple teams went agile and found it really effective then thought "if it was this effective for 1 team just imagine if we scaled it up to everyone!". Spoiler: I will likely never work for another SAFe org again.
electrondood 4y ago
At my last company we used SAFe and I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, with dependencies between teams, with wiggle room/flexibility, by the end of the event. I understand this can depend on how well it's implemented, but in my experience I've never seen anything like it before or since.
- bl4ckm0r3 4y ago
  How big was the team and what type of project? And what amount of level of detail did you put in the planning/roadmap? Did you also had experiments and investigations taken into account?
- kqr 4y ago
  > Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, This is the part I don't understand. What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months?
  - ThalesX 4y ago
    Three months!? Is this the stability we expect from companies in our day and age? I would think it's a lost company, one that couldn't somewhat predict what the next three months are going to look like.
    - pflenker 4y ago
      Just look back 3 month and assess how many of the things that happened were predictable (keeping in mind the fact that hindsight is 20/20). I wager every company in the world was affected by the world wide changes right now. Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change.
      - ethbr0 4y ago
63 4y ago
As someone who just finished a week of 8 hour PI planning meetings with another week of the same starting Monday, I wholeheartedly agree. My experience of SAFe has been shorter term waterfall with a couple steps cut out. It's definitely better than waterfall and I'm grateful for that, but I wouldn't call it agile.
- roguecoder 4y ago
  It follows the outline of taylorism, just one level up from the team: measure, control and manage.
- tootie 4y ago
  SAFe almost feels like a ploy lead by waterfallistas to sneak their agenda back into the mainstream and call it "agile" to fool everyone. It's a shame because there is room for a toolkit to help scale agile. There aren't great tools for managing dependencies between agile teams.
- brightball 4y ago
  A week? It’s supposed to 2 days. 2.5 if you are partially time shifted.
  - throwaway93494 4y ago
    I mentioned this in another reply, but it bears repeating. Our current PI planning is 2 weeks not counting the half day before in Pre-Planning for PI Planning. I sincerely wish that was a joke. It's a 4 hour team wide meeting to review all work items are ready to be planned during PI planning, as well for us to identify dependencies and schedule meetings with those dependencies. There isn't enough time to to that during the actual planning.
ChuckMcM 4y ago
What SAFe does is provide some sort of visibility and accountability to senior management. (Which waterfall did before it) Until the Agile community can come up with a reliable way of identifying and firing the low performers for senior management, they will keep pushing down requirements like SAFe on the organization. Fortunately, the level of opacity between budget managers (P/L) vs execution managers usually doesn't get this bad until you've got 10 - 20K employees.
- ResearchCode 4y ago
  How does SAFe reliably identify "low performers"? Top companies tend not to do SAFe, I don't see the issue this solves. But I'd easily see SAFe creating low performers.
  - ethbr0 4y ago
    By mandating visibility. And let's be honest, SAFe is not for "I can attract talented people who can self-manage" companies. It's for "75% of my developers are scraping the bottom of the barrel, but I take what I can get because my company isn't sexy."
- bitwize 4y ago
  > What SAFe does is provide some sort of visibility and accountability to senior management. This is true of all Agile methodologies adopted by corporations. If it weren't true, the methodology would not be adopted.
mrweasel 4y ago
I've never worked in an organisation that used SAFe, but to be honest I've never worked for one that used SCRUM either. The only semi-structured method I've ever been part of has been "SCRUM BUT". What I find weird about both SCRUM and now SAFe is that pretty much every single agile expert I've read articles and blog post from dislikes it. My take away is that the agile purist, if you can call them that, are focus on delivering high quality software and user satisfaction, that's the focus, that's the goal. SCRUM and perhaps now SAFe (presumptuous acronym btw) seem to be focused on managing software deliveries in larger organisations. As some one who studies software engineering and process management 18 years ago, I can't say that time has made me think that things have improved much over time. I am especially skeptical of processes that comes with certifications and titles. The original agile manifesto is beautiful in that it's something we can all do. There's are no training, no certification, no corporate backer. Its principles, and you can either agree or disagree, is something the team can reflect and meditate on how to best incorporate the ideas into their work. Overall, more and more I start to think that PHK was right in his talk "Entirely Predictable Failures" in 2012[1]. It's snake oil, almost all of it. [1] https://www.infoq.com/presentations/Predictable-Failures/ https://www.infoq.com/presentations/Predictable-Failures/ (At around 24:30 and a few minutes from there).
- 29athrowaway 4y ago
  Scrum is not an acronym.
csours 4y ago
SAFe is not about software development or planning. SAFe is about funding software development in a cost center. I haven't seen anyone address how to do the accounting for software development for a large organization, where that software is not being sold for money.
- ethbr0 4y ago
  Internal billing + discretionary "keep the lights on" budgeting? It has its flaws, but it's not the worst approach.
- roguecoder 4y ago
  You are absolutely right about the short-sighted problems created by incompetent finance models. I've seen two successful approaches in practice. The first is vertically integrated companies using easily-measured labor-saving techniques like ML to justify the infrastructure costs required to support those innovations. And the second is places where workers have the institutional power to advocate for investment in the tools they have to use. It seems to me that there should be an effective strategy where we treat software as capital spending that gets appropriately depreciated, but mostly what I see is finance departments trying to micro-manage development and in the process costing their company a lot of money.
SSLy 4y ago
SAFe is bad, but is there anything better when you have, say, 1500 devs, and expect two fat releases a year with whatever required bugfixes between?
- Smeevy 4y ago
  Doesn't that fundamentally undercut the incremental value delivery and CI/CD progression that SAFe promises?
  - derekbaker783 4y ago
    Yes
- yakshaving_jgt 4y ago
  > is there anything better Yes. Not doing SAFe.
- 29athrowaway 4y ago
  The max size of an ART is 125
ButterWashed 4y ago
I'm currently a year into a role as Lead SRE in team working in SAFe. We plan five 2 week sprints for which we immediately write off 50% of our time as "BAU activities" and the rest of our time is spent lurching from one deliverable to another in the hope we actually achieve something before we get "re-prioritised" yet another time. It's not even SRE, it's 2nd line support and platform engineering. I really have no idea how SAFe works or how it's meant to work, but everyone seems happy so long as I complete my JIRA tickets on time because that's what the users want.
- ethbr0 4y ago
  I worked for a SAFe company like that once. Took a salary cut for another job. Haven't regretted the choice for a second: life's too short to waste one's talent in service to a bad employer.
- BizarreByte 4y ago
  I don't know if we claim to use SAFe were I work, but this sounds very similar to my experience. It frustrates me to no end, but as a contractor I don't get a say and the full time employees seem to be okay with the status quo. I am constantly amazed that any working software comes out of such a process, but against all odds it does.
retrocryptid 4y ago
This seems a bit of a hit piece, but it seems like a safe target as at least half the people I know seem to hold it (SAFe) in disdain. I've consulted for organizations that started using it and have a mostly negative opinion. Organizations that are in near complete disarray may find it useful; but then again, they might also find a return to old-school waterfall useful. Where I've seen SAFe not work so well is organizations that are doing reasonably well with planning, but have some deficiencies or some corners of the organization that aren't doing too well. Traditional Agile doesn't scale well above the team level (not that it's bad, it's just that benefits from its processes don't seem to be focused on that level of the organization.) Scrum of Scrums is rarely executed well and Lean and XP don't really describe practices for that echelon. (I'll have to re-read my Kanban books and see if it addresses it.) My take on SAFe is that it rigidly adds dependencies between teams, even if such dependencies are counter-productive. But like the manager who uses the daily standup as a status meeting, it seems like it's serving the "bean counters" instead of the people doing the work.
faangiq 4y ago
It’s well known at this point that Agile and any other “methodology” is a scam. The only thing that matters is raw IQ everything else is just kabuki paper shuffling.
- i_like_apis 4y ago
bane 4y ago
SAFe seems to be a bit like "internet scale", it's designed for very large organizations building very large single software solutions. Most organizations wildly overestimate their size and the size of their solutions. A Microsoft Office release probably can benefit from SAFe, an update to an auth microservice maintained part/time by a team of .75 FTE doesn't. SAFe seems to sort of be a micro-waterfall approach inspired by Conway's law [1]. It build massive communication and coordination teams so that this gets reflected into short-term development waterfalls that produce software that mirrors the system that managed it. But this team needs to be dwarfed by the development effort they are trying to push forward or they'll end up dominating all of the activities with largely useless communication and coordination activities resulting in very slow forward software movement, confused goals and priorities, and overstaffing of projects. Example: I once ran a team that was developing some internal tools for a large org, but we were outside of the main SAFe effort. At one point we became dependent on some service the SAFe effort was going to produce. It took 60 people 3 years to not produce a correctly working service. Exhausted with this, I finally just had 1 person build the service we needed as a stopgap. She spent 3 months building it with part-time support from one other engineer for a couple weeks. More than 3 years later that is the service that's still running and the SAFe effort never did manage to get a properly working solution out the door. I can think of half a dozen similar examples where the parallel effort by a smaller team with less organizational overhead radically outperformed the giant SAFe team -- and they did it mostly by just ad hoc communication channels between the small teams. 1 - https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law
- RajT88 4y ago
  I took a SAFe training class once, and they explained that Wal-Mart does this sort of exercise quarterly. Rents out a warehouse, flies in all the dev managers and leads, and does sprint planning using all the boards they have stood up everywhere. I am not commenting on how effective it was for them of course. It seemed to me to be a bit overkill for the size of the company I was in (about 5k people).
  - marcosdumay 4y ago
    Getting everybody together once in a long while, and synchronizing a "what are you working on?" is a good exercise. But only if that while is long.
mkw2000 4y ago
I had a recruiter mention to me that the company is all about SAFe and I should express my interest and enthusiasm for it during my interview. I looked it up, saw a diagram describing the process that actually made me burst out laughing and ran far away from said company.
heynowheynow 4y ago
When consultants suggest a "new" fad, they're all about charging money to help businesses adopt that fad to avoid FOMO. Predictably, there will be a new fad next year and the year after that. Waterfall: elevator control systems, agile: expense reports UI, and apply a blend to things in between.
- doctor_eval 4y ago
  100% agree. I worked at a large telco where this happened. Brand-name consulting company “changed methodology” half way through the project and charged the customer for it. I couldn’t believe it. But then again, we were quite literally the only team that delivered a product, so naturally we were seen as a threat and our contract was cancelled. True story.
  - heynowheynow 4y ago
    Those who can't tend to hurl negativity and sabotage at those who do. Or people who are too dumb or lazy to try language X or approach Y (minus fads) tend to reiterate how wonderful their stale way and obsolescence are. There are people at my work (MAANG) who say Rust is too "esoteric" and "impractical" despite the whole company and industry moving that way, but they're comfortable in just now finding Go and being religious about it, maybe 8 years late to the party that's now over because it's "worse is better" shit in the long term. I'm looking around because I think my team is doomed since it lacks coherent leadership (the lead was playing with VR and skipped their own conference), it's full of "senior" people who lack professional career development goals and are uninterested in leveling, they're fine with ignoring software craftsmanship and tech debt, and they don't interact with me with any regularity. I can't get anything done or propose any ideas because the lead looks at me like Tucker Carlson before I can finish a sentence. They don't include me on anything, so I don't know why I'm there.
ineptech 4y ago
I don't really understand SAFe, but from the outside looking in, it seems like the answer to "How close can we get to agile while still employing an army of Project Managers?" Which is to say, not very.
- vesinisa 4y ago
  SAFe not only keeps middle managers employed and feeling important but also forces lots of unnecessary pencil pusher type work on the engineers and designers. It's a strain on all parts of the organization that are forced to use it. This is why most companies will abandon SAFe after a couple of years, like the case studies show. I have personally left one employer (a bank) because SAFe made the job unbearable. Both this company and their larger competitor abandoned SAFe after a couple of years. I now categorically ignore any gigs and openings at companies using SAFe - it's a glowing red flag to me.
  - teeray 4y ago
    I have also left an employer with MBAs that continually tried to find and mandate the One True Way of building software. I noped out when I found myself in multiple status meetings every day repeating myself to different middle managers (and having to update a Slack status channel as well). Spoiler: they adopted SAFe after I left, which told me everything I needed to know about SAFe without having to experience it firsthand.
JulianMorrison 4y ago
In my experience, if what you've got is a months-ahead plan where management sets the deadlines AND controls the scope via pressuring the line manager, and delivery relies on crunch time and panicky de-scoping and working to the letter and not the spirit of the contract, then what you have is waterfall in a fedora and a Groucho Marx novelty disguise.
sas224dbm 4y ago
I have been involved in 2 medium sized-ish (~300) software support projects for western-nation's land forces project that brought in SAFe with a fanfare. Lots of ($$) training, everybody gulping down the coolade etc etc. It started off OK, but as with most of these ideological methodologies, our projects' circumstances started to clash with the SAFe 'way'. Our customer was very fond of his existing rituals (meetings, committees, progress meetings etc), but we also folded in all the SAFe rituals too. It seemed we were in meetings too much of the time, and we did a poor job of convincing the customer to move wholesale to the SAFe way. In addition, the organizational structure and governance models never operated in the SAFe way, with the customer's insistence on being in our shorts on every decision hampered most of the 'delegate decisions as deep as possible' philosophy. At the end of the day, it steel feels like RUP re-invented for 'agile' .. never again.
dunno7456 4y ago
This is a reflection of agile brin dead on the water when it comes to it's promises.
twawaaay 4y ago
I wasn't aware of SAFe until one new manager got our director to loose his head for it and institute it in all teams. It was a total disaster. The idea of Agile is for each team to be responsible to improve their processes. Because improvement loops involving higher management are taking forever to complete and because each team has its own needs. "Agile" (quotes intentional) as practiced today is bad enough -- teams are not really improving their process, only implementing something taken from a book. SAFe is taking it one step further by absolutely obliterating team's ability to influence the process. At least with "standard Agile" it was possible for some teams to do the right thing, as long as they had a manager that understood what Agile really is. With SAFe that was gone. I was told that we can't even modify our t-shirt sizing because "It has to be standardised, otherwise there would be too much chaos. BTW, we are definitely not creating a new request form to change t-shirt sizes in Jira" Forget about changing any other part of the project. We had a bunch of testers and business analysts which did absolutely nothing but had to stay on the team because they were required in the process by higher management. We did not need them. I spent time hiring people who could do the work from discussing requirements with the business people through design, implementation up to deploying it to prod, but that did not matter. Talk about crazy projects...
- closeparen 4y ago
  The middle manager brain has "consistency" as a terminal value. Being responsible for more activity than they can hope to substantively understand, they "need" systems that make it all look the same so it can be measured, summarized, compared, etc. Otherwise they get the intuitive sense that it's all chaos and mayhem and can't possibly be working well. It's the same sort of thing as an architect being mad that different services have different internal architectures, tech stacks, code styles. It's true that such differences make it unreasonably difficult to understand or manage things at the abstraction level of the middle manager or architect's portfolio. But it misses the question of how and whether things should be managed from that level at all. Often you have someone stepping into a working bottoms-up emergent order (like the internet, or a market economy) hamfistedly trying to implement top-down central planning control. SAFe is a tool of choice for these attempts. The radicalism of "true agile" is not about the duration of the planning cycle, but about the level of autonomy and control vested way down in the leaves of an org chart.
brightball 4y ago
I’m going to summarize my earlier comment with this: SAFe with Scrum teams (how instructors are taught SAFe) merely adds more ceremonial meetings and sucks for everyone. SAFe with Kanban teams trades the scrum ceremony for less frequent SAFe ceremony and is a much better experience for developers. SAFe corporate needs to change the way they teach it to address the clearly visible issues coming from the way they currently teach it, based on the comments here.
heisenbit 4y ago
The critique by agile experts of SAFe would be more convincing if they had shown earlier how to scale up agile. While not a fan of SAFe or any agile cargo cult implementation there were a few things I liked about SAFe: Some acknowledgement of the role of planning which imho. is needed at that scale and some framework to handle architectural concerns.
- kitsune_ 4y ago
  Self-organization at scale: Teal / Holacracy / Sociocracy. In the case of holacracy: Imagine a world where your company, its rules and all its employees including the bosses are bound by a constitution [0]. Or have a look at Coplien's Scrum patterns [1] patterns that do involve "planning", and that are also supplemented by his decade old organizational pattern work outside of just Scrum. [0] https://www.holacracy.org/constitution/5 https://www.holacracy.org/constitution/5 [1] http://scrumbook.org/ http://scrumbook.org/ and https://sites.google.com/a/scrumplop.org/published-patterns/home https://sites.google.com/a/scrumplop.org/published-patterns/...
- kevinmchugh 4y ago
  The idea that you can scale agile is false. It's fake. Agile experts didn't say how to do it because it can't be done. They put everything they knew, as clearly as they could, in the manifesto. And then they described themselves. And almost all of them were consultants. They found that delivering software frequently to their customers worked better than any alternative. If you can do that, you can do agile. It doesn't matter if your customers are internal or external - internal might be better, because you can work with them more regularly.
lee 4y ago
I worked for a company that adopted SAFe and sent me to get certified as a SAFe Program Consultant. So I worked to set up "Agile Release Trains" and coached a few teams that had never used any Agile methodology before. I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner. However, It's not entirely terrible as it provides some tools that can be address some organizational problems. I think at best if a large organization is already doing well and is "agile" overall, SAFe won't provide a lot of value and is unlikely worth the investment. If an org is highly siloed, dysfunctional, and lacking inter-department coordination then SAFe it at least offers some tools to address those issues.
- tonyarkles 4y ago
  I have never worked in a SAFe environment, but have worked with multiple teams that have followed various Agile methodologies over the years, with varying degrees of "compliance to the process". > I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner This is the wrinkle, and in my experience the #1 factor for whether or not any particular methodology is going to work within an organization: top-level buy-in. Before I got too jaded, I worked with and helped some teams that wanted to try bottom-up agile, and it would help the team get better, but if a layer or two up in the management chain still wants e.g. fixed timeline, fixed budget, fixed scope projects, you're going to run into impedance mismatches all over the place and lose most of the benefits in the medium term. This can also happen in the other direction. An organization I worked with adopted EOS on the business side of the company but didn't really roll it out on the engineering side, except for expecting everyone organization-wide to specify their quarterly goals. After setting those quarterly goals, the engineering teams would still get yanked around in multiple directions, being asked semi-randomly to work on things that had nothing to do with their quarterly goals and then at the end of each quarter everyone just scratched their heads and went "why didn't we accomplish what we wanted to accomplish?" Maybe I'm jaded, but I've gotten to the point where I don't really care which methodology is used, but rather that everyone top-to-bottom is on-board with it and actually following it. If it's Scrum, management needs to 100% buy in to the idea that they're going to get releases at a constant cadence and that those releases will contain whatever was prioritized as the highest value, with lower value features potentially missing. If it's something more conventional/waterfall-esque, management needs to be on-board with the fact that there's going to be some very costly analysis up front (that must include engineering) and that changes to that plan are expensive and will cause the schedule to slip; engineering needs to be on-board with the fact that they will be expected to deliver everything according to the schedule they built. It doesn't matter nearly as much which approach everyone wants to take, just that everyone understands the tradeoffs with that approach and that everyone's going to follow it.
charbull 4y ago
I had a very good experience using safe 4.x The whole department participated. Edge Software Cloud platform Application team It allowed the 3 teams to have better communication, things were written, we knew what we are building and how/who is using it. Met with stakeholders regularly for feedback and better understanding of the business in general, the strategy and why we need to land this feature either to differentiate or because it is priority 0 asked by many customers. As a team member safe allowed me to understand why what I am working on is important for the business and how it brings value. I wonder if it is a people problem that we are blaming safe for or an actual process problem?
- lostdog 4y ago
  Describe how it works in 1 paragraph or less.
- tbalsam 4y ago
  Some problem might be it's both a people and a process problem. There may be little to nothing about it that is objectively, technically "wrong". But maybe it doesn't work for 90-95% of people. It sounds like most of what you listed is something that could be accomplished with a good scrum team that has a well-defined, prioritized, and pruned backlog (as necessary.... :))
- derekbaker783 4y ago
  None of that requires SAFe, and would be probably be less costly to achieve without SAFe.
oneplane 4y ago
Seems to me that SAFe like so many business ideas only exists because companies that work well without it may still work well despite having to use SAFe. Companies that don't function well are not magically turn into well-functioning companies because someone threw a book at it. When you can restructure a company from not-working to working order, it's not SAFe that did it, but someone with enough time and energy. At that point it doesn't matter if SAFe was involved or not, because that's just an idle wheel coming along for the ride.
bitwize 4y ago
SAFe is basically Rational Unified Process (cross-team waterfall) with a coat of Agile paint. No one in a SAFe organization thinks it's particularly agile, but it meets certain business needs (total visibility and the appearance of control by upper management). SAFe is a key component of an "agile transformation" which is a bit like the "peace process" between Israel and Palestine: the participants who implement the process are best served if no progress is made while they project the illusion that progress is being made.
cpeterso 4y ago
Here's a 2019 presentation from Lockheed Martin about how they are implementing SAFe for their F-16 software development. They went from throwing a whole new program over the wall to flight test in 3-4 years to delivering an testable increment (of the new program) in 9 months. Their total program delivery is no shorter, but they now get test feedback on increments years sooner. https://www.youtube.com/watch?v=nvfYLZ52zX0 https://www.youtube.com/watch?v=nvfYLZ52zX0
rootusrootus 4y ago
It's difficult to really articulate just how much damage SAFe safe has done to our organization. But senior management loves the waterfall planning and the finance guys love the level of detail they can stuff into their spreadsheets somewhere. That it cuts our actual development output by half or more is not relevant. As long as we can churn out meaningless Jira tickets to describe all that we aren't really doing, management is happy. The important work still gets done, but it's off the books. It would never survive PI planning.
danabrams 4y ago
The SAFe promise is that you can make your enterprise agile without any of the difficult changes that senior and middle management have to make to truly make agile. Just pay scaled agile lots of money for your project managers to become certified. It’s like a diet that promises you can eat as much of whatever you want, as long as you pay.
pjbeam 4y ago
SAFe was implemented top down at CVS Health when I was there. Main benefit I got from it was the parties in the evenings after PI Planning days were excellent. Otherwise I don't miss anything about it.
chris_nielsen 4y ago
When I read it, I see a devastating critique of SAFe from every big name I trust in the Agile space. I would never recommend SAFe. But no-one is asking me… How would a potential customer of SAFe see it? Right now somewhere in the world there is probably a C level exec of a large org reading a powerpoint about how transformative and agile SAFe is. They’re probably in their mid fifties and have never worked in tech before. They know agile is good, but any large IT project is risky. What would they see if they read this? Would it mean anything to them? Or would they see a bunch names they don’t recognise, and a list of failed IT projects blaming SAFe.
travisgriggs 4y ago
SAFe is to early agile what modern Christianity is to early Christendom. (I am a frustrated Christian)
- deleted 4y ago
  [deleted]
oaiey 4y ago
SAFe is agile process for the R&D management level and not on team level (where it is effectively a 3 months waterfall). This analogy never fails me. SAFe brings tools and benefits on that level. For everyone below, it is waterfall pain.
anyonecancode 4y ago
I worked for several years at a company that was known for its use of agile. I had my critiques, but overall was a fan. Then I moved on to a much larger company and heard of SAFE, and my initial reaction was "isn't SAFE axiomatically an oxymoron?". Subsequent experience at that large company reinforced that initial impression.
jxf 4y ago
As a former Thoughtworks leader who is mentioned by proxy on this website, it's pretty lightweight in how it describes the attitude towards SAFe. It was almost universally a failure in any company that adopted it. Frequently I landed business merely because a company was trying to unwind SAFe.
rqtwteye 4y ago
Anybody who looks at the SAFe diagram and doesn’t think it’s sheer lunacy has never done any real project work. And calling this “agile” is an insult.
muaytimbo 4y ago
I worked at a company where the new CTO instituted SAFe (which he used at a previously failing company). It was an unmitigated disaster, everyone was miserable. Developers were leaving so quickly consultants were brought in to stem the bleed. When I left the CTO was trying to retain the little talent there was left by holding monthly Q&A sessions. The final question I heard before I left was something like, “why are the consultants treated better than the employees? They don’t have to do SAFe.”
deleted 4y ago
[deleted]
T3RMINATED 4y ago

304 points by clockworksoul 4y ago

I like this take on SAFe. Steve Denning has great talks about what agile is, and what it is not. https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/ https://www.forbes.com/sites/stevedenning/2019/05/23/underst... The SAFe training is predominantly a bunch of pointless games, marketing, and baseless claims. Leaving all that aside, it's just fake agile.

synu 4y ago
It’s agile for companies that absolutely do not want to adopt agile but want to be able to tell their (prospective) employees that they have.
- 29athrowaway 4y ago
  That is a nice way to describe it. SAFe puts a bunch of layers between you and the customer. Agile is about removing layers between you and the customer.
- ResearchCode 4y ago
  Are employees looking for "agile" companies? Seems more like a red flag for micromanagement nowadays.
  - synu 4y ago
    My personal experience is that, while you’re absolutely right for startups, large multinationals and companies that don’t see themselves as necessarily tech-first still use it as a selling point. I don’t know if it is effective to do so or not, but I do see it highlighted on job ads/recruiting landing pages.
  - 29athrowaway 4y ago
    Better to be micromanaged by 1 person than 10.

yborg 4y ago

I was originally trained as a lad in classic waterfall and was a CMM auditor at one point - I got SAFe certification a few years ago and my overwhelming impression was that they had replicated all of the flaws of these methodologies, just with the word "agile" inserted wherever possible. I suppose that it is the final representation of the principle that any revolution becomes the new orthodoxy in a generation and ends up as ritualized as what preceded it.

onli 4y ago
I thought Scrum would be more a candidate for that, when the rituals from there become useless orthodoxy. If (since) SAFe implementations are just waterfall with all its flaws rebranded, it's more the counter-revolution disguising itself.
- roguecoder 4y ago
  As soon as people forgot that Agile was about organizing workers & having management trade its power for more-valuable software, it was basically doomed. Executives would rather give money to the people who promised that they could get the more-valuable software without giving up any of their power and control.

rileyphone 4y ago

I strongly agree with this, but you need some more editing, especially to convince the leadership types that keep making this mistake.

nvr219 4y ago
Agreed. The decision makers at my company would not read this.
cpeterso 4y ago
And if you’re going to say “Don’tdo SAFe, you sure suggest some alternatives.

brightball 4y ago

I'm a SAFe certified SPC and RTE. Also a programmer with 20+ years of experience. IMO the only real issue with SAFe is that the quality of trainers have probably become diluted. If you have a SAFe instructor without a programming background to go along with it who can understand how all of the pieces involved will affect the people and the process, you're going to end up with pure by-the-book rigid implementer...because they probably don't know any better. I was drawn to SAFe after posting a lot of venting thoughts on my blog, that got picked up here and somebody on this forum recommended a fantastic book to me. The Principles of Product Development Flow: 2nd Generation Lean Product Development by Donald Reinertsen. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 This book is not rigid, nor are the principles within it. I used those principles to very successfully run a development group, but I was failing at consistently involving the business side of the house effectively. I looked around for something more formal that was based on his work and I found SAFe. Going through the training, it's about 80% based on that book. You'll recognize all of the underlying principles. But I took so many classes on it because I wanted to make sure I understood SAFe well enough to know the goals of it's structures so that I knew how to adapt effectively. I don't think a lot of SAFe instructors do that. So here's what you need to know about SAFe. They flat out tell you, you are NOT trying to fit the organization into this structure. You're trying to see how the principles of this structure can benefit your organization. If you want an effectively summed up list of the keys of SAFe from everything I've learned it's this: 1. Continuous Delivery & Deployment are the primary goals of this structure. There is a huge focus on development pipeline automation and all of the efficiencies that come from it. I have no idea why anyone would think otherwise based on comments in that link, because it's absolutely core to the entire process. 2. Prioritization without emotion. SAFe prescribes a formula based approach to prioritization that is essentially a dressed up Return on Investment formula called Weighted Shorted Job First. It recommends structures to get a lot of representatives from the business side of the house to go through and apply relative weights to 3 different factors to establish a Value metric called Cost of Delay and then counts on the technical side of the house to estimate the workload. This helps you prioritize in a way that factors in Opportunity Cost. You have X amount of developer time, if you spend it on this you can't spend it on that. This process is FANTASTIC for everyone involved except the person at the company who is used to getting things prioritized by yelling the loudest. On the business side, everybody has a clear place to have a voice in the company priorities. On the dev side, you never get the "everything is top priority" answer that is so common. 3. Feature Flags. This is one of the absolute keys from a best practices perspective and it also critical for a continuous delivery environment. It allows dev to deploy to production behind a flag rather than hold stale branches while waiting for marketing, product, etc to give feedback, documentation etc. Product gets the benefit of being able to show features to specific clients, gather feedback, etc in a production environment while everyone else can prepare to release when they are ready...without having to bog down development with that entire process. The idea of separating Deployment from Release is hard for a lot of people to wrap their heads around. The biggest complaints that I see around SAFe are that it's too rigid and/or that it's waterfall. It's neither of these things. It's made to be adapted to your company and all it involves is a collection of best practices that work really effectively together. They adopted a lot of current practices, like Scrum, into Reinertsen's work because it's easier for an organization to adopt it if they think they're already doing a lot of it. Each team within a SAFe environment can use Lean, Scrum, Kanban, etc. It's up to the TEAM entirely. Scrum structures are just there because a lot of people are already using them. As for the waterfall bit, I reject this entirely. There's a large group of people out there that seem to think even acknowledging a dependency means you have a waterfall process and I bristle every time I hear it. The PI Planning structure allows you to coordinate team planning over 8-12 weeks. Have you ever been in a scrum environment where the teams didn't have a clear path to coordinating? It's awful. Moreover, the structure allows (and insists) that your developers actually provide the plan. This means nobody else has handed you a deadline and your entire team gets to have a dialog about what can be done in what amount of time. You discuss tradeoffs with management if they ask for the world and they only really need a piece and then discuss how to get that piece. How many environments leave developers out of this process entirely? Just handing you tasks? I'm a huge fan of SAFe because it's goal is to provide an environment where developers can thrive. Every time I see comments about SAFe and ask questions about it, I get responses like "they didn't do that in our SAFe implementation." That's because your upper management nixed it. It's not because it wasn't supposed to be there. Personally, I'm a huge SAFe with Kanban advocate. If you have questions about SAFe at your company or you simply want a second opinion on what you're being told, feel free to hit me up. I'll be happy to answer any questions that I can.

orzig 4y ago

I read as much of the site as I could, but could somebody explain: how is SAFe different than the original agile manifesto?

fidrelity 4y ago
The agile manifesto does not dictate any team or organisational structure. SAFe prescribes a bunch of structures, councils and processes. It is by design anti agile. Edit: this image highlights the paradox: https://www.agilest.org/wp-content/uploads/2018/03/scaled-agile-framework-4-5-big-picture.png https://www.agilest.org/wp-content/uploads/2018/03/scaled-ag... Just try to count all the roles and processes prescribed.
- gherkinnn 4y ago
  Very lean indeed.
- isoprophlex 4y ago
  If anyone comes and tries to sell you stuff using a chart that looks like that, better show them the door immediately. That thing seems optimized to cause upper management hypnosis by its expertly designed cavalcade of hollow bullshit terminology.
  - FridgeSeal 4y ago
    I've never seen this chart before, but I've worked with people previously that I know would get instantly giddy with excitement looking at this. The meaningless terms, the disconnected-flow-chart-but-not-a-flow-chart, the deluge of acronyms, the weird visuals and the inscrutable words and relationships, it's all there. It's a document I'd attempt to create if I was trying to parody consultants and business shenanigans, but it's real.
- db48x 4y ago
  I’m having an allergic reaction after looking at that chart. Where did I put that epipen?
- 4y ago

flerchin 4y ago

The thoughtworks case study is repeated. Otherwise wholeheartedly agree. I have delivered plenty of software during 10 PIs, but that was in-spite of SAFe, and the whole thing was harder and slower because of it. Since then, I reorganized a team of ninjas away from the trains and have delivered at 3x the velocity using kanban methodology.

swagtricker 4y ago

Don't forget the classic parody of SAFe which shows it as the overblown "waterfall in agile clothing" that it is: LAFABLE. https://www.lafable.com/ https://www.lafable.com/

mindwok 4y ago

I view the implementation of SAfe anywhere as a huge red flag. To me it suggests that the decision makers read about Agile and what it proposes and decided that for whatever reason they don’t want it, in its unfettered form it scares them, or they don’t understand how to adopt it. As someone who prefers working in Agile workplaces, that tells me all I need to know.

JamesSwift 4y ago
My experience in an org that introduced SAFe during my time there, was that it was actually a misguided bottom-up introduction. A couple teams went agile and found it really effective then thought "if it was this effective for 1 team just imagine if we scaled it up to everyone!". Spoiler: I will likely never work for another SAFe org again.

electrondood 4y ago

At my last company we used SAFe and I was blown away at how effective it was. Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, with dependencies between teams, with wiggle room/flexibility, by the end of the event. I understand this can depend on how well it's implemented, but in my experience I've never seen anything like it before or since.

bl4ckm0r3 4y ago
How big was the team and what type of project? And what amount of level of detail did you put in the planning/roadmap? Did you also had experiments and investigations taken into account?
kqr 4y ago
> Once a quarter, we had a 3-day event in which the entire next 3 months were planned out, This is the part I don't understand. What sort of business are you in where you can actually meaningfully predict which will be the most valuable opportunities and ideas that will come your way in the next three months?
- ThalesX 4y ago
  Three months!? Is this the stability we expect from companies in our day and age? I would think it's a lost company, one that couldn't somewhat predict what the next three months are going to look like.
  - pflenker 4y ago
    Just look back 3 month and assess how many of the things that happened were predictable (keeping in mind the fact that hindsight is 20/20). I wager every company in the world was affected by the world wide changes right now. Those who cling to plans are at disadvantage against those who have the ability to quickly adapt to the change.
    - ethbr0 4y ago

63 4y ago

As someone who just finished a week of 8 hour PI planning meetings with another week of the same starting Monday, I wholeheartedly agree. My experience of SAFe has been shorter term waterfall with a couple steps cut out. It's definitely better than waterfall and I'm grateful for that, but I wouldn't call it agile.

roguecoder 4y ago
It follows the outline of taylorism, just one level up from the team: measure, control and manage.
tootie 4y ago
SAFe almost feels like a ploy lead by waterfallistas to sneak their agenda back into the mainstream and call it "agile" to fool everyone. It's a shame because there is room for a toolkit to help scale agile. There aren't great tools for managing dependencies between agile teams.
brightball 4y ago
A week? It’s supposed to 2 days. 2.5 if you are partially time shifted.
- throwaway93494 4y ago
  I mentioned this in another reply, but it bears repeating. Our current PI planning is 2 weeks not counting the half day before in Pre-Planning for PI Planning. I sincerely wish that was a joke. It's a 4 hour team wide meeting to review all work items are ready to be planned during PI planning, as well for us to identify dependencies and schedule meetings with those dependencies. There isn't enough time to to that during the actual planning.

ChuckMcM 4y ago

What SAFe does is provide some sort of visibility and accountability to senior management. (Which waterfall did before it) Until the Agile community can come up with a reliable way of identifying and firing the low performers for senior management, they will keep pushing down requirements like SAFe on the organization. Fortunately, the level of opacity between budget managers (P/L) vs execution managers usually doesn't get this bad until you've got 10 - 20K employees.

ResearchCode 4y ago
How does SAFe reliably identify "low performers"? Top companies tend not to do SAFe, I don't see the issue this solves. But I'd easily see SAFe creating low performers.
- ethbr0 4y ago
  By mandating visibility. And let's be honest, SAFe is not for "I can attract talented people who can self-manage" companies. It's for "75% of my developers are scraping the bottom of the barrel, but I take what I can get because my company isn't sexy."
bitwize 4y ago
> What SAFe does is provide some sort of visibility and accountability to senior management. This is true of all Agile methodologies adopted by corporations. If it weren't true, the methodology would not be adopted.

mrweasel 4y ago

I've never worked in an organisation that used SAFe, but to be honest I've never worked for one that used SCRUM either. The only semi-structured method I've ever been part of has been "SCRUM BUT". What I find weird about both SCRUM and now SAFe is that pretty much every single agile expert I've read articles and blog post from dislikes it. My take away is that the agile purist, if you can call them that, are focus on delivering high quality software and user satisfaction, that's the focus, that's the goal. SCRUM and perhaps now SAFe (presumptuous acronym btw) seem to be focused on managing software deliveries in larger organisations. As some one who studies software engineering and process management 18 years ago, I can't say that time has made me think that things have improved much over time. I am especially skeptical of processes that comes with certifications and titles. The original agile manifesto is beautiful in that it's something we can all do. There's are no training, no certification, no corporate backer. Its principles, and you can either agree or disagree, is something the team can reflect and meditate on how to best incorporate the ideas into their work. Overall, more and more I start to think that PHK was right in his talk "Entirely Predictable Failures" in 2012[1]. It's snake oil, almost all of it. [1] https://www.infoq.com/presentations/Predictable-Failures/ https://www.infoq.com/presentations/Predictable-Failures/ (At around 24:30 and a few minutes from there).

29athrowaway 4y ago
Scrum is not an acronym.

csours 4y ago

SAFe is not about software development or planning. SAFe is about funding software development in a cost center. I haven't seen anyone address how to do the accounting for software development for a large organization, where that software is not being sold for money.

ethbr0 4y ago
Internal billing + discretionary "keep the lights on" budgeting? It has its flaws, but it's not the worst approach.
roguecoder 4y ago
You are absolutely right about the short-sighted problems created by incompetent finance models. I've seen two successful approaches in practice. The first is vertically integrated companies using easily-measured labor-saving techniques like ML to justify the infrastructure costs required to support those innovations. And the second is places where workers have the institutional power to advocate for investment in the tools they have to use. It seems to me that there should be an effective strategy where we treat software as capital spending that gets appropriately depreciated, but mostly what I see is finance departments trying to micro-manage development and in the process costing their company a lot of money.

SSLy 4y ago

SAFe is bad, but is there anything better when you have, say, 1500 devs, and expect two fat releases a year with whatever required bugfixes between?

Smeevy 4y ago
Doesn't that fundamentally undercut the incremental value delivery and CI/CD progression that SAFe promises?
- derekbaker783 4y ago
  Yes
yakshaving_jgt 4y ago
> is there anything better Yes. Not doing SAFe.
29athrowaway 4y ago
The max size of an ART is 125

ButterWashed 4y ago

I'm currently a year into a role as Lead SRE in team working in SAFe. We plan five 2 week sprints for which we immediately write off 50% of our time as "BAU activities" and the rest of our time is spent lurching from one deliverable to another in the hope we actually achieve something before we get "re-prioritised" yet another time. It's not even SRE, it's 2nd line support and platform engineering. I really have no idea how SAFe works or how it's meant to work, but everyone seems happy so long as I complete my JIRA tickets on time because that's what the users want.

ethbr0 4y ago
I worked for a SAFe company like that once. Took a salary cut for another job. Haven't regretted the choice for a second: life's too short to waste one's talent in service to a bad employer.
BizarreByte 4y ago
I don't know if we claim to use SAFe were I work, but this sounds very similar to my experience. It frustrates me to no end, but as a contractor I don't get a say and the full time employees seem to be okay with the status quo. I am constantly amazed that any working software comes out of such a process, but against all odds it does.

retrocryptid 4y ago

This seems a bit of a hit piece, but it seems like a safe target as at least half the people I know seem to hold it (SAFe) in disdain. I've consulted for organizations that started using it and have a mostly negative opinion. Organizations that are in near complete disarray may find it useful; but then again, they might also find a return to old-school waterfall useful. Where I've seen SAFe not work so well is organizations that are doing reasonably well with planning, but have some deficiencies or some corners of the organization that aren't doing too well. Traditional Agile doesn't scale well above the team level (not that it's bad, it's just that benefits from its processes don't seem to be focused on that level of the organization.) Scrum of Scrums is rarely executed well and Lean and XP don't really describe practices for that echelon. (I'll have to re-read my Kanban books and see if it addresses it.) My take on SAFe is that it rigidly adds dependencies between teams, even if such dependencies are counter-productive. But like the manager who uses the daily standup as a status meeting, it seems like it's serving the "bean counters" instead of the people doing the work.

faangiq 4y ago

It’s well known at this point that Agile and any other “methodology” is a scam. The only thing that matters is raw IQ everything else is just kabuki paper shuffling.

i_like_apis 4y ago

bane 4y ago

SAFe seems to be a bit like "internet scale", it's designed for very large organizations building very large single software solutions. Most organizations wildly overestimate their size and the size of their solutions. A Microsoft Office release probably can benefit from SAFe, an update to an auth microservice maintained part/time by a team of .75 FTE doesn't. SAFe seems to sort of be a micro-waterfall approach inspired by Conway's law [1]. It build massive communication and coordination teams so that this gets reflected into short-term development waterfalls that produce software that mirrors the system that managed it. But this team needs to be dwarfed by the development effort they are trying to push forward or they'll end up dominating all of the activities with largely useless communication and coordination activities resulting in very slow forward software movement, confused goals and priorities, and overstaffing of projects. Example: I once ran a team that was developing some internal tools for a large org, but we were outside of the main SAFe effort. At one point we became dependent on some service the SAFe effort was going to produce. It took 60 people 3 years to not produce a correctly working service. Exhausted with this, I finally just had 1 person build the service we needed as a stopgap. She spent 3 months building it with part-time support from one other engineer for a couple weeks. More than 3 years later that is the service that's still running and the SAFe effort never did manage to get a properly working solution out the door. I can think of half a dozen similar examples where the parallel effort by a smaller team with less organizational overhead radically outperformed the giant SAFe team -- and they did it mostly by just ad hoc communication channels between the small teams. 1 - https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law

RajT88 4y ago
I took a SAFe training class once, and they explained that Wal-Mart does this sort of exercise quarterly. Rents out a warehouse, flies in all the dev managers and leads, and does sprint planning using all the boards they have stood up everywhere. I am not commenting on how effective it was for them of course. It seemed to me to be a bit overkill for the size of the company I was in (about 5k people).
- marcosdumay 4y ago
  Getting everybody together once in a long while, and synchronizing a "what are you working on?" is a good exercise. But only if that while is long.

mkw2000 4y ago

I had a recruiter mention to me that the company is all about SAFe and I should express my interest and enthusiasm for it during my interview. I looked it up, saw a diagram describing the process that actually made me burst out laughing and ran far away from said company.

heynowheynow 4y ago

When consultants suggest a "new" fad, they're all about charging money to help businesses adopt that fad to avoid FOMO. Predictably, there will be a new fad next year and the year after that. Waterfall: elevator control systems, agile: expense reports UI, and apply a blend to things in between.

doctor_eval 4y ago
100% agree. I worked at a large telco where this happened. Brand-name consulting company “changed methodology” half way through the project and charged the customer for it. I couldn’t believe it. But then again, we were quite literally the only team that delivered a product, so naturally we were seen as a threat and our contract was cancelled. True story.
- heynowheynow 4y ago
  Those who can't tend to hurl negativity and sabotage at those who do. Or people who are too dumb or lazy to try language X or approach Y (minus fads) tend to reiterate how wonderful their stale way and obsolescence are. There are people at my work (MAANG) who say Rust is too "esoteric" and "impractical" despite the whole company and industry moving that way, but they're comfortable in just now finding Go and being religious about it, maybe 8 years late to the party that's now over because it's "worse is better" shit in the long term. I'm looking around because I think my team is doomed since it lacks coherent leadership (the lead was playing with VR and skipped their own conference), it's full of "senior" people who lack professional career development goals and are uninterested in leveling, they're fine with ignoring software craftsmanship and tech debt, and they don't interact with me with any regularity. I can't get anything done or propose any ideas because the lead looks at me like Tucker Carlson before I can finish a sentence. They don't include me on anything, so I don't know why I'm there.

ineptech 4y ago

I don't really understand SAFe, but from the outside looking in, it seems like the answer to "How close can we get to agile while still employing an army of Project Managers?" Which is to say, not very.

vesinisa 4y ago
SAFe not only keeps middle managers employed and feeling important but also forces lots of unnecessary pencil pusher type work on the engineers and designers. It's a strain on all parts of the organization that are forced to use it. This is why most companies will abandon SAFe after a couple of years, like the case studies show. I have personally left one employer (a bank) because SAFe made the job unbearable. Both this company and their larger competitor abandoned SAFe after a couple of years. I now categorically ignore any gigs and openings at companies using SAFe - it's a glowing red flag to me.
- teeray 4y ago
  I have also left an employer with MBAs that continually tried to find and mandate the One True Way of building software. I noped out when I found myself in multiple status meetings every day repeating myself to different middle managers (and having to update a Slack status channel as well). Spoiler: they adopted SAFe after I left, which told me everything I needed to know about SAFe without having to experience it firsthand.

JulianMorrison 4y ago

In my experience, if what you've got is a months-ahead plan where management sets the deadlines AND controls the scope via pressuring the line manager, and delivery relies on crunch time and panicky de-scoping and working to the letter and not the spirit of the contract, then what you have is waterfall in a fedora and a Groucho Marx novelty disguise.

sas224dbm 4y ago

I have been involved in 2 medium sized-ish (~300) software support projects for western-nation's land forces project that brought in SAFe with a fanfare. Lots of ($$) training, everybody gulping down the coolade etc etc. It started off OK, but as with most of these ideological methodologies, our projects' circumstances started to clash with the SAFe 'way'. Our customer was very fond of his existing rituals (meetings, committees, progress meetings etc), but we also folded in all the SAFe rituals too. It seemed we were in meetings too much of the time, and we did a poor job of convincing the customer to move wholesale to the SAFe way. In addition, the organizational structure and governance models never operated in the SAFe way, with the customer's insistence on being in our shorts on every decision hampered most of the 'delegate decisions as deep as possible' philosophy. At the end of the day, it steel feels like RUP re-invented for 'agile' .. never again.

dunno7456 4y ago

This is a reflection of agile brin dead on the water when it comes to it's promises.

twawaaay 4y ago

I wasn't aware of SAFe until one new manager got our director to loose his head for it and institute it in all teams. It was a total disaster. The idea of Agile is for each team to be responsible to improve their processes. Because improvement loops involving higher management are taking forever to complete and because each team has its own needs. "Agile" (quotes intentional) as practiced today is bad enough -- teams are not really improving their process, only implementing something taken from a book. SAFe is taking it one step further by absolutely obliterating team's ability to influence the process. At least with "standard Agile" it was possible for some teams to do the right thing, as long as they had a manager that understood what Agile really is. With SAFe that was gone. I was told that we can't even modify our t-shirt sizing because "It has to be standardised, otherwise there would be too much chaos. BTW, we are definitely not creating a new request form to change t-shirt sizes in Jira" Forget about changing any other part of the project. We had a bunch of testers and business analysts which did absolutely nothing but had to stay on the team because they were required in the process by higher management. We did not need them. I spent time hiring people who could do the work from discussing requirements with the business people through design, implementation up to deploying it to prod, but that did not matter. Talk about crazy projects...

closeparen 4y ago
The middle manager brain has "consistency" as a terminal value. Being responsible for more activity than they can hope to substantively understand, they "need" systems that make it all look the same so it can be measured, summarized, compared, etc. Otherwise they get the intuitive sense that it's all chaos and mayhem and can't possibly be working well. It's the same sort of thing as an architect being mad that different services have different internal architectures, tech stacks, code styles. It's true that such differences make it unreasonably difficult to understand or manage things at the abstraction level of the middle manager or architect's portfolio. But it misses the question of how and whether things should be managed from that level at all. Often you have someone stepping into a working bottoms-up emergent order (like the internet, or a market economy) hamfistedly trying to implement top-down central planning control. SAFe is a tool of choice for these attempts. The radicalism of "true agile" is not about the duration of the planning cycle, but about the level of autonomy and control vested way down in the leaves of an org chart.

brightball 4y ago

I’m going to summarize my earlier comment with this: SAFe with Scrum teams (how instructors are taught SAFe) merely adds more ceremonial meetings and sucks for everyone. SAFe with Kanban teams trades the scrum ceremony for less frequent SAFe ceremony and is a much better experience for developers. SAFe corporate needs to change the way they teach it to address the clearly visible issues coming from the way they currently teach it, based on the comments here.

heisenbit 4y ago

The critique by agile experts of SAFe would be more convincing if they had shown earlier how to scale up agile. While not a fan of SAFe or any agile cargo cult implementation there were a few things I liked about SAFe: Some acknowledgement of the role of planning which imho. is needed at that scale and some framework to handle architectural concerns.

kitsune_ 4y ago
Self-organization at scale: Teal / Holacracy / Sociocracy. In the case of holacracy: Imagine a world where your company, its rules and all its employees including the bosses are bound by a constitution [0]. Or have a look at Coplien's Scrum patterns [1] patterns that do involve "planning", and that are also supplemented by his decade old organizational pattern work outside of just Scrum. [0] https://www.holacracy.org/constitution/5 https://www.holacracy.org/constitution/5 [1] http://scrumbook.org/ http://scrumbook.org/ and https://sites.google.com/a/scrumplop.org/published-patterns/home https://sites.google.com/a/scrumplop.org/published-patterns/...
kevinmchugh 4y ago
The idea that you can scale agile is false. It's fake. Agile experts didn't say how to do it because it can't be done. They put everything they knew, as clearly as they could, in the manifesto. And then they described themselves. And almost all of them were consultants. They found that delivering software frequently to their customers worked better than any alternative. If you can do that, you can do agile. It doesn't matter if your customers are internal or external - internal might be better, because you can work with them more regularly.

lee 4y ago

I worked for a company that adopted SAFe and sent me to get certified as a SAFe Program Consultant. So I worked to set up "Agile Release Trains" and coached a few teams that had never used any Agile methodology before. I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner. However, It's not entirely terrible as it provides some tools that can be address some organizational problems. I think at best if a large organization is already doing well and is "agile" overall, SAFe won't provide a lot of value and is unlikely worth the investment. If an org is highly siloed, dysfunctional, and lacking inter-department coordination then SAFe it at least offers some tools to address those issues.

tonyarkles 4y ago
I have never worked in a SAFe environment, but have worked with multiple teams that have followed various Agile methodologies over the years, with varying degrees of "compliance to the process". > I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner This is the wrinkle, and in my experience the #1 factor for whether or not any particular methodology is going to work within an organization: top-level buy-in. Before I got too jaded, I worked with and helped some teams that wanted to try bottom-up agile, and it would help the team get better, but if a layer or two up in the management chain still wants e.g. fixed timeline, fixed budget, fixed scope projects, you're going to run into impedance mismatches all over the place and lose most of the benefits in the medium term. This can also happen in the other direction. An organization I worked with adopted EOS on the business side of the company but didn't really roll it out on the engineering side, except for expecting everyone organization-wide to specify their quarterly goals. After setting those quarterly goals, the engineering teams would still get yanked around in multiple directions, being asked semi-randomly to work on things that had nothing to do with their quarterly goals and then at the end of each quarter everyone just scratched their heads and went "why didn't we accomplish what we wanted to accomplish?" Maybe I'm jaded, but I've gotten to the point where I don't really care which methodology is used, but rather that everyone top-to-bottom is on-board with it and actually following it. If it's Scrum, management needs to 100% buy in to the idea that they're going to get releases at a constant cadence and that those releases will contain whatever was prioritized as the highest value, with lower value features potentially missing. If it's something more conventional/waterfall-esque, management needs to be on-board with the fact that there's going to be some very costly analysis up front (that must include engineering) and that changes to that plan are expensive and will cause the schedule to slip; engineering needs to be on-board with the fact that they will be expected to deliver everything according to the schedule they built. It doesn't matter nearly as much which approach everyone wants to take, just that everyone understands the tradeoffs with that approach and that everyone's going to follow it.

charbull 4y ago

I had a very good experience using safe 4.x The whole department participated. Edge Software Cloud platform Application team It allowed the 3 teams to have better communication, things were written, we knew what we are building and how/who is using it. Met with stakeholders regularly for feedback and better understanding of the business in general, the strategy and why we need to land this feature either to differentiate or because it is priority 0 asked by many customers. As a team member safe allowed me to understand why what I am working on is important for the business and how it brings value. I wonder if it is a people problem that we are blaming safe for or an actual process problem?

lostdog 4y ago
Describe how it works in 1 paragraph or less.
tbalsam 4y ago
Some problem might be it's both a people and a process problem. There may be little to nothing about it that is objectively, technically "wrong". But maybe it doesn't work for 90-95% of people. It sounds like most of what you listed is something that could be accomplished with a good scrum team that has a well-defined, prioritized, and pruned backlog (as necessary.... :))
derekbaker783 4y ago
None of that requires SAFe, and would be probably be less costly to achieve without SAFe.

oneplane 4y ago

Seems to me that SAFe like so many business ideas only exists because companies that work well without it may still work well despite having to use SAFe. Companies that don't function well are not magically turn into well-functioning companies because someone threw a book at it. When you can restructure a company from not-working to working order, it's not SAFe that did it, but someone with enough time and energy. At that point it doesn't matter if SAFe was involved or not, because that's just an idle wheel coming along for the ride.

bitwize 4y ago

SAFe is basically Rational Unified Process (cross-team waterfall) with a coat of Agile paint. No one in a SAFe organization thinks it's particularly agile, but it meets certain business needs (total visibility and the appearance of control by upper management). SAFe is a key component of an "agile transformation" which is a bit like the "peace process" between Israel and Palestine: the participants who implement the process are best served if no progress is made while they project the illusion that progress is being made.

cpeterso 4y ago

Here's a 2019 presentation from Lockheed Martin about how they are implementing SAFe for their F-16 software development. They went from throwing a whole new program over the wall to flight test in 3-4 years to delivering an testable increment (of the new program) in 9 months. Their total program delivery is no shorter, but they now get test feedback on increments years sooner. https://www.youtube.com/watch?v=nvfYLZ52zX0 https://www.youtube.com/watch?v=nvfYLZ52zX0

rootusrootus 4y ago

It's difficult to really articulate just how much damage SAFe safe has done to our organization. But senior management loves the waterfall planning and the finance guys love the level of detail they can stuff into their spreadsheets somewhere. That it cuts our actual development output by half or more is not relevant. As long as we can churn out meaningless Jira tickets to describe all that we aren't really doing, management is happy. The important work still gets done, but it's off the books. It would never survive PI planning.

danabrams 4y ago

The SAFe promise is that you can make your enterprise agile without any of the difficult changes that senior and middle management have to make to truly make agile. Just pay scaled agile lots of money for your project managers to become certified. It’s like a diet that promises you can eat as much of whatever you want, as long as you pay.

pjbeam 4y ago

SAFe was implemented top down at CVS Health when I was there. Main benefit I got from it was the parties in the evenings after PI Planning days were excellent. Otherwise I don't miss anything about it.

chris_nielsen 4y ago

When I read it, I see a devastating critique of SAFe from every big name I trust in the Agile space. I would never recommend SAFe. But no-one is asking me… How would a potential customer of SAFe see it? Right now somewhere in the world there is probably a C level exec of a large org reading a powerpoint about how transformative and agile SAFe is. They’re probably in their mid fifties and have never worked in tech before. They know agile is good, but any large IT project is risky. What would they see if they read this? Would it mean anything to them? Or would they see a bunch names they don’t recognise, and a list of failed IT projects blaming SAFe.

travisgriggs 4y ago

SAFe is to early agile what modern Christianity is to early Christendom. (I am a frustrated Christian)

deleted 4y ago
[deleted]

oaiey 4y ago

SAFe is agile process for the R&D management level and not on team level (where it is effectively a 3 months waterfall). This analogy never fails me. SAFe brings tools and benefits on that level. For everyone below, it is waterfall pain.

anyonecancode 4y ago

I worked for several years at a company that was known for its use of agile. I had my critiques, but overall was a fan. Then I moved on to a much larger company and heard of SAFE, and my initial reaction was "isn't SAFE axiomatically an oxymoron?". Subsequent experience at that large company reinforced that initial impression.

jxf 4y ago

As a former Thoughtworks leader who is mentioned by proxy on this website, it's pretty lightweight in how it describes the attitude towards SAFe. It was almost universally a failure in any company that adopted it. Frequently I landed business merely because a company was trying to unwind SAFe.

rqtwteye 4y ago

Anybody who looks at the SAFe diagram and doesn’t think it’s sheer lunacy has never done any real project work. And calling this “agile” is an insult.

muaytimbo 4y ago

I worked at a company where the new CTO instituted SAFe (which he used at a previously failing company). It was an unmitigated disaster, everyone was miserable. Developers were leaving so quickly consultants were brought in to stem the bleed. When I left the CTO was trying to retain the little talent there was left by holding monthly Q&A sessions. The final question I heard before I left was something like, “why are the consultants treated better than the employees? They don’t have to do SAFe.”

deleted 4y ago

[deleted]

T3RMINATED 4y ago