Agile methods generally start and end with the customer. The customer may be internal to your company or an external consumer. Either way you need to understand their requirements and you achieve that through conversation - talk to them, discus your solutions with them, listen to their feedback and suggestions. This all indicates that getting feedback from your team and the users of your software is, rather than being a waste of their time, an indispensable investment of their time; not only in the quality of the software itself, but also in your value as a team member. If your managers and senior engineers are half-decent and familiar with Agile paradigms they will appreciate this, otherwise you have an opportunity to improve the company culture.
The architecture of the system will often be heavily dependant on the IT infrastructure in which your software has to operate: ASP .NET is not the best choice if the target webserver is running Linux. If it's Windows then ASP .NET is great and MVVM (rather than MVC) is a good way to structure your application and assemblies. This means that the architecture choice shouldn't take more than a few minutes to decide!
The design of your solution is the bit that takes the time and experience, and this is where Agile methodologies really do help, because they effectively allow you to improve your design as you go along. Do one little bit at a time, make it work, get feedback from the customer and move on to the next bit, refactoring what you did before if you need to. The 'design' is what you end up with, rather than what you start with. Providing you test thoroughly at every stage and incorporate your customer feedback as you go along, what you end up with will work and if it works then it is a good design. "Only just good enough is good enough." Of course, you do have to consider the 'habitability' and maintainability of the source code.
Test Driven Development is a popular way of managing both the functionality and quality of the code you produce. It's particularly well suited to Pair Programming, but is easy to use when you have to work alone. This is certainly a technique that I would strongly recommend, even if you don't use anything else from the Agile portfolio. When combined with MCDC test coverage you can get a very high confidence level in your software.
Implementing your selected architecture effectively does require trial and error (and research, SO, coffee, cussing, late nights, etc.) but even experienced developers still spend their time going through that. Good development practices help you get to your goal quicker and the whole point of Agile is that it is a collection of "better ways of developing software".
So, to answer your question: stop worrying and start coding (and have fun!) :-)