7 ms·
Agile development is fading in popularity at large enterprises
- count 3y agoSAFe is an atrocity. I bet most of these 'large enterprises' are doing something similar. Plan your sprints a full 2 years in advance! No changes, gotta stick to the plan, because it's in the sprint! But we do standups! (I know, I know, no true scotsman, but also, come on....)
- leansensei 3y agoSAFe won't go away soon... https://overbring.com/blog/2023-04-27-safe-agile-souffle/ https://overbring.com/blog/2023-04-27-safe-agile-souffle/
- whoswho 3y ago[flagged]
- count 3y agoAgile, as practiced in many large organizations with whom it is fading in popularity is practiced in the form of 'Scaled Agile Framework' - https://scaledagile.com/what-is-safe/ https://scaledagile.com/what-is-safe/ It takes all of the flexibility and tenants of agile development, and destroys them to make things 'ok' for people used to traditional waterfall planning methods, but keeps some of the 'ceremony' around agile so people feel like they're 'doing the thing'.
- Andaith 3y agoWe call it waterfall with all the agile buzzwords - Waterfall because thats what mgmt understands and wants, and all the agile buzzwords so we can hire developers...
- datavirtue 3y agoI think the problem is the same given "waterfall" or "agile." Waterfall, if you step back and think about it rationally is a perfectly valid approach. In fact, I see only slight differences between them...mostly cosmetic.
- willsmith72 3y agoNo it's not, that's the whole point of agile. If you only see slight differences between them, you haven't seen agile.
- count 3y agoCosmetic in what sense? Planning everything in advance, vs iterative, incremental delivery are pretty different ways to do things.
- datavirtue 3y agoThe vision has to be planned either way. Neither way requires you to plan all the infrastructure and write UML. Development is always iterative, in any mythological system or supposed anti-system.
- datavirtue 3y agoScaled agility. Such a sultry phrase for the target audience.
- jiveturkey 3y agotenets. sorry that one is just a peeve of mine.
- tharkun__ 3y agoSAFe is exactly what the name sounds like. "Agile" in a form that large corporations feel that it's safe to adopt "Agile" in. About 15 to 20 years late at that. It's really just the old big Corp consulting gigs but for Agile. Don't get me wrong, SAFe does have agile concepts in it that make sense overall. But the whole "let's do a strict process and let's do it wrong and let's enforce it rigorously without thinking" is just corporate BS all over but this time with "Agile" written at the top instead of "Rational Unified Process" or whatever else your corporation might have paid consultants for before.
- willsmith72 3y ago> SAFe does have agile concepts in it that make sense overall Like what exactly?
- tharkun__ 3y agoPrefix: SAFe in general is an accumulation of buzzwords. Especially geared towards larger organizations. As such I dislike it to on principle. I will assume that you do accept that Agile overall has sensible elements. Here are some of those that do appear in SAFe. The way SAFe goes about packaging and advertising them: questionable to say the least. As would be customary when we're trying to appeal to a large corporation that wants to feel safe and minimize divergence from processes that can be applied by exchangeable cogs in the machine. A release train Continuously releasing functionality in small increments makes a lot of sense to me and is part of certain Agile principles. Kanban and WIP limits Believe it or not, they mention this. Of course they do, they want to appeal to ops teams. Kanban makes a lot of sense to me. Personally I use it on my teams whenever I'm allowed/able to where we do away with Story Points and just size things about the same into vertical slices. Of course I'm in a constant fight w/ "corporate" about hard deadlines and the "need to estimate" and they don't understand lead and cycle time and how you can estimate using those w/ same-sized tasks sigh Refactoring Yes, they include refactoring as a topic of note. Isn't that awesome? :P It's amazing how much text (and training you can sell I'm sure!) you can write on the simple fact that refactoring may be necessary at some point. XP refactoring mercilessly anyone?
- nradov 3y agoThat's not really a fair criticism. SAFe is very complex and overkill for small organizations. But if you're managing a huge product portfolio with multiple teams spread across the world and need to deal with external priorities then SAFe is kind of the least bad way to keep everything somewhat sane. Sprints are never planned more than 3 months in advance, and often less. SAFe has provisions for some teams to run continuous flow (Kanban) with minimal advance planning. https://scaledagileframework.com/safe-team-kanban/ https://scaledagileframework.com/safe-team-kanban/
- Shadowmist 3y agono
- pvdoom 3y agono
- count 3y agoShow me an ostensibly high performing software organization that uses SAFe? Any FANGs? I only ever see it in pathologic orgs. And 3 months, lol. Let me introduce you to the federal govt!
- nradov 3y agoI have seen high performing software organizations that use SAFe, although I am not at liberty to name names. The keys are to have senior leaders that are really committed to it (not just lip service) and ignore the parts that aren't helpful for your particular circumstances. Pretty much everything in SAFe is optional so you can pick and choose the parts that you want (although if you decide to ignore or customize some parts then you should at least have a clear reason for doing so beyond a belief that your organization is somehow "special"). FAANGs operate at mega scale and have the luxury of enough time and resources to create customized methodologies which ideally suit their unique circumstances. But most software organizations can't afford to hire experts to build up custom methodologies (or they wouldn't know whom to hire even if they could afford it). The benefit of something like SAFe is that it's "good enough" for less sophisticated organizations to adopt off the shelf and move forward. And if you look inside the FAANGs you'll see that they essentially do follow many parts of SAFe although they tend to call things by different names and hide some of the gory details from lower-level ICs. I haven't done any federal government work but I've seen large government contractors successfully apply SAFe. They aren't making sprint plans more than 3 months in the future. Again, SAFe isn't anything particularly wonderful. It's just a reasonable starting point that represents accumulated industry best practices for large enterprises with a lot of complex moving parts. Much of the criticism is simply uninformed. Anyone who wants to criticize it should at least cite the relevant section (everything is publicly documented) and explain why that part is unnecessary or suboptimal from an overall business perspective.
- pvdoom 3y agoHell, most enterprises don't even follow SAFe, but usually an even worse abomination wearing the skin of SAFe. And that is not defending it in any way it's cursed.
- ho4 3y agoAgile scales as poorly as does general efficiency of the development team within the same project
- datavirtue 3y agoTurn one dev loose, no distractions, and you can get amazing results. Add another dev, and if they are aligned, they can knock it out of the park. Add another dev? Better have a damn good reason. I forgot how productive a single person can be until I joined my recent company. I'm the only dev working on a sizeable application. I have all the resources I need and zero distractions. I can't believe how smooth progress is and I whince at what would happen if we added other team members without having a clear role for each person and a pressing need for them. Stand-ups are devastating to productivity. I just left a number of huge enterprises. I could barely get anything done at any of them. Sizeable teams that could barely push out a web app. Its no wonder they have to acquire companies that were built by three devs to innovate.
- lulznews 3y agoMultiple devs are fine. Its the “management” that kills things.
- gmfawcett 3y agoSorry, but this is a lazy take. Sure: horrible managers can kill anything. Horrible team members can do it as well. So can horrible company cultures, horrible tool choices, etc. There are horrors for every occasion in the software industry.
- datavirtue 3y agoPrevious to this job I chanced into another opportunity where myself and two other devs were tasked with building a whole new company/product. The third dev completely ruined it. He was a complete asshole and couldn't help but rake our other colleague over the coals on a daily basis. Life is too short to deal with Adderall burn outs.
- willsmith72 3y agoUnless your company cares at all about bus factor
- 3y ago
- skypanther 3y agoMost of my career has been at startups, but I'm at a fairly large enterprise now. Agile is very different here. It's much more rigid. Every team has an agile coach, there are rules that must be followed, there are limits on who can make decisions about certain things, we do every sprint ceremony ever conceived every sprint, all pods must follow the exact same process. There's no flexibility and little acknowledgment of the original Manifesto principles (e.g. people over process). With an implementation like this, I can see why enterprises can fail to gain as much benefit from agile as promised.
- operatingthetan 3y agoIn my experience agile at a large org is waterfall with a new name.
- kermatt 3y agoAgilefall