Agile development is fading in popularity at large enterprises(itpro.com)
itpro.com
Agile development is fading in popularity at large enterprises
https://www.itpro.com/software/agile-development-is-fading-in-popularity-at-large-enterprises-and-developer-burnout-is-a-key-factor
37 comments
> 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.
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.
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.
My model is overfitted to senior devs with domain knowledge.
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.
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.
> My model is overfitted to senior devs with domain knowledge.
As a former senior dev (with domain knowledge!), I politely disagree, this model doesn't fit my experience at all.
As a former senior dev (with domain knowledge!), I politely disagree, this model doesn't fit my experience at all.
> 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.
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 looked for it, planned for it, AND it fell in my lap. Chance of a lifetime.
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
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
Multiple devs are fine. Its the “management” that kills things.
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.
Unless your company cares at all about bus factor
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.
Agile scales as poorly as does general efficiency of the development team within the same project
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....)
SAFe 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.
"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.
> SAFe does have agile concepts in it that make sense overall
Like what exactly?
Like what exactly?
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.
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
Kanban and WIP limits
Refactoring
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.
https://scaledagileframework.com/safe-team-kanban/
https://scaledagileframework.com/safe-team-kanban/
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.
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.
no
SAFe won't go away soon... https://overbring.com/blog/2023-04-27-safe-agile-souffle/
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.
whoswho(1)
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.