In my experience, there are a few things that you can do as a developer to combat this problem, in yourself and in your peers:
- Immerse yourself in the business problem - before the product.
- Use the businesses terminology for your entities - it will make communication so much easier
- Spend time with the users (not necessarily the stakeholders) - see their pains and understand their fears
- Look for opportunities as well as threats - people can sometimes fear change, is there some opportunity to make them adore the new feature by simplifying/clarifying their experience?
- Don't be precious about your role - you probably have nearly as much analysis experience as your BA, so use it to their advantage by offering your help.
- Make them like you - this is really important. There needs to be no barriers because you can only really build to their quality of requirement. Make time in your day to find out about their interests outside of work or family.
- Collaborate - Don't have a 5 minute conversation before composing your documentation in isolation from each other. Don't communicate with them via email.
- Know what your soft-skill capabilities are and spend some time developing them as you do your technical skills
- Ask for peer evaluation of your soft skills periodically, and plan what to focus on improving next
- When you're driving home at night, reflect on the interactions you've had with people during the day. Be your worst critic and decide what you'd do differently if you had your time over again
- Don't keep the techniques and skills you learn to yourself. Evaluate your peers and help yourself by influencing them in the areas they need to improve. Can you do this without them realising? So much the better.
- Talk to people about how important soft-skills are - in addition to your covert operations, simply asking people what their opinion on say 'teamwork' is can provoke a discussion that can be to their benefit and yours.
- Consider doing something in the wider software development community. I hesitate to use the word 'evangelise' in our industry these days, but that's really what I'm talking about.
- Honesty in software development is crucial. As a rule I would always follow this simple process: Say what you intend to do, do it, say what you've done. Admit when you goof, as early as possible but with a plan in your head of how you can avoid the mistake in future.
- Bravery is about; not taking the popular line simply because its popular, playing devil's advocate when an opinion has not even been considered, don't allow people to be dishonest with you - ask questions until you are sure of their real intent/motivation.
- Cut the apron strings. It's oft quoted but I find it immeasurably true; Ask for forgiveness rather than permission. Using your initiative more and more will build your confidence and allow you to be brave and honest.
The above is by no means an exhaustive list, but I think it's a good reference point for you to reflect on how you work. Feel free to comment on what you think I've missed, got wrong, or you don't understand.