How much should a developer contribute in business analysis meetings of a software project?

Question

I've previously worked in a project where mostly my Team Lead, Project Manager and the Business Analyst would sit together and discuss the business of our project. They'd attend client meetings and takes notes of requirements. Then it's always them three discussing about the business and making requirement analysis. The other developers and I were never any part of it.

Then all of a sudden, one day, I was surprised that my Team Lead told me and another developer to attend one business analysis meeting. I was mostly sitting silently, listened to what the other guys said and took notes. I never expressed my opinions there. I was feeling like I was not really sure what to do there.

My question is, what is actually the appropriate attitude on my part i.e. developer's part in these type of business analysis meetings? Was my attitude correct in the above mentioned situation? How much participation and contribution is expected from a developer in such meetings?

My team lead later hinted me indirectly that he expects more enthusiasm and participation from me regarding attending business meetings, rather than just stick to coding. How right is he? Should I consider his advice seriously? Does this mean he expects to see me in a Technical Lead or Management position in future, so he wants me to get prepared and accustomed to attending business meetings from now?

Answer 1

The reason he expects you to attend the business meetings is

1. to understand the problem domain;

2. participate in the requirements analysis ao that you understand what is going to be done;

You are not coding in a vacuum and apparently, your team lead expects his software engineers to function as software engineers and not as code typists who are simply told to code. Which is what we expect from a competent team lead.

Your team lead's requirement is a core duty for software engineers. Sitting around like a potted plant and neither asking questions nor taking notes while others are asking questions and taking notes as to what has to be done - that will mark you as as uninvolved and uninterested in a key part of the software development process and count against you.

With respect to taking your attendance at these meetings as a sign that you are being groomed fo promotion, you are jumping to conclusions and getting ahead of yourself.

Answer 2

All technical people should be ready to participate fully in requirements definition. When no technical people are consulted you get requirements that are too vague to be useful in developing code or requirements to do something specific when it won't solve the actual problem they have or all sorts of other things.

What you bring to the table is twofold, your knowledge of how programming in general works, what is and isn't feasible from a purely technical standpoint and your knowledge of how the current system the project is being integrated into works or your knowledge of the system that is being replaced. Both are invaluable in determining requirements. You can keep them from going down a wrong path.

But there are other reasons to be there and to participate as well. IF you have ever played the childhood game of telephone, you know that the message deteriorates the more people it passes through. By being in on the meeting, you know what was actually said and how others in the room interpreted it. This keeps you from getting a poorly passed on message. You also start to see the business reasons why things are being asked for and start to develop an understanding of the business domain and can start to think of how you can solve the actual problems they have rather than what they said in the formal requirement.

If things are unclear to you, then you can get the information from the source not passed through 12 people when you ask a question later while you try to implement. This helps prevent deterioration of the information so that Client A wants problem B solved but by the time the message gets to you it has morphed into problem ZQ. This greatly increases your chances of building what they need instead of what was told to you after passing through many people. If you are developer, you should be fighting to be included in these meetings. Any place where devs are excluded is doing it wrong and will have many more bugs than they need to have You don't want to waste time solving the wrong problem.

Next you have a chance at this stage to influence the direction of the project which is also invaluable. Ask any very experienced dev how often they have been forced to build something stupid because no one could clearly communicate with the ultimate users.

You can stop account managers and BAs and other people from promising what can't be delivered in the timeframe. It is often too late to protest the schedule after it has been agreed on in a meeting like this. You can point out all the things they haven't thought of that this will involve so they understand why the timeline doesn't work.

I have seen a group of people think that a change must be simple because how hard can it be to add a button to a form. It never occurs to these people that the button won't do anything unless someone defines what it will do and then builds the underlying structure and code to make that thing happen.

Having devs in a requirements meeting to explain how difficult some task might be can often prevent you having to work the next 12 weekends in row and 14 hours days for weeks on end to meet a deadline designed around the idea that this was something easy to do.

You also get to ask questions abut the less common paths through the software. For instance, they say they want to institute an approval process and then define how that works. I have never seen a group of non-programmers define what to do in that process if the approval is turned down, yet most competent devs will need to know that has to be defined because every dev knows that when you have an IF branch, you should be handling more than one case.

From a career perspective it is important for you to actively particulate as well. The people in these meetings are often the people who have input into raises and promotions and bonuses. You want them to have a good impression of your professionalism and your technical ability based on the things you bring up. Remember most of these people will never see a line of code and they are part of the process that allocated limited budgets for pay and bonuses. The only thing they will know about you is what they learned in these meetings and any emails you send and anything they hear about you.

If they only thing they heard was you built the part of the project where there was a bug they found painful (but you saw as minor because it took minutes to fix) then they will think you are incompetent if they have no other way to judge. They have no basis for determining how good a dev you are except these meetings and any issue that gets escalated. Don't make the escalations be the only thing they know about you.

Answer 3

The developer's role in these meetings is what you make of it. It can be insight into customer preferences and requirements (if you have them), insight into costs and tradeoffs of proposals, and so on.

If you have opinions, or questions, you can go ahead and voice them; that's why you're there. It may be safer to voice opinions as questions ("this may be obvious, but have we considered..."). If you aren't sure you can get away with that, you can certainly give your team lead feedback after the meeting and ask whether you should have brought it up at the time.

Even if you aren't headed toward technical lead or management any time soon (or ever), it's useful to have some exposure to and understanding of the business planning process. And it's sometimes helpful for them to have someone around who isn't yet infected with group-think and can ask the questions they've been ignoring.

Answer 4

I think for the first meeting or so, it was smart to take notes and remain quiet. You should know how things work. It's better to remain quiet and people think you don't know what is going on, than to open your mouth and prove it.

Taking your boss's feedback into consideration, if you have a comment, recommendation don't hesitate. Definitely ask questions to help your understanding.

Hold a separate meeting with other team members who may or may not attend, so you are all on the same page. You don't want to be contradicting each other in the meeting nor do you want to have to return to the next meeting and withdraw an incorrect recommendation that could have been avoided by consulting your team initially. This is what your team is for.

This is a great opportunity to have a voice in the project and some control over the requirements and expectations. Often some would will suggest a "nice to have" feature and by the time it reaches the development team it turns into "If we don't implement this immediately, everyone is fired." You can be a great service to the team by being involved in these meetings.

Answer 5

Many managers in my country (aka business analyst) think developers should stay coding and never participate to those kind of meeting because talking to the final client is a privilege of the "leaders". Ok I am exaggerating a bit but this is the idea.

However I have experienced that knowing the stakes and expectations from the client directly (and not repeated, deformed by your managers) help us a lot to define our priority in our effort to build quality software for them. Moreover knowing what the client needs from a final user point of view and having even a glimpse of the business practice is crucial to deliver the right technical parts of a projects expected from the client.

Lastly I have always found rewarding to feel involved in the construction of a software solution from the analysis to the definition. Even better when you know the person who will use the piece of software your are working on makes a lot of difference in the end because you end up feeling obliged to deliver the best you can.

I have found on several occasions the client asking questions to the developer attending the meeting. The client knows that developers don't lie when they ask them about the feasibility and the cost of a feature so that in some way if your manager wants to hide the truth they should not invite you ...

Answer 6

As a developer, with possibly considerable intelligence, and possibly considerable experience implementing what is given to you, you probably know better than anyone else what the cost of some decisions will be. For example, if the client says "A would be Ok if we can't get B, but B would be nicer to have", then you might be able to say that the cost of A and B is the same or almost the same, or B would actually be cheaper (making everyone happy), or B would be very difficult and costly to implement (and the customer could get a lot more benefit if the time and money is spent elsewhere).

As a developer, you know everything about workflows, and you can tell which suggested workflows just won't work. You know where a suggested workflow contains an unmentioned step "read the user's mind".

As a developer, you know when you get requirements that you just know are going to change and produce unnecessary work, and you just know which people are going to change their mind.

Of course if some manager thinks he or she knows it all and you are just a stupid coder that shouldn't be listened to, that's their problem (you keep your CV up to date).