Programming

That's actually a pretty important part of its original premise.

It's a big part of why scrum meetings were a thing, as the expectation was any curious dev could just join in to see what's up, if they like.

Not tying devs down to 1 specific thing is like the cornerstone of agile, and over many years of marketing and corporate bastardization, everyone had completely forgotten that was literally the point.

The whole point of the process was to address 2 things:

1. That client requirements can't easily be 100% covered day one (But you still need to get as many as you can!)

2. To avoid silo'ing and tying devs down to specific things, and running into the one bus rule ("how fucked would this project be if got hit by a bus?")

And the prime solution posited is to approach your internal projects the same way open source works. Keep it open and available to the whole company, any dev can check it out, chime in if they're familiar with a challenge, etc.

One big issue often noted in non-agile companies (aka almost all of them) is that a dev slent ages hacking away at an issue with little success, only to find out far too late someone else in the company already has solved that one before.

An actually agile approach should be way more open and free range. Devs should be constantly encouraged to cross pollinate info, tips, help each other, post about their issues, etc. There should be first class supported communication channels for asking for help and tips company wide.

If your company doesn't even have a "ask for help on (common topic)" channel for peeps to imfoshare, you are soooooooo far away from being agile yet.