SAFe 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....)
Agile, 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/
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'.
We 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...
I 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.
The 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.
"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.
Prefix: 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?
That'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.
Show 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!
I 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.
Part of the problem here is that methodologies are like religions where a lot of people say they follow the same thing but if you check their day to day activities you’ll find substantial differences. There aren’t many examples of high-functioning teams using SAFe and that’s at least in part because the kind of places which it appeals to aren’t set up to support that, and any other methodology will struggle in the same environment.
Hell, 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.
Turn 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.
Sorry, 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.
Previous 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.
> Turn one dev loose, no distractions, and you can get amazing results.
Yes... or, horrifying results. Or something in between.
Your model is overfitted to your personal experience. Your take is going to resonate with devs who have had bad agile-ish experiences, and for sure there are plenty of those. But the lone-developer mythos also resonates with devs who've been burned on stupid teams. You're mixing those two things together here, but agile and lone-coder are not opposites.
If you're sincerely wincing about adding more team members without clear roles, then I hope that someday you experience the joy of working on a high-performing, self-directed development team. They exist; many of them even follow agile processes. Some of them work in enterprise settings.
Sometimes you just have bad managers, or bad team members, and no buzzword methodology is going to dig you out of that hole.
> Sometimes you just have bad managers, or bad team members, and no buzzword methodology is going to dig you out of that hole.
Very true, but the common theme among bad managers at shit companies is that they always try and fix that problem by buying a new methodology with a buzzword attached to it, reward themselves for having done so, and never reflect on whether anyone's done anything effectively by the time they get a new one.
The lone-developer and the self-directed team mythos' share the common element that they've figured out how to tangle with any real logistical problems they actually have by analyzing them, reflecting on how to do better, and using communication, rather than imagining what problems they have, externalizing the solution with an off-the-shelf template, and identifying how much praise they'll get from anyone but those doing the work regardless of whether the non-plan works.
> I'm the only dev working on a sizeable application. I have all the resources I need and zero distractions.
This would be a dream come true for me. Any advice on how to find such a job? Did you purposely look for it or did the stars just align and you dropped into an awesome situation?
My manager and my bikeshedding coworkers are driving me insane.
Similar experience here and worked on large enterprise company.
I produced my best work when working with my Lead Architect and no Project Management Oversight. Did a complex POC and completed it ahead of expected timeliness and was working alone for most parts.
That POC was approved for incorporating in production and has to be done in agile manner with daily status meetings and biweekly sprint, demos , reviews and whatnot.
Killed my enthusiasm and let another developer take the lead while I moved away from the project
Most 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.
37 comments
[ 4.4 ms ] story [ 84.6 ms ] threadIt 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'.
If you only see slight differences between them, you haven't seen agile.
"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.
Like what exactly?
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.
Continuously releasing functionality in small increments makes a lot of sense to me and is part of certain Agile principles. 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 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?https://scaledagileframework.com/safe-team-kanban/
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.
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.
Yes... or, horrifying results. Or something in between.
Your model is overfitted to your personal experience. Your take is going to resonate with devs who have had bad agile-ish experiences, and for sure there are plenty of those. But the lone-developer mythos also resonates with devs who've been burned on stupid teams. You're mixing those two things together here, but agile and lone-coder are not opposites.
If you're sincerely wincing about adding more team members without clear roles, then I hope that someday you experience the joy of working on a high-performing, self-directed development team. They exist; many of them even follow agile processes. Some of them work in enterprise settings.
Sometimes you just have bad managers, or bad team members, and no buzzword methodology is going to dig you out of that hole.
Very true, but the common theme among bad managers at shit companies is that they always try and fix that problem by buying a new methodology with a buzzword attached to it, reward themselves for having done so, and never reflect on whether anyone's done anything effectively by the time they get a new one.
The lone-developer and the self-directed team mythos' share the common element that they've figured out how to tangle with any real logistical problems they actually have by analyzing them, reflecting on how to do better, and using communication, rather than imagining what problems they have, externalizing the solution with an off-the-shelf template, and identifying how much praise they'll get from anyone but those doing the work regardless of whether the non-plan works.
I was going to hire a junior dev or two until I started talking with copilot all day. Greased lightening.
The hiring process alone would cost us more than their first year salary. Going to avoid it as much as I can.
As a former senior dev (with domain knowledge!), I politely disagree, this model doesn't fit my experience at all.
This would be a dream come true for me. Any advice on how to find such a job? Did you purposely look for it or did the stars just align and you dropped into an awesome situation?
My manager and my bikeshedding coworkers are driving me insane.
I produced my best work when working with my Lead Architect and no Project Management Oversight. Did a complex POC and completed it ahead of expected timeliness and was working alone for most parts.
That POC was approved for incorporating in production and has to be done in agile manner with daily status meetings and biweekly sprint, demos , reviews and whatnot.
Killed my enthusiasm and let another developer take the lead while I moved away from the project