What are the key parts of agile, if any, that would help me as a SWE? What's your working strategy?

My take: it is helpful to try to ask questions immediately when something is unclear, ship a piece of it asap, retrospect, and keep the cycle going.

Also generally I feel waiting for engineers to first look at a problem after non-engineers have planned it out completely from their side is not going to go well.

When trying to ship something big, I am most concerned with knowing what the first step is we can take, how many independent/parallel work streams there are, and what decisions can be made early to keep those streams running as independently as possible.

Certainly knowing what you’re supposed to build is critical, but something like exact UI design shouldn’t block you building the data aggregator. The exact format of a service reply from a dependency shouldn’t stop you from creating your business logic or persistence layer. What the expiration policy is for retention of your data shouldn’t block design approval.

If you really need a single design to rule them all for the whole system, you should still devolve most of the details to design docs scoped at a module or service at largest. The big picture can compose these, and show overall data flow, have blocks for caches and storage, etc, but semantics of calls or locking or something should be in a lower level design. Having sub-owners for each of these designs, and giving those individuals ownership of implementation (with you possibly owning one, but contributing where need is most) helps further make things run in parallel.

For me this isn’t like… what methodology or what rituals you perform, it is about having the fewest number of blocking dependencies as possible. If a decision can be made later, make it later. If a decision isn’t terminal/one-way, make it with less data and do so early, knowing you can change course later when the new information arrives.

Last thing I can think of is to start any review you need (design, privacy, security, data, whatever) at the start of the project, and provide the assets as needed. Get these done as soon as you can. Waiting until code complete makes this a huge serial effort when you have the least wiggle room. If any of these trigger required changes, the sooner you know the cheaper it is to fix. Again, if you can decompose these to module or service level, instead of needing a single reviewer that groks a giant system, that’s great.

So really, what I think the “good parts” of Agile or Scrum or whatever are isn’t like… having a standup or whatever, it is not trying to write requirements in stone with every possible contingency covered, then starting coding, then doing iterative testing, then doing documentation, then doing internal reviews. Doing least-informed decision making, working on all stages in parallel, and changing course as soon as something is known, tends to go way better.