What to do when the team prefers private communications on mail and chat over collaborative tools like Jira?
You're conflating collaboration with transparency. They're two different things. Your team is collaborating. What you're really asking about is how to make the results (if any) of that collaboration visible.
Use your ticketing system for ticket management and progress reporting. Don't try to repurpose it as a communications tool, which it is not what it was designed to do even if a particular system has some limited comment or email features bolted on.
Analysis and Recommendations
Communications and Collaboration
As a ticketing tool, jira is absolutely not an effective method of intra-team communication. The Twelve Principles Behind the Agile Manifesto clearly states a few key things (emphasis mine):
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
You should trust the team to be collaborating together effectively. Unless there's a clear dysfunction in their collaboration, you should be supporting their collaboration rather than trying to micromanage how they do so.
This doesn't preclude you requesting that the team members make useful results visible to the rest of the team using whatever information radiators are most effective. However, it still differentiates between the collaboration itself and the visibility or dispersion of useful information that may result from the collaboration.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is true prima facie, but it doesn't mean that other forms of conveying information lack all value. However, there's generally a hierarchy that needs to be adjusted for your working environment.
Face-to-face provides the highest level of interpersonal communications bandwidth. That's not always practical for non-colocated teams, or for teams with neurodiverse team members, so you can make trade-offs here. In roughly descending order, communications bandwidth still has value when videoconferencing, on the phone, real-time chat, asynchronous chat, code comments/issues, email, and (deliberately dead last) ticketing. For intra-team communication and collaboration, support whichever options give the most bandwidth without preventing the team from collaborating in the ways that they find most effective.
Visibility and Information Radiators
Your real issue seems to be either:
- As the Scrum Master you don't have visibility into the content or outcome of the collaboration.
- The Scrum Team doesn't have visibility into the content or outcome of the collaboration.
The a priori assumption seems to be that Jira is the best place for this information to be made accessible to the rest of the team, but that's not necessarily the case. It's a faulty assumption.
The real questions you should be asking are:
Do these collaborations have any impact to anyone but the collabaorators themselves?
Assuming the software development domain, pair programming is a great example here. Tight communication makes for better pairing, but no one else on the team needs to be a party to the ongoing conversations. They just need to be aware of material changes to the code base, especially if they will need to rebase ongoing work-in-progress on top of changes merged to the integration branch.
From a Scrum perspective, you don't need to report the minutes from every casual conversation or even deliberate collaboration that takes place. The only thing that needs to happen is that the Scrum Team as a whole feels like they're coordinating effectively.
What should happen when collaboration results in action items or material information for the whole team?
Action items should be placed on the Sprint Backlog, or possibly handed to the Product Owner as future Product Backlog work. Other information that affects current product development should be automated by your source code management (SCM) system, team wiki, or your ticketing system when changes are made.
In other words, use your SCM, Jira, or other information radiator to inform the rest of the team when something in the environment that matters to the team has changed. This could be part of the definition-of-done for user-stories or features, or communicated during the daily-scrum.
What's your interest in the details of the conversation as a scrum-master?
The role of Scrum Master has certain key accountabilities, but taking minutes or structuring every working collaboration isn't among them. Unless there's clear dysfunction, or you're addressing issues brought up in a Sprint Retrospective, you're doing more harm than good in trying to dictate how the team communicates and collaborates while building the Increments that achieve a Sprint Goal.
Not every meeting or conversation is of interest to the whole team. Trying to account for all time spent in meetings, conversations, or collaboration is also a Scrum anti-pattern. So ultimately, unless this is creating information silos within the team, you should absolutely butt out on this issue.
If material information is not being disseminated or routinely preventing the team from meeting Sprint Goals, then of course you should bring this up in a Sprint Retrospective. You should then collaborate with the team to identify a better way to share out decisions, action items, and material changes that might impact the team or the current Product Goal.
In short, your objective should be to let the team do whatever works best for them so long as Sprint Goals are being met. How they are being met is up to the self-managing members of the Scrum Team as a whole, so unless this is causing some kind of pragmatic problem for you as the Scrum Master or for the project itself, there's absolutely no upside in trying to funnel communications through a ticketing system. There are, however, many downsides to that approach.
Use your ticketing system for ticket management and progress reporting. If you need additional tracking, discuss it with the rest of the team. However, under no circumstances should you ever replace direct interpersonal communications with ticket-status updates.