In a team practicing Domain Driven Design, should the whole team participate in Stakeholder meetings?

In my experience, a Software Development Team that comprises:

1 Project Manager
1 Tech Lead
1 – 2 Senior Dev
2 – 3 Junior Dev (Fresh grad)

Only the Tech Lead & PM (and/or Senor Dev/s) will participate in a meeting with Clients, Domain Experts, Client’s technical resource.

I can think of the ff potential pitfalls:

Important info gets lost
1. Human error (TL/PM might forgot to disseminate info due to pressure or plain human error)
2. Non-verbal info (maybe a presentation using a diagram presented by Domain Expert)
Maintaining Ubiquitous language is harder to build since not all team members get to hear the non-dev persons
Potential of creative minds are not fully realized (Personally, I am more motivated to think/explore when I am involved with these important meetings)

Advantages of this approach:

Only one point of contact
Less time spent on meetings?

Honestly, I am biased & against this approach. I would like to hear your opinions. Is this how you do it in your team?

I don’t think it’s about the role, but it’s a lot about the attitude. In a perfect scenario I would try to have all the relevant person in the same room to actively discuss about the model. But in a perfect scenario I beed to have a suitable available room, with the required tools and people disciplined enough to manage this conversation. It isn’t that easy.

For creative collaboration to effectively happen, a weird non-technical thing called alchemy is probably requirement number one. The Domain Expert is the most important source of information (though not the only one) and he should be at ease with exploring the model together with the team, or part of it. If meetings are too long, too boring or meaningless, attention is lost, and we’ve missed our goal. Also, some developers might not have the right attitude to participate in this meeting. A facilitator role, to prevent conversation from becoming too technical, might be useful.

The whole goal is a deep shared understanding of the domain. This won’t happen if there is a layer between the DE and the team. But if the meeting is unpleasant, it won’t happen either. So my rule of thumb is “bring people willing to participate, unless this is making the meeting meaningless”. According to the starting point this might be a process of gradual insertion of more people, starting from the ones that want to participate.

Also, the right type of Domain Expert (the one that knows the answers to the why questions) might not be so easily available. So having a big meeting when everybody is present is probably less efficient than having a smaller meeting sooner.

Several years ago I have worked in a place where it was usual to put whole teams into meetings, just for the sake not to exclude anyone. Now, for almost ten years I work in a place where only those persons meet who really need to discuss things together, and other team members are only invited occasionally (and not for the whole meeting) to discussions about topics which are directly related to their work.

From that experience, I can tell you that the second approach is much more efficient. However, it works so well because everyone can ask questions to our domain experts whenever a question arises, independently of any formal meeting.

I also recomend to have a look into Steve Maguire’s book “Debugging the Development Process”. He describes that one important step in improving the efficiency of a development team is to keep them away from unneccessary distractions like needless meetings. From my own experience, I can confirm this 100%

Domain modelling sessions abide by the same rules as any meeting – the more active participants, the messier the meeting. In my experience, you can’t have a really focused and productive design session with more than one domain expert and one or two developers.

However, as you point out, the whole team needs a shared knowledge of the domain. This is where Agile planning and estimation meetings shine as a complement to smaller domain modelling sessions. Some time ahead of the start of a release, the domain expert will explain a group of features to all the team members using the ubiquitous language that took form during previous domain modelling sessions. Team members can give their feedback and propose new ideas, adjusting and enriching the ubiquitous language. Just before the start of an iteration, the whole team will again examine a subset of these features, re-estimate them and break them down into tasks, with the opportunity to make final adjustments to domain details.

The ubiquitous language and model pertaining to a feature or a set of features must go through several stages of refinement before they are ready to be implemented. These stages involve different people at different times. You don’t have just one big bang meeting where everything is decided about the domain.

There is one problem with composition of your team: Domain experts are not part of the team.

One of the key points of DDD is to include Domain Experts in team to ensure better collaboration and emergence of ubiquitous language. Of course, they don’t need to work full-time for team, there probably wont be enough work for them here. But, they need to be available at any time for developers to ask questions and clarifications. This approach has all the advantages and none of the disadvantages.

Only problem is how to get client to “lend” you the domain experts while they are not really your employees. But I’m sure there are some HR ways to make this easy and simple.

Let responsibility and authority be your guide. If someone has responsibility or authority to make decisions, and the subject of those decisions is discussed, they should probably be at the meeting.

However, Fred Brooks talks about the Design of Design and compares and contrasts several things that were made by committee with things that were made by great software visionaries.

It will depend on the project scope and the meeting agenda.

For all initial design meetings it might be waste of time to involve all team members, as some of this discussion would be really high topics for them. Instead, they may get simplified and easy to understand technical descriptions from Team Lead.

In addition, some of the decision made in that meeting might not seem logical for all developers. As each decision may take into account some non-technical considerations which are not openly discussed due to million of other reasons (company policy, confidentiality, etc.).

Filed under: softwareengineering - @ 02:25

Thẻ: agile, development-process, domain-driven-design, meetings, project-management

Thiết kế website giá rẻ

Danh mục

In a team practicing Domain Driven Design, should the whole team participate in Stakeholder meetings?