Rules to Better Communication

What we've got here is failure to communicate! – Cool Hand Luke

So many problems in business come down to a lack of clear and effective communication. Here is a series of communication rules that should give you an edge.

  1. Sometimes you can't complete a task right away or anytime soon. People might just say: "I can't do it this week, but I should have it done by the end of next week".

    Another scenario is when the task should be done or will expire after a period of time. For example "Send Google Analytics data after a month" or "Remove course banner once the course is completed".

    If you leave it like that there is a high chance it gets forgotten as remembering tasks is a highly unreliable method.

    Efficient people don't rely on their memory and instead, use some way to make sure they don't forget to do that task. Common ways are to make a note in a paper diary or stick a post-it note to a screen, but there are better ways.

  2. It can be very jarring when somebody is called out of the blue and they are not expecting it. They might be deep in a task or talking to a client and by calling them their focus is getting disrupted.

    Before calling someone, be sure not to just say 'hello'.

    A good way to initiate a call is to warm them up by giving a warning (e.g. “Calling you in 1 min to talk about the Northwind production site being down 💀.”).

  3. Things move fast at work, so staying on top of your tasks is key. With Microsoft Loop right in your Teams tab, you can easily keep track of what you’re doing and update your manager whenever needed.

  4. When collaborating within teams, the current process involves soliciting individual updates or feedback, with one team member responsible for manually compiling this information. Unfortunately, this method presents several challenges:

    • The need for manual compilation of feedback/updates
    • Time-consuming process
    • The individual providing the original feedback must verify it, as it has been consolidated into a single file
    • Any subsequent updates may necessitate the creation of a new version (v2) of the compiled file

    Fortunately, Microsoft Loop offers a solution by introducing interactive notes shared seamlessly across all Microsoft 365 products. This addresses the challenges by eliminating the need for manual compilation, streamlining the process, and ensuring that updates are instantly accessible to all stakeholders.

  5. Often when you are talking with others, it is easy to forget they have a different background and experience to you. Then, once you start explaining something to them, they easily become lost. So, it is crucial to think about your audience before talking.

  6. Explaining problems can be really hard. Often, when you are trying to talk with someone about them, they get lost and frustrated because they don't fully understand the context.

    That's why it is crucial to start at a fully zoomed out level and slowly zoom in with your audience.

  7. Ideally, you should point out any problems with a work item when you are first assigned it in Sprint Planning. However, sometimes you think a PBI will be fine, but then you run into blocking issues during the Sprint. In that case, you shouldn't wait until the next Sprint Planning because that is burnt time being blocked. So, you are forced to do some googling, and investigation on how to move forward. These moments can be stressful, especially for junior developers and the question arises... "When should I ask for help?"

    Asking for help should follow 4 phases:

    1. Determine if it's time to ask
    2. Do your due diligence
    3. Figure out who to ask
    4. Prepare to talk to a senior
  8. Work items often have a great description and Acceptance Criteria. However, work can change quickly; sometimes, the justification for those changes ends up in emails or instant messages.

    If decisions and discoveries aren't in a central location, it can cause significant pain down the line. For example, if a new developer starts working on a work item, they might get halfway through the task only to find out their work has been wasted due to side conversations in emails. Therefore, when the requirements of a Work Item change or critical information is found, these details should be accessible to everyone on the Scrum team.

    That's why the discussion section of a work item rocks!

  9. It is very common that a developer looks at a PBI to work on, and finds out that it has limited or missing information. Usually, this is due to unclear requirements, ambiguous instructions or people simply don't understand the importance of getting the right information in the PBI.

    When that happens, it is crucial for the developer to raise their voice and gather enough information so it meets the Definition of Ready. Additionally, anyone working on the task who doesn't fully understand should raise the problem ASAP.

  10. Explaining work can be hard. When you are presenting in a Sprint Review, it is difficult to gauge exactly what information to give to the Product Owner and how to deliver it.

    As a developer, it might be super exciting to talk about all the technical details and start explaining those aspects. However, the Product Owner probably cares more about the business value. So when you are talking about the technical parts they may get lost or simply think you are wasting their time.

    Luckily, there are a few tips and tricks you can use to make sure you are ready to show the Product Owner your work:

per page
1 - 10 of 27 items
We open source.Loving SSW Rules? Star us on GitHub. Star