Agile development is fading in popularity at large enterprises
itpro.com
itpro.com
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
"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.
A release train
Kanban and WIP limits
Refactoring
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.