Does Fidelity's Reorganization Signal the Beginning of the End for 'Small-Team Agile'? (bostonglobe.com) 85
Longtime Slashdot reader cellocgw writes: Hiding inside another layoff report, Fidelity is reorganizing: "The changes are aimed at moving the teams away from an 'agile' makeup -- comprising smaller, siloed squads -- and toward larger teams built to move faster on projects." OMG, as they say: "Sudden outbreak of common sense." According to the Boston Globe, Fidelity is cutting about 1,000 jobs even as it plans to hire roughly 5,300 new workers, many of them early-career engineers. Half of the 3,300 new workers hired this year "will be in tech or product-related roles," the report says, noting that "about 2,000 of those jobs are currently open, and 400 of them are in tech/product-delivery."
"The company also plans to add almost 2,000 new early-career workers, with the goal of making the tech and product-delivery teams more hands-on. In all, that means roughly 5,300 new jobs in the pipeline for Fidelity." The company says AI isn't driving the shift; as cellocgw noted, it's about moving toward larger teams that Fidelity says can move faster on priority projects.
The financial services firm also reported a strong 2025 under CEO Abigail Johnson, with managed assets rising 19% from 2024 to $7.1 trillion and revenue climbing 15% to $37.7 billion. "Throughout the company's history, our investments in technology have fueled our growth and customer service capabilities," Johnson wrote in a letter (PDF) included in the company's annual report. "We will continue to prioritize technology initiatives that help us advance digital capabilities, simplify our technology ecosystem, and protect the firm and our customers."
"The company also plans to add almost 2,000 new early-career workers, with the goal of making the tech and product-delivery teams more hands-on. In all, that means roughly 5,300 new jobs in the pipeline for Fidelity." The company says AI isn't driving the shift; as cellocgw noted, it's about moving toward larger teams that Fidelity says can move faster on priority projects.
The financial services firm also reported a strong 2025 under CEO Abigail Johnson, with managed assets rising 19% from 2024 to $7.1 trillion and revenue climbing 15% to $37.7 billion. "Throughout the company's history, our investments in technology have fueled our growth and customer service capabilities," Johnson wrote in a letter (PDF) included in the company's annual report. "We will continue to prioritize technology initiatives that help us advance digital capabilities, simplify our technology ecosystem, and protect the firm and our customers."
One behemoth isn't a trend (Score:5, Interesting)
As much as Agile is the perennial punching bag that many would celebrate dying, reading too much on financial behemoth as an industry trend seems silly.
And call me skeptical on current news like this being anything but creative storytelling exercise on the reason for staff reductions.
Also could use a different "cooler" finance company as trend like Coinbase with microteams with Project Managers with AI agents doing the coding, oh wait they they are cutting staff too...
Re: (Score:3)
Also, bigwigs always think their latest reorganization idea will help teams "move faster." Everything is always "move faster." They say that is the intent, but they have zero evidence that the reorganization will in fact lead to "moving faster." I predict yet another reorganization aimed at "moving faster" within a few months, after this attempt starts to get stuck in the mud because...too many people per team.
Re: (Score:2)
They say that is the intent, but they have zero evidence that the reorganization will in fact lead to "moving faster."
Why do you think their intent is to move faster?
If managers can slow you down, then they need to hire more people below them. That is a promotion for the manager.
Managers are actively trying to slow you down.
Re: (Score:2)
"Managers are actively trying to slow you down." Managers might be, but if they are I suspect is from sheer ignorance rather than any design to get more workers underneath them. The reward system favors using as few people as possible so they can claim x savings at the End-O-Year Roundup.
Re: (Score:3)
I suspect is from sheer ignorance rather than any design to get more workers underneath them.
Wrong. Managers are always scheming to get as many people below them as possible. Claiming savings is an effective short-term strategy that only works in specific circumstances, and it only works as a strategy when it results in more people below you on the org tree.
Re: (Score:2)
Clearly, you have never worked for a good manager. I'm sorry for you. Good managers do exist.
As a manager myself, I listen to my team, I trust them to get stuff done, and when *they* tell me they are overwhelmed, I start trying to convince my management to hire more people. I couldn't care less about getting as "many people as possible" working for me.
Re: (Score:2)
Clearly, you have never worked for a good manager. I'm sorry for you. Good managers do exist. As a manager myself
That's why you're not climbing the corporate ladder. Get more people under you ASAP. Learn to fight off your rivals. Or stay down.
Re: (Score:2)
Right! No thanks. I want none of that headache. It's bad enough I have to fight off my bosses constantly. My priority is to enable my team to be effective, to give them space to get things done, and to make their jobs one that they *want* to do every day. That's what gives me satisfaction and makes my work headaches worth having, because I know I made a difference. And my career hasn't suffered as a result. I manage a team of 21 developers, that's plenty enough for me. And I know I'm not alone. My company h
Re: (Score:2)
Excellent. I applaud your stance. Good managers do indeed exist, even if they are pretty rare. You clearly are one. There is one quality good managers and good engineers share: They want to do a good job. Many managers just want to climb the corporate ladder and that is not good at all.
Re: (Score:2)
I manage a team of 21 developers,
All that and you still can't help bragging about how many people you've managed.
Re: (Score:2)
You can read it that way if you want to. It's a fact, not a boast.
Re: (Score:2)
Why do I think they are forming this large team because they want to move faster? Maybe because the summary says
The changes are aimed at moving the teams away from an 'agile' makeup...toward larger teams built to move faster on projects.
Who said anything about more managers? In Scrum, each Scrum team is not headed by a manager, but is guided by a Scrum Master and a Product Owner. I would bet these larger teams at Fidelity, do not have a single person to manage the project and a single person to build requirements. At best, a single person can produce requirements for only a small number of developers, not single-handedly for a la
Re:One behemoth isn't a trend (Score:4, Interesting)
The idea is to have bigger teams and fewer managers. Maybe instead of team sizes 4-6 move to team sizes 12-15.
Personally I think the problem isn't team size, it's a matter of having people who's entire job is to manage. If managers spend 50% (or some reasonable percentage) of their time doing practical work (ie, work that is not managing), then they are working alongside their teams and the problems will go away.
"Span of control" (Score:2)
It is having fewer managers with larger teams so that managing from the top has less direct and indirect reports.
Agile has a 25+ year run since 2000. Object oriented has a 35 year run.
Business consulting firms - Gartner, Forrester, and such need a new "silver bullet" program, strategy, plan,.... to sell to upper management.
Re: (Score:2)
Business consulting firms - Gartner, Forrester, and such need a new "silver bullet" program, strategy, plan,.... to sell to upper management.
They don't sell to upper level management, they sell to second tier management.
If you're second level, you need to make "positive changes" in the company to climb the ladder, but you aren't smart enough to think of those changes yourself. Gartner sells the plan to second level managers, who sell it to top level in hopes of getting promoted.
Gartner, Forrester, etc are in the "help second tier managers get promoted" business.
Re: (Score:2)
The problem with that is the skills needed to manage and the skills needed to do real work (let's take programming as an example) are pretty distinct. Someone can have both, but they tend to have one or the other. Forcing those without the skills to do the practical work into doing it doesn't actually help the team, it just slows everyone down. And if they get on the critical path of any project you can be royally fucked.
There are a couple of ways to solve this problem:
1)Larger team sizes. This can work
Re: (Score:2)
Larger team sizes. This can work if the team owns enough to keep everyone busy, but it can lead to effectively being independent subteams calling themselves one team while being inconvenienced by each other.
A large team will inevitably split itself into smaller units.
Among the larger team there should and will be some higher level coordination, but the lower level discussion necessary to get things actually done only scales up to small team size before becoming so much overhead to become problematic.
Re: (Score:2)
The problem with that is the skills needed to manage and the skills needed to do real work (let's take programming as an example) are pretty distinct.
Normally people become managers with zero training in management. It's not a high skill position.
If you want to manage, then this book [amazon.com] will quickly get you into the 98th percentile of managers. Only 224 pages.
If you want to climb the corporate ladder, that is the difficult side of management. I don't know any good books about that.
Depends on your goals, I guess. (Score:4, Interesting)
Agile teams are a great way to waste small amounts of money quickly. But if you want to waste money in vast amounts on an enterprise scale, they aren't the way to go. Throwing huge teams at a problem is fantastic by comparison. It drives up burn rate, drives down efficiency, and extends timelines while claiming the opposite. Small teams cannot compete.
Tongue only partially in cheek... I watched a team of hundreds of local and remote workers burn $400M in a catastrophic waterfall grand attempt and fail completely. The worst agile failure I witnessed burned $4.5M before the plug was pulled.
Re:Depends on your goals, I guess. (Score:4, Interesting)
I looked at a waterfall project where the mayor ended up spending $3M to have an audit done on the current state of a project that was way behind on time and way over budget, only for them to come back and say that it'd be cheaper to burn all the effort to date and start fresh.
Re: (Score:2)
and no doubt it was waterfall that was to blame. Super important to get that detail in there.
$3M for an AUDIT but management couldn't be to blame, right?
Re: (Score:2)
Management was blamed. (Score:2)
Actually, management was blamed left and right, the audit helped force the contracting companies to eat far more of the cost, etc...
Trick i failed to mention, it was the NEW incoming mayor that ordered the audit, and less than 1% of project cost to date.
Re: (Score:2)
only for them to come back and say that it'd be cheaper to burn all the effort to date and start fresh.
That is the state of many projects. The problem is that for that to work, you need to also get rid of the management idiots that caused most of the issue. I have seen a case in an organization where a critical project needed to fail three (!) times over 6 years before they identified the idiot at the top that made that happen.
Re: (Score:2)
In this case, the prime manager, the mayor, had just been replaced inthe election.
Re: (Score:3)
Re: (Score:2)
i've experienced the same with huge agile team trees to catastrophic results. it's not really inherent to the methodology but to the real goals you mentioned: burn money to increase valuation to eventually sell off. any methodology will succumb to that. if anything agile actually allows for more confusion, discordination, obfuscation and most of all plausible deniability (i can almost hear some true believer shouting "then you're not doing agile right!" which ... just describes the majority of companies doi
Re: (Score:2)
In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.
There are some things that agile works well for, but it's really limited to domains where you can quickly build something tangible for feedback and you have stakeholders willing and able to give frequent feedback. UIs are a good example. It's a horrible fit for anything that requires actual research, or that can't be shown
Re: (Score:2)
In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.
So true. Same with programming languages, too. Good engineers solve problems in the constraints they are given.
Re: (Score:2)
Actually, really good engineers shape the constraints they solve a problem in. But that also requires good managers and these are very rare.
Re: Depends on your goals, I guess. (Score:2)
Oh if I had points right now, +1 to you sir.
Re: (Score:2)
Appreciated nonetheless. Thanks.
Re: (Score:2)
In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.
Indeed. "Agile" just stands in your way in a more obnoxious manner. It does not fix anything if the people cannot do. It does not fill any need or provide any improvement if the people can do. It is merely an expression of the permanent need of "managers" to not respect people as individual and see them as easily exchangeable function units. That does not work and cannot work.
Oh, please, not again. (Score:5, Interesting)
First of all, the singular term is "agility" not "agile". Second of all, agility isn't a means, it's the end. The actual goal. And "agile software development" is a thing and will remain a thing in teams and "projects" where it fits and makes sense. Those are scenarios with experienced teams booked on a well-seasoned and under control stack with which every team-member has solid experience to basically take on any task in the scope of the project.
Agile software development is the _solution_ to the problem of clients not knowing what they want and developing a piece of software that isn't military, medical, space, aeronautic, nuclear, mission-critical embedded or some other hardcore stuff. This is why agile software development is most often used in web development and generic user-facing software for vertical markets. Because that's precisely where you find customers who are usually overwelmed with formulating the requirements of a piece of software to be programmed.
And no, it's not at an "end" and no, it's not "dead". Perhaps the fad with dimwitts has died and they've moved on to another new buzzword, but that would be a good thing.
Agility or Agile Software Development is still alive an well for anyone actually aware what those terms really mean. See the original Manifesto for Agile Software Development [agilemanifesto.org] for further details.
Congratiulations, you are now ahead of 99% of the buzzword crowd. You're welcome.
Re: (Score:3)
Great, Agile is the just manifesto. And we'll pretend that in the real world that it doesn't mean Project Managers that are certified Scrum Masters like to inflict time wasting ceremonies, some pointy hair manager trying to implement some Scaled framework (which is probably the case in big finance), or something that didn't get planned onto some obscure Kanban board for a pizza-boxed sized group. We'll No True Scotsman Agile into nothing but a theoretical ideal that can be wiped away as "just not implemente
Re: (Score:2)
"...will remain a thing in teams and "projects" where it fits and makes sense"
Web page development.
"Those are scenarios with experienced teams booked on a well-seasoned and under control stack with which every team-member has solid experience to basically take on any task in the scope of the project."
Projects that have no need for specific experience or specialization, where everyone does the same thing. Web page development.
"Agile software development is the _solution_ to the problem of clients not knowin
Re: (Score:2)
Actually, changing requirements during development do not work and cannot work. You always get a defective product. This is not unique for software, but all engineering. The role of "Agile" is merely to obscure that fact and pretend it is not true. Classical incompetent management at work, thinking they are not the problem.
Re: (Score:1)
Agile software development is the _solution_ to the problem of clients not knowing what they want and developing a piece of software that isn't military, medical, space, aeronautic, nuclear, mission-critical embedded or some other hardcore stuff.
That is wrong.
The area has nothing to do with it.
Agile actually means what the word implied to mean: being agile to change direction, up to canceling the project if it is clear we are going nowhere. Fail fast, fail early, instead of burning a lot of money and time.
Dissing Agile (Score:4, Interesting)
People diss agile today because they don't remember how it was before Agile, and how teams that actually succeeded kinda sorta did something like Agile. Agile wasn't adopted by software companies because it was some new religion. It was often adopted because software companies were already "cheating" and Agile just set a framework that could make it work and not feel like cheating anymore.
That being said, successful companies cheat in Agile too.
What's going to replace Agile is some methodology where the new AI tools are going to interconnect to make the team much more productive.
Fidelity hiring 5000 juniors to replace their 1000 seniors .. hmm.. frankly that's not going to work.
Sounds like an idea some MBA came up with to "save money".
Re: (Score:2)
Ageism is illegal. But that isn't stopping Fidelity from ditching the senior level staff to replace them with a bunch of greenies.
Re: (Score:3)
Re: (Score:2)
Well, expect nothing working at Fidelity anymore in a few years and all their data getting stolen, probably several times.
Disrespect the technology and it kills you. Thinking it dopes not require skill and experience to deal with is the ultimate form of disrespect.
Re:Dissing Agile (Score:4, Interesting)
"People diss agile today because they don't remember how it was before Agile, and how teams that actually succeeded kinda sorta did something like Agile. "
No and no. Real software development requires design. Agile is a race to accumulate band-aids. Never time to fix anything, only time to cover garbage up.
"Agile wasn't adopted by software companies because it was some new religion."
Even though it was a new religion. Agile targets managers, it defines doers as literally all the same and interchangeable, then creates worthless metrics that managers can use for performance claims. Agile is adopted because of weak managers, just like religion is adopted by weak minds.
"That being said, successful companies cheat in Agile too."
Agile is cheating, they are synonymous. No design, ground up approach, worthless metrics, no long term values, no team development.
"What's going to replace Agile is some methodology where the new AI tools are going to interconnect to make the team much more productive."
Agile is shitty management, not shitty product development. Agile precludes good product development, but tools do not fix that, real project management does.
"Sounds like an idea some MBA came up with to "save money"."
A bean counter version of Agile.
Re: (Score:2)
Re:Dissing Agile (Score:5, Insightful)
No and no. Real software development requires design. Agile is a race to accumulate band-aids. Never time to fix anything, only time to cover garbage up.
That's not true at all unless "Agile" is being touted as excuse to do a sloppy work. Part of the work when doing Agile properly is refining design decisions and aggressively refactoring consequently. There should be a lot of design considerations being done continuously when doing Agile.
Said that, there are teams which do use "Agile" as excuse to cut corners and keep solutions half-baked, so I get what you mean.
Agile targets managers, it defines doers as literally all the same and interchangeable, then creates worthless metrics that managers can use for performance claims.
That's a key issue. The "original" Agile Manifesto and Agile movement was developer-centric and tried to offer pragmatic solutions for developers wanting to get the job done. When Scrum entered the place, it turned "Agile" project-management-centric, with focus on processes and "ceremonies" to integrate in a corporate strucuture which is almost inevitably highly hierarchical and top-down driven.
This is a big source of endless discussion because the two are very different things. It's like an American talking about "liberals" vs. an European, where in America it means "neo-liberals" and in Europe more likely "classic-liberals", which couldn't be more far apart in ideology.
Agile is cheating, they are synonymous. No design, ground up approach, worthless metrics, no long term values, no team development.
Some of the most elegant and effective designs I produced were developed with Agile. "Emergent design" can be superior because it can profit from lessons learned during its own implementation and will continuously get refined during the life of the solution, as long as the solution gets properly adapted to those lessons which is exactly what Agile is supposed to achieve.
How Agile operates is by continuously adapting to new lessons learned and situational changes, but it is supposed to be done aggressively and in a clean way. Not doing that or doing that through ugly hacks is not how it's supposed to work.
Re: (Score:2)
Real software development requires design. Agile is a race to accumulate band-aids. Never time to fix anything, only time to cover garbage up.
Indeed. The only case of "Agile" I have seen working was when it was circumvented. External team was forced to do "Agile" because the whole enterprise was forced to do it. Their leader decided to make "sprints" 6 months long. Turns out they were the ones that continued to deliver adequate results.
Re: (Score:3)
Real software development requires design.
I agree in principle, but real software development almost always runs afoul of real deadlines.
Never time to fix anything, only time to cover garbage up.
I agree completely. This happens regardless of development methodology. This is standard market practice. There is never enough time.
Agile has gotten a bad name from how much useless cruft has attached itself (including having a formal definition). Worthless metrics are a real problem, but they have been around for far longer than Agile has had a name. Actual agile development can be done on very few principles, b
Re: (Score:2)
Fidelity hiring 5000 juniors to replace their 1000 seniors .. hmm.. frankly that's not going to work.
Sounds like an idea some MBA came up with to "save money".
Obviously. You have to be really, really, really dumb to think something like that can work. You also have to have a completely outsized ego and think that devs are easily replaced low-skill workers and experience does not matter at all. Unlike the god-like management you are doing and obviously you are not replaceable at all. Sounds familiar?
Demented moves like that cripple or (long term) kill an enterprise.
Re: (Score:2)
"Fidelity hiring 5000 juniors to replace their 1000 seniors .. hmm.. frankly that's not going to work."
If they expect to replace the seniors today, yes that's not going to work.
If they are looking to have replacements for seniors in 20 years, that's about half of what they will eventually need.
Even if you are downsizing, you have to keep hiring juniors so that all levels of the career ladder are populated.
Same crp (Score:1)
Re: (Score:2)
Fidelity Investments. [fidelity.com] They're a financial-services company that offers trading, banking, financial planning, education, and other stuff. Similar to ETrade, Schwab, etc.
Re: (Score:1)
So a nobody company that doesn't deserve a story. Gotcha.
Re: (Score:2)
So a nobody company that doesn't deserve a story. Gotcha.
Hardly. From TFS:
The financial services firm also reported a strong 2025 under CEO Abigail Johnson, with managed assets rising 19% from 2024 to $7.1 trillion and revenue climbing 15% to $37.7 billion.
As I said, they're peers with ETrade and Schwab.
And as for them deserving a story, they're abandoning an "agile" approach in favor of larger teams focused on specific projects. It will be interesting to see whether they succeed with the new development model. So, the story fits the Slashdot ethos of "News for Nerds. Stuff That Matters."
Re: (Score:3)
They're one of the 4 biggest stock brokers in the US. If you aren't trolling, you're showing yourself to be really ignorant.
Re: (Score:1)
He a typical nerd left loonie who thinks that dissing anyone who uses or makes money makes him great for "sticking it to the man". Same sort of guy who think his users are nuts, laughs at people who do not use leet command line UIs and jacks of to ASCII Art Porn in his mother basement because he cannot interact with real humans. And only Open Source ASCII Art Porn Written by other nerds in Vi. AI is definitely not on, and if it is closed source... wel it involves money so it is not leeeeet enough.
Re: (Score:1)
One of the largest companies managing 401ks and IRAs in the country. Anyone who's worked more than 30 years in corporate America has likely had, at one time or another, a 401k managed by Fidelity. I'm having trouble believing you've never heard of them.
Is this really about Agile? (Score:3)
From the description it sounds more like the company is replacing older but experienced staff with young but manipulable staff. All the talk about protecting the company interest and investing in new tech sounds like a more evolved narrative for AI displacement.
In short, newbies wil use AI to hope for the best, won't argue about work conditions and will do it for less money.
Re: (Score:2)
Cut the pay for the doers, redirect the pay to executive staff.
Re: (Score:2)
Indeed. But cheap engineering always ends up being exceptionally expensive. I guess there are still a ton of "managers" that are completely clueless about software creation.
Just stop (Score:1)
Larger teams will move faster than smaller teams? (Score:4, Insightful)
Think about CPUs. If you have 2 cores, the processor is 2x the speed of 1 core, right? And 16 cores is 16x faster than 1 core, right?
Hardly. The more cores you have, the more coordination overhead is required. If your tasks are truly parallel, with no dependencies, then sure, you can get 16x work done with 16 cores. But real software has dependencies. So Core 2 might have to wait for Core 1 to finish something.
Teams of people are the same. If you have a team of 16 working on truly independent tasks, sure, they can get a lot more done than a smaller team. But real software has dependencies, and the more people you have, the more waiting you will have.
Also, for years now, the hardest part of programming is not the code writing, but the development of the specifications / stories / PRDs / whatever your company uses to define the work to be done. Teams regularly outpace the development of new requirements. Bigger teams will only make that ratio more out of balance.
No, I'm not buying that bigger teams will move faster.
Re: (Score:2)
They can, under some circumstances. If the scope of what they work on is too small to fill the team's feature set. Or if the work they would be doing is significantly less important than other work to be done, having them in one large team makes it easier to move to more important work and can get critical features built faster. In that case it may not be overall more work done, but it may move the important stuff quicker. If larger teams weren't useful on some level, we wouldn't have teams at all- we'
Re: (Score:3)
What you are describing is a problem of prioritization. The art of prioritization isn't confined to large teams, multiple small teams can work on the "most important things" first just as easily.
The reason we have teams, is that there is too much work to be done, to be accomplished by a single person. Collaboration is a necessary evil, a cost that must be paid, in order to have multiple people working to get things done. The larger the team, the more collaboration overhead must be paid for.
Also, there is th
Re: (Score:2)
No, it's more about how teams work. Teams have a scope. They don't typically go beyond that scope. So if my team owns the Foo and Bar modules, I work on those. But if there's little important work on Foo and Bar, but a lot of important work to be done on Baz, it's generally organizationally difficult for us to work on Baz. Typically we need to be lent out by our manager and seconded to the other team. Which can be a lot of red tape and politics.
Now if you're imagining some alternate world where progra
Re: (Score:2)
I agree, if there's not enough work for a team to do on Foo and Bar, to keep the team busy, the team is too small and needs to have added responsibility.
My preferred team size is 3-5 developers. This is big enough to work on significant projects, and small enough to be nimble. A team of 25 cannot be nimble, under any circumstances.
Re: (Score:2)
Incidentally, just in case you are unaware of it, there are only 3 developers in what Brooks in "The Mythical Man-Month" describes as the perfect software engineering team: There is the "chief programmer", the "copilot" and the "toolsmith". Nobody else writes code, they are all support for those that do.
Depending on the task, I would think you can extend the number of coders a bit, but not much without efficiency and effectiveness suffering. I think, for example, that you can have more than one tool-maker i
Re: (Score:2)
Yes, the Mythical Man-Month is a classic that everyone in software should read. He saw Scrum coming before Scrum existed. There were roles he couldn't envision at the time, such as UI developer. But that team size is about right.
Re: (Score:2)
There is a well-known ideal team size for engineering design work (which software is) it is around 5-10 people. Go over that and you lose efficiency. Go significantly over it and total (!) productivity drops. Above some size a team cannot deliver results anymore at all. This has been known for a long, long time, but "managers" are typically ignorant.
Re: (Score:2)
If larger teams weren't useful on some level, we wouldn't have teams at all- we'd all be individuals.
Large teams are useful for exactly one thing in engineering: Making the person on top feel important because of the large number of underlings. No other positive effects.
This is, incidentally, also the way bureaucracies grow. Bureaucrats define their personal worth by how many people they control (whether directly or indirectly by forcing them to follow demented procedures).
Re: (Score:3)
Brooks described that nicely in "The Mythical Man Month". Should be required reading for anybody that manages software creation.
And yes, bigger teams will very obviously not move faster. They cannot. At some size-point all they do is meetings.
Nimble vs. bulk quantities (Score:3)
A ship is the fastest way to get huge amounts of cargo from one place to another. But it's the opposite of nimble. And it requires extensive pre-preparation (loading cargo into boxes, onto pallets, into shipping containers) before the journey can begin, and then unbundling at the end.
A motorcycle is that fastest way to get ONE person and a small amount of cargo, from one place to another. No need for a tun of up-front prep, just pick up your bag of groceries and throw it in the trunk.
Team size depends on what you value: the ability to be nimble, or the ability to get large quantities of parallel work done. The latter requires much more up-front preparation, and much more user acceptance testing. The former allows quicker pivoting, and each small increment requires much less testing.
There is a place in this world for both types of software development. One company's decision doesn't change that.
I think the opposite (Score:2)
One cycle starts as another ends (Score:2)
Mythical Man Month (Score:4, Insightful)
Adding more people to a software team does not make the team move faster, nor does it allow you to ship better software faster. This has been well-known for about five decades.
Whether you use small teams and switch to big teams, or use big teams and switch to small teams, the output will be shit if the people coordinating the work and the people doing the work aren't good at their jobs.
You can't take young inexperienced people and make their output smarter just because you have lots of them.
The biggest barriers to productivity in any corporation are organization, communication, and agency. Road blocks are death by a thousand cuts.
All of this means that just changing team size will make no difference whatsoever by itself.
Re: (Score:2)
Indeed. But "managers" are typically fully incompetent and do not even know these basic and well-established facts. And hence the same stupid and expensive mistakes are being made time and again.
My guess would be that some senior engineers at Fidelity told "management" these basic facts and that what "management" was doing was not going to work. Hence "management" decided to get rid of all these naysayers and hire young and clueless people. Expect Fidelity to not exist anymore in no more than 10 years.
Agile streamlined management waffle :o (Score:2)
“These changes are about getting the right combination of skills in place for where Fidelity and its customers need them most. This means creating more room for early career, hands-on engineering roles and streamlining management layers.”
"Fidelity’s belief [cbsnews.com] is that being physically toget
The original agile manifesto made sense (Score:2)
Then it got mutated by authors, pundits, managers and others who turned it into a rigid process with many problems
Re: (Score:2)
Well, yes. But it started with "Individuals and interactions over processes and tools".
Respect individuals? That is not something management does! Cannot have that! So the usual "Agile" implementation starts with disregarding the first line in the Agile manifesto. And usually it goes downhill from there.
"The Mythical Man Month" (Score:2)
It might be good for Fidelity to read this classic tome.
Short version: Adding more people to a project doesn't speed things up.
Re: (Score:2)
They will have been told. Why do you think they are firing all the senior engineers with a clue?