Software design meeting procedures

Question

Elements of my team and myself are experiencing some difficulty performing design meetings. The symptoms are:

1. We get off track easily, a combination of low understanding of the content of the system and want for the solution to be your solution drives the conversation often.
2. We are unable to come to an acceptable conclusion. Often the developers and the system architect have issues due to the involvement of the architect in the low level design.
3. In-ability to stick to a top-down approach, often going into depth of components before the high level design is completed. I believe this is due to a significant difference of design thinking by the members of the meeting.

I believe the solution to these problems is in better understanding of a design approach. What i am interested in is:

1. Suggestions for improvements, but more so
2. A good way to conduct software design meetings between the implementers and the software architect, from literature that can be read by all.
3. A technique or guide how to best approach design (not architecture, but the steps between High level design and class diagrams), so that the developers and architect can take a common approach to design. Ideally a quote from readable distributable reputable literature is ideal, again so it can be read and agreed by all.

Answer 1

Some things you may wish to try to improve the situation

Agenda

Have a set list of topics you need to discuss and limit yourself to these (at least initially).

Timebox discussions

Timebox each agenda item. If it is looking like it will run over, take it offline or bump it to another meeting.

Limit attendees

You can stop discussions getting out of hand my limiting the number of attendees or splitting the design session into multiple meetings. If you can get the attendees to think about the agenda items beforehand, it will grease the wheels.

Schedule

Accept that design meetings could cover multiple sessions. Consider when best to schedule meetings to get the best out the attendees.

Make progress where possible

If an agenda item is becoming blocked, feel free to park it and move onto an item where consensus is likely. The meeting is likely to be be viewed more positively for all parties if some progress has been made.

Limit available options

If a design feature is moot, limit the available options. Even if you can't do this, you may be able to at least rule some options out (from experience in previous projects).

Answer 2

The problems you are experiencing are primarily workplace issues, however I believe they are rooted in problems the roles people play in the software enginering process. A possible lack of a role (business analysis) might help out as well.

We get off track easily, a combination of low understanding of the content of the system ...

This may indicate you need a business analysis, or someone to gather requirements and understand the problems the client is having, and how software can solve those problems.

... and want for the solution to be your solution drives the conversation often.

This is a people problem, which is off topic for this site.

We are unable to come to an acceptable conclusion. Often the developers and the system architect have issues due to the involvement of the architect in the low level design.

While this might be a "people problem" it does relate to software engineering in particular. The architect should make decisions like "this will be a web application" and "we will use a relational database" and "it will utilize micro-services".

Decisions about low level components should be delegated to the lead developer in the engineering team. Separation of duties, would be a term that applies here.

In-ability to stick to a top-down approach, often going into depth of components before the high level design is completed. I believe this is due to a significant difference of design thinking by the members of the meeting.

This is likely because of people "going into depth of components before the high level design is completed." The high level design needs to be completed, before thinking about the lower layers.

Answer 3

Don't invite people who shouldn't be at the meeting.

For example, the architect shouldn't even be present when low-level design is being discussed. Only invite people who understand the system well, at the level being discussed in that meeting.

Don't try to do architecture, high-level design and low-level design all in one huge meeting.

Design it top down. In separate meetings. Don't even think about low-level design until you've decided what the thing is meant to do.

Answer 4

In addition to @Robbie Dee answer,

For point 1

Share the agenda with the relevant stake holders in advance and have them ready with their home work/questions.

If the discussion going off track, park it to be taken offline with sub group involved in off tracking. Example would be developer and architect not agreeing on particular design points. Let those people come to consensus on their own offline or separate meeting. This would help you to achieve your agenda for that particular meeting and forking topic level groups to build consensus.

If these things happen every now and then figure out the weaknesses (technical/soft skill) in the team that lead to the off tacking and address those.

For point 2: Accept software development is not like assembly line, where one person does something and other take over. Entire team need to be involved in every process so that they had better grasp of things.

For point 3: You already mentioned in point 1 "limited knowledge of system content". Team is going in depth because they do not have faith in high level design (due to limited knowledge of system content) and they want to validate the design immediately by digging deep. To address this have the Architect deliver High level design, assign the components to developers/leads to design and review as per HLD before the meeting. Only time boxed review happen in meeting.