2

I've noticed that a lot of discussion between a developer and a Product Owner happens in private conversations in various communication tools (Skype, Slack, email, etc). The reason is because these tools are more convenient for communication than Jira.

  1. a lot details is hidden from the rest of the team
  2. it is difficult to find these details in message history
  3. these details are not reflected in Jira

Are there any good practices to avoid this?

1
  • 1
    Took a stab to make the question summary a bit more specific. Feel free to revert it if that doesn't express what you wanted to convey.
    – Tiago Cardoso
    Nov 21, 2020 at 19:58

5 Answers 5

3

From Agile manifesto:

Individuals and interactions over processes and tools

Your objective is NOT to avoid communication. You want to promote it. People in a project must communicate in the most effective way they see fit. I believe you should shift the focus of your energy, changing the question you're looking for answers to questions such as

  • How can we as a team effectively make sure information is available about any conversation?
  • Where such information could be available?
  • Why do I need to write down the outcomes of team conversations?

These questions might help you fine tune the specific needs for your context. There's no canonical answer as it heavily depends on your environment.

Environment #1: Junior team, low confidence between parts, time zone differences. You still want to keep conversations flowing, but you want to have it written somewhere for future reference. Each conversation might be related to a specific ticket, so the outcomes of this conversation could be summarised as a jira comment. Special attention to outcomes and summarised. You definitely do not want transcripts of conversations (as I saw someone doing some years ago).

Environment #2: Seasoned team, high confidence between members. On these cases, there's no better "communication" than working software. Nothing else needs to be written.

===

Remember: Everything that's not directly contributing to delivery, is a waste. Oftentimes, wastes are needed, but a team doesn't need to stick to them for the sake of the methodology. A methodology is just a mean, a tool for a purpose, not an objective in itself. Your focus should always be on the consistent delivery, not on consistent methodology usage.

2
  • Our team is seasoned (Environment #2) and still we find it inconvenient that pieces of information are scattered over different places and difficult to find.
    – Daniel
    Nov 22, 2020 at 8:32
  • There's no best written evidence of understanding a requirement than working software. If you need to refer to a specific piece of conversation from 6 months ago, something is off. Notice I'm focusing on "conversations", not on formal docs one may need. In any way, jira isn't the best place for "documentation" in any way.
    – Tiago Cardoso
    Nov 22, 2020 at 13:44
3

First and foremost, you can't use tools to solve this. If there is any problem here, it's a people problem and a communication problem. I say 'if' because this may be fine. Maybe it's something that really only effects them. Or maybe they are, after their 1-on-1, sharing the info with the right people.

If you are seeing impacts where info isn't being shared from those conversations and it's impacting how the team works, my best recommendation would be to raise those impacts at the retro and then as a team, discuss how you'd like to work differently to avoid those impacts. If they are using other tools instead of Jira, maybe Jira is a poor tool for that communication, but other options exist, like having the slack conversation in the team chat instead of 1-on-1. I'm confident the team can find the solution that works well for them, makes communication easy, and avoids accidental side-effects.

2

Jira is not a communication tool, but that doesn't mean you can't add information gained elsewhere to a ticket.

If something is unclear in the ticket description, by all means ask around until you understand it, and then come back and update the ticket description. If your conversation unearths missing acceptance criteria or a link that would be relevant to anyone who implements (or just looks at) a task, go ahead and add it.

Note that while you can use comments to have a conversation inside a Jira ticket, a long comment thread can easily get out of hand. It's also easier for comments to go out of date than a description (which can be updated by anyone). Comments are a good way to get someone's attention, though, and to get specific questions answered, for example when you need more details about a task or bug report.

2
  • Who should update Jira? Do you think that Scram Master should oversee all the conversations that happen and keep summarising them in Jira?
    – Daniel
    Nov 22, 2020 at 8:37
  • @Daniel Anyone can update Jira tickets. If for some reason team members lack permissions to do that, maybe the Scrum master can help them in getting these permissions. Otherwise, it's the team's jobs to make sure the tickets are up to date.
    – Llewellyn
    Nov 22, 2020 at 17:35
2

Tiago's answer and Llewellyn's answer both give good perspectives on the overall approach. However, I'd take a slightly different approach.

Since Jira tends to be more accessible than an individual's email inbox and private Slack channels or DMs, I tend to think of Jira as the source of truth and use integrations to allow people to push content into Jira when it's appropriate.

What you should consider is a way to get information out of these other tools and into Jira. Fortunately, Jira has integrations for email, Slack, Teams, and other tools that can help to either link content to the Jira ticket or get content attached to the Jira ticket as attachments or comments. The integrations with Slack, for example, allow people to receive issue notifications and make certain edits, including leaving comments, without leaving Slack. There are similar integrations for Gmail and Outlook as well as more generic emails to and from Jira.

2
  • To add the link to a message in Slack is not enough, because a dicussion consist of many messages. Someone need to summarise the dicussion and add the summary to Jira. But this takes time, efforts... Who should be doing this?
    – Daniel
    Nov 22, 2020 at 8:43
  • @Daniel I'm not suggesting just adding a link to a Slack message. Using the Jira/Slack integration, you can use Slack to create new issues, add comments to existing issues, and (I believe) transition the state of issues. You can also have notifications of changes pushed to individuals or channels to facilitate discussion about issues. As far as taking time and effort, if you have a pro Slack plan and hold discussions in more open Slack spaces, you don't need to summarize. You can just post a Slack URL as a comment in a Jira issue.
    – Thomas Owens
    Nov 22, 2020 at 11:22
0

TL;DR

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, 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:

  1. As the Scrum Master you don't have visibility into the content or outcome of the collaboration.
  2. 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 for or features, or communicated during the .

  • What's your interest in the details of the conversation as a ?

    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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.