There are a few approaches you could take to determine user needs before implementing them in your software. One of them is to look at existing software designed to address a particular area of concern, and to note where it is lacking. Another is to imagine what the ideal software would do, if it existed. It may not even be possible to implement the ideal, but it is a good exercise to do, and you could follow it by approaching the ideal as closely as possible.
User stories help by giving you concrete scenarios that you could envision your software being used in. It's a transition from thinking of features themselves, to the scenarios that represent problems to be solved. For example, rather than thinking of an alarm feature and how you might want to notify a user at times, your frame of thinking could be shifted to a real world scenario where a user must not be late for work, and depends on their alarm to wake them up at the appropriate time. Obviously, a failure to alert the user would be terrible, but the scenario of missing a day of work due to a failed alarm is much better at conveying the importance of perfecting the feature than some intangible description of it in isolation.
Developing programs should be approached piecemeal, beginning with a consideration of the core functionality for a feature, and then noting any extreme situations that could occur (out of range errors, unexpected input, etc). Once tests are developed, you implement the base functionality, test it, and then either fix any failing tests, or continue to work on the next feature. Occasionally, integration tests are performed to ensure that there are no conflicts between code. This cycle continues until the project is completed.
In terms of agile processes that I would incorporate into my future development work, I would like to implement Scrum, Kanban, Lean, as well as TDD (Test Driven Development) and CI/CD (Continuous Integration/Development). Scrum seems like a very simple and effective method for managing a team, especially one where there is no hierarchy. Kanban is a good way to measure progress towards project completion, where you can visualize your flow and where stoppages may occur. Lean is a brilliant way to minimize waste and improve performance by doing only what is necessary and nothing more. TDD ensures that tests are not an afterthought, but are front and center as part of the development process. CI/CD means that quality is put first, and that issues are addressed as code is written rather than left as bugs to be addressed later. As I look back on these processes, it seems to me almost as if software development as a profession is growing up and incorporating standards to elevate the quality of the work produced. I'm excited to learn about and be part of this change.
A good team member in software development is one who is respectful, shows up, does their work in a timely fashion, and inspires others to better themselves. They should be collaborative, willing to engage with their team to make the work easier for everyone. At the same time, they should push themselves to better their own skills, and learn as much as possible. This way you can increase the quality of your work, and have something of value to teach less experienced members of the team. I believe a good team member should exemplify the ideal as much as possible, in that you should be diligent, courageous, patient, curious, and lighthearted, forgiving mistakes where necessary, and dispensing solid criticism where needed. A team is, in some ways, reminiscent of a family. You should wish the best for each other, helping others to be successful, but also not be afraid to point out where improvements must occur.