I work at a company that wants to be agile, but the business analysts often provide us “user stories” that are more solution than problem statement. This makes it difficult to make good design decisions, or in more extreme cases, leaves few design decisions to be made. It does not help the programmers understand the user’s needs or make better design decisions in the future. Our product owner makes an effort to provide us with problem statements, but we still sometimes get solution statements, and that tends toward a “code monkey” situation.
An additional challenge is that some (not all) of my teammates do not see a problem with this, and some of them honestly want to be told what to do. Thus, when we receive a solution statement on our backlog, they are eager to jump right in and work on it.
I believe that as a software engineer part of my job is to understand the user’s needs so that I can build the right thing for the user. However, within our organization structure, I have zero contact with the user. What kind of things can I do to better understand our users?
7
This really depends on your management.
What I have found in over 13 years of software engineering is that I need to talk directly to the customers and sometimes even end users (often in software these are separate entities). Business analysts are hit or miss: some of them understand the customer and end users and write really good requirements (not solutions), some of them go too far and assume too much.
I would recommend talking to your management and argue that you need to be involved earlier in the process, ideally right after sales exits the picture and the BAs enter. Do not be just a fly on the wall: you need to assert yourself as a product expert seeking to understand the problem domain (ugh, buzzwords: you know your software, you want to learn what the customer wants you to do with it).
For existing projects, I would work through your project manager and try to cut the BAs out of the picture. You will likely get answers that match what you have already been told. Do not accept this. Try to get in meetings with the customer to discuss requirements. In an Agile environment there should be no problem with this: if you do not understand something, the customer is the final arbiter for requirements (but not necessarily for what your company will authorize you to do in the billable hours paid for).
Essentially, keep asking questions and do not shut your mouth until you fully understand what the customer wants. Just because a BA gave you an odd-sounding requirement does not mean this is what the customer wants, or that it is the best way to accomplish the customer’s wishes.
2
Direct and honest communication between the development team and all stakeholders is the only reliable way of delivering great solutions that I know of.
This is damn hard to organise and organisations take shortcuts with product owners, project managers, program managers, subject matter experts that can give the dev team some time from time to time. I believe that the role with the most impact is the product owner.
Pragmatically speaking I would suggest that you choose a pet feature and make it the best you can – if it works out, you may get a bigger feature to work on and the success of the first feature would give you more leverage in discussions how to do things.
If you want plenty of opinion about this issue ask at workplace.stackexchange.com.