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.
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.
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 💀.”).
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.
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:
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.
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.
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.
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:
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!
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.
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:
Product Backlog Items (PBIs) are the cornerstone of a well-oiled project. They track features, bugs, tasks, and much more. When a developer or Product Owner is looking through the backlog, it's important that - at a glance - they can read the titles of PBIs and have a decent understanding of them.
So what separates a good PBI title from a bad one?
There are many tools used to communicate and collaborate online. The most efficient platforms for chats and calls are:
The de facto approach of communicating via group emails and sharing files via a patchwork of different services is difficult, with the potential for missed messages and files.
To prevent downtime while waiting for a response from a client, or the topic in an email needs to be discussed immediately (e.g. a bug), you should always call first before emailing.
A disproportionate amount of time is spent thinking about whether you got the right answers from the client (or in the software world "Did we get the right specs?"). However, asking the right questions is a very important part of this process.
During meetings, there is a lot of communication between you and the client. It is very hard to keep the entire conversation in your head; hence it is very important you take notes. Notes must be short but descriptive enough so that you can remember what the conversation was all about and what tasks were created during the meeting.
It is also very important that you use appropriate tools e.g. Microsoft Loop, Microsoft OneNote, Trello, Microsoft Word etc and avoid tools like Notepad.
As businesses become larger and more complex, it's harder for the decision makers to keep up to date with every product change or be in every meeting. Responsibilities for decision making cannot be delegated but gathering the information to make an informed decision can.
One common tactic is to have a delegate attend the meeting on their behalf and then loop them in at the end, bringing them up to date with an executive summary.
Here are some tips to doing this effectively:
Throughout your career, you might come across a scenario that feels unfair. In these situations, communication is vital for resolving conflict and making all parties feel content with the result. Let's take a look at some scenarios that may be perceived as unfair:
When communicating with others, it is important to match the tone of your voice with your intent. The way you deliver your message can significantly impact how it is received. A well-matched tone ensures clarity, understanding, and strengthens relationships, allowing your true intentions to shine through effectively.
This is extra important for consultants - we need to make sure our clients trust us and feel confident in the solutions we provide.
The word "but" often sounds negative and creates friction—even when you're agreeing. Phrases like "Yes, but...” can come across as dismissive, subtly negating what was just said. This can make the other person feel unheard or contradicted.
Instead, try using "Yes, and..." to acknowledge the previous point and build upon it. This approach encourages collaboration and keeps conversations constructive.