6

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.
Fantastic Mr Fox
  • 171
  • 6
  • Seems like you want to know about [Software Architecture versus Software Design](https://stackoverflow.com/questions/704855/software-design-vs-software-architecture). – Greg Burghardt Oct 29 '18 at 13:46
  • 3
    These look more like symptoms of badly-run meetings in general than specifically software engineering issues. Do your meetings have (a) an effective chairperson; (b) agendas (c) objectives (d) *etc* – High Performance Mark Oct 29 '18 at 13:46
  • Another good read: [Software architecture vs System architecture vs Class diagrams?](https://softwareengineering.stackexchange.com/q/343643/118878). Basically the architect should be concerned with the architecture, and the engineering team should be concerned with software design (system design is another term for this as well). – Greg Burghardt Oct 29 '18 at 13:48
  • 2
    It might be a good idea to edit your question and remove the requests for literature or documentation, as these kinds of questions are off topic for this site. – Greg Burghardt Oct 29 '18 at 14:00
  • 1
    There needs to be an organizer, someone who can sort of listen and keep the topic on track but not actively participate. They can interrupt at any time and keep topic relevant, because otherwise the rabbit hole is deep. If anything, the organizer can decide that the topic, while off topic, still merits its own meeting. – Neil Oct 29 '18 at 14:37
  • "Elements of my team", why do you choose to refer to your teammates as inanimate objects? – whatsisname Oct 29 '18 at 15:44
  • 4
    @whatsisname. An [element](https://www.dictionary.com/browse/element) of the team means a part of the team (part of the whole). 3 of us are having the problem out of the 8 members of the team. This is simply an elegant to say some of the people in the team. Why do you choose to pick out a part of a question that is clearly an attempt to improve team relations and is not incorrect and make a point of it? If you have input answer the question, don't attempt to infer information about my teams relationships by the use of one word in a text based article ... – Fantastic Mr Fox Oct 29 '18 at 16:08

4 Answers4

6

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).

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • Some of the best meetings in which I've participated used time boxes and a large timer that everyone could see. – Dan Wilson Oct 29 '18 at 14:58
0

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.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
0

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.

Simon B
  • 9,167
  • 4
  • 26
  • 33
0

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.

Harvinder
  • 21
  • 1