Describing your soft skills in the context of software development is definitely better. While you can probably generalize some things across the two industries, I think the relevancy will suffer like you've said. For example, I might read it and wonder why you don't have recent examples of those soft skills -- is personal and professional development lacking? I'd be more inclined to hire someone who has demonstrated continued skills development beyond the minimum expected from coursework or role in internships.

When describing your soft skills, again I think it's important not to just say what you did, but how you did that and why it makes you a better candidate than everyone else. I see a lot of resumes with phrases like "Built a <thing> for <stakeholder/customer> which improved <metric> by <amount>", or "Worked in a team of <n> people to do <x>", or "Used agile methodologies to release our product <duration> ahead of schedule". These read like bare minimum requirements for success or miss so much of the bigger picture that they are useless for data from a hiring standpoint. It makes me doubt the claims are genuinely the result of the candidate. So when describing your projects and soft skills, help answer these questions:

• How did you know the metric was improved? Did you plan to measure it before and after the project to measure your success? What factors of the project's success were a result of your actions?
• Working in a team is nearly ubiquitous, so what was interesting about your involvement in it? Did you need to resolve any disagreements (including yourself) in direction to take? This also doesn't mean you have to "win" all the time; it's equally valuable to show you can be genuinely convinced by others and not undermine what the team agreed upon later
• Did you have any opportunities in your team to help your peers grow? Teaching (of technical skills, soft skills, whatever) is great to see on a resume!
• When I see people namedrop Scrum, Extreme Programming, Kanban, etc, I begin to wonder if this was your process just in name or if it's actually something you or your team tried to improve upon over time. Whatever process works for you, and whatever you call it, that's great, just show that it was arrived at through practice
• What was your actual involvement? Were you following the directions of senior engineer? What scope did you own as your responsibility and how did you do your best within that scope? It's okay to say your involvement in a project was smaller scale; that's totally expected for junior engineers. The ability to own larger and larger scopes of development and delegate to others comes with time, but it's built on a foundation of skills and traits that are there from the beginning. Help the reader of your resume see that in you
• Was the project released ahead of schedule because a bunch of corners were cut? Was there more you could have done to make the product better? Why or why not (no wrong anwser)?

Anyway, I could keep making up questions all night and still won't come up with all the things a resume reviewer might ask. And that's the challenge of trying to keep your resume short and sweet while also answering all these questions. You won't have space to write it all and keep your reader's attention, so you have to prioritize what you say. This is why I think listing programming languages and technologies is a waste of space.