In an Agile Software Development a tight collaboration of a Cross-Functional Team is desired.

Tight collaboration is reachable by transparent communication. Decisions must be made by Dev-Team (Development Team) itself. Better decisions can be made when all developers live the Collective Code Ownership by using Pair Programming and everybody has the same knowledge base.

In a Cross-Functional Team you have mostly specialized persons for several concerns (Testing, Backend, Frontend, Integration, etc.), most of them have mostly different skill levels (junior, senior, etc.). Team members also have different experience in the project, for instance, new team members often have problems to get into the domain and passed architecture decisions as we know any documention is missing or not up-to-date. Another point is that bigger teams have more trouble than smaller teams to communicate every important issue.

That leads to following questions...

• How to improve collaboration and Collective Code Ownership in a huge or small Cross-Functional Team?
• How to allocate different skill levels and knowledge base to each team member?
• How to share passed decisions and concepts?
• How to improve all of them without influencing the daily work and progress?

Rollout

I think a lot of teams use agile methods, as described in Scrum. For instance, you use the important Retrospective Meeting to inspect your daily work and improve it by discovering and removing impediments. I think you also use Planning Meeting to discuss the requirement. Maybe you already use Pair Programming for sharing domain and application knowledge.

Those are really good techniques but all of them are subject to the project!

Dev-Meeting is subject to the Dev-Team!

A Dev-Meeting (Developer Meeting) is primarily used for discussions about offside topics out of requirements and project. That means team members will basically share their knowledge each other, such as Best Practices, Principles, Patterns, Paradigms, Tools and so on. It's also possible to share news about the IT-World in general. In other words, developers will share everything which is valuable to become a better developer.

Typical statements in a Dev-Meeting are...

• "I listened to an interested Podcast about NoSQL, maybe we can adapt the approach to our application..."
• "Have you ever heard about Law of Demeter?"
• "I wanna suggest you to use a dark theme in your IDE, because..."
• "Did you know next PHP-Conference is in our city?"
• "I wanna introduce you to Acyclic Dependencies Principle."

A Dev-Meeting is a very good place to know each other better, especially for new team members. Pulling knowledge is the standard approach in daily work, but not in a Dev-Meeting. There is the basic condition of pushing knowledge.

Please consider that the project is really important for the management, if necessary it'll be appreciated to use it for issues related to the project as well, like follow-ups of plannings or any reviews, but don't lose the focus to the team.

Carry out

Like other meetings a Dev-Meeting has to be time boxed. According to team size, the meeting should be lasted one or two hours every week. Each meeting must have an agenda with ordered topics. As for transparency, you should record it to have the possibility for review. Having great history of passed meetings is a great benefit for new members. New team members can read it to get into the team flow directly.
Each developer of the team has to participate, other people as viewer can participate too. A dedicated moderator is unnecessary, as the Dev-Team has to be self-educated, however in case of start up difficulties, feel free to invite an experienced moderator to join. It's preferred to meet in a closed room with obligatory presentation equipment.

Consider that the Dev-Team contains different personalities and each of them has different skill levels, thus, respectful treatment, empathy as well as courage are required for an effective meeting. An open-mined communication is highly recommended, for instance, don't prejudice against others' opinions, support introvert people to participate actively.

Attempt to figure out multi-perspective of any issue and topic. Principle of Multiple Perspective is an awesome tool for problem solving, which also ends up in great creativity.

Try also Learning by Teaching. Just create a list of topics (e.g. OOP-Principles) which is extendable by each team member. One or two team-members can subscribe for one topic, after preparation they give a talk on it. From my point of view Learning by Teaching is one of the best techniques to reach a higher level, especially for the teaching guy.

Furthermore, it doesn't matter about agenda, the discussion should be avoided aborting. Finalizing discussion is really important, otherwise, participant will have more questions than before, which will lose credibility of the Dev-Meeting idea. Just postpone topics from the agenda to the next Dev-Meeting.

Outcome

Firstly, the result of periodical Dev-Meeting is a fast harmonization of skill levels and knowledge base from developer to developer, as well as cross-functionality is growing. That is a really big benefit not only for the developer, but also the project will have a positive revenue (As we know, how expensive a meeting can be). Also social skills will be improved. A lot of developers are really good in coding, but sometimes they have problems to describe their used patterns. All discussions and talks inside the Dev-Meeting force an open mindset, courage and Ubiquitous Language in technical context, so that tackle also nomenclature problems. Harmonization leads to make the right decisions effectively, the Dev-Team will perform more and more agile.

Secondarly, the project is more immune against team fluctuation. I discovered that new team members can participate on the general workflow quickly. I also noticed that Dev-Meetings are really widely used by developers, who will be more committed to the team and will be contributed in a more convinced way. Successful teams are mostly those teams where people shares meaningful relationships besides technical knowledge.

Pair Programming and Code Review will be easier, planning and daily work will be more effective. Besides that, records of Dev-Meetings provides you a great documentation about passed learnings, decisions and concepts. It can be used as a timeline.

So, i have to suggest to establish the Dev-Meeting into your approach as an additional agile method. But don't mix it with the Retrospective Meeting, also don't replace the Retrospective Meeting by it, just add the Dev-Meeting next to the Retrospective Meeting.