How would it even be possible to name a service "Google helpdesk - password reset" or something like that, without being insta banned? Obvious fraud in the making, not getting recognized?

I don't have the numbers of other manufacturers, but 30% doesn't sound like outrageously much to me. That still is an overwhelming majority of non-recycled materials. An improvement is good, but 30% is nothing worth writing home about.

The shipped nearly 250 million phones last year plus millions of other products. Having 30% recycled materials across a production line of that scale is massively impressive if you ask me.

Maybe just does a search for it on some discussions here and finds them that way.

Exactly, it doesn't have to be about them lying. It could simply be, that they let go or lost one of their engineers and that person knew why to do what and the next one didn't, accidentally exposing stuff.

How to shoot yourself in both feet 101

And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.

Which means Agile will always be more expensive, time-consuming and difficult than alternatives.

Say you're building a boat. Boats require not only lots of skills in woodworking, but a whole 'nother skill of design, to get a boat that does what you want on the water. It is always time-consuming, expensive, and hard.

And there's two basic ways to build it: with plans, and without plans. Without plans, you have to design it yourself, then try to build it, then make mistakes, maybe even to the point you have to start from scratch. Time-consuming, expensive, hard. But start with plans that have already been built, and you benefit from somebody else's time, money, expertise and toil. The boat is built faster with less effort and fewer mistakes. And instead of needing master craftsmen, you only need journeymen who can follow orders.

No, that's not at all what it means.

It means, that you need capable engineers, who are willing to talk to users and build understanding, rather than just being Jira task rabbits. It means, that you might not even need all the intermediaries, each having their own personal agenda and incentives, that engineers usually have to put up with. It also means, that certain layers in an organization have to trust their employees a little more.

It means, that what you build it based on user feedback, rather than what someone tells the engineers, what the user feedback supposedly is, without having a clear idea, what the users actually want. I have seen this first hand. When in the beginning of the product I as an engineer interacted with the users and found out their issues with the platform I was developing, later on the organization added hierarchy layers, shielding or preventing engineers from talking to the users, to build their own job moat, and patronization going on in terms of "Your time is better spent developing the actual features.". In the end the product ended up drifting far from what is good for the actual users, and instead people talked more to B2B customers, than the employees at those other businesses and what they actually need or want.

With each additional layer between the user and the developer (which is also people who want to be paid btw.), the business is inflicting significant cost and increases the risk to steer off course.

Perhaps needing to estimate tasks in cloud credits? That would be a new one. And then of course mapping those credits uselessly to time needed.

Maybe you gotta do daily standups with all your own Agents and then have both you and them do standup with the rest of the team's Agents to touch base, sync up and loop back or whatever.

In an actually agile project or organization, the source of truth is the user of the software, because the developers periodically and whenever else necessary talk directly with the users and listen to what they have to say, and put that into writing.

In a fake agile project or org, the source of truth is a made up document written by the PO or PM and only remotely related to what the actual user says. Devs are kept away from the user by their higher ups, who seek job guarantees.

If you don't care about definitions, then it would be good to not perpetuate using the word agile for your own set process. "Individuals and interactions over processes and tools"

Until the agents start touching things that already worked well before and break them.

They do need a competent developer operating them. That has nothing to do with whether nor not specs have value.