Think about what the user wants (and not what’s fun to develop)

• Often times developers focus more on what’s fun from them, instead of priorities.
• This is especially true when uncertainty comes in. People look at problem from their own perspective.
• Therfor, always make sure you understand the problem the client is trying to solve.

Pitch fun to develop to clients

• Over the time the team gets to know the product better and better and might become “users” of the product to.
• Start from a POC and pitch a feature that is fun to developer, to generate new business and excitement for the team.

Async communication works better than you might first think

• Documentation when
  • Someone forgot something
  • Someone is sick/in another meeting
• Standup/status
  • If you - for some reason - cannot make it to the standup, you can still send what you are working on or thing you are stuck with and read the updates from others, to make sure you and nobody is blocked

Have an up-to-date ticket description

• Sometimes it’s not clear how to solve a bug or work on an issue. If that’s the case, the issue comment section is usually a great place to start asking a question. If the conversation turns into a Ping-Pong, where two or more people are constantly sending issues back-and-forth, get these people together. This can be in a chat room or a virtual hangout.
• After the hangout or chat, write down the essence of the conversation and post this into a less fleeting communication channel, such as the issue description.

Ask questions in public channels

• Instead of sending a DM to someone from the team, try to ask for help in a public channel. If the person you are asked help from is busy, someone else might jump into the conversation to help you
• Another benefit is that the answer become visible to the entire time. Say you run into a bug. Chances are someone else from the team might run into the same issue later. If it was posted in a public channel, the might have seen the issue and recognise immediately how to solve it. They can even search for their bug.

Do more meetings, but shorter and with preparation

• Nobody likes to sit still for one hour
• Do meeting of maximum half an hour
• Get people to prepare for the meeting
• For a retrospective meeting - explain the concept and get people to prepare for the meeting
  • The preparation can already begin at the start of the sprint - get the people on board with the retro that will happen in two weeks so they can prepare in advance: write down frustrations when they occur, take notes on success when things work smoothly

Write down responsibilities

• I worked with teams where some responsibilities were unclear. Who is responsible for what? When it comes to making technical decisions, who will gather pro’s and con’s and steer the team in the write direction?

Communicate your frustrations

• Sometimes people have different opinions, ways of working and/or ways of communicating thing. A frustrations might just occur when someone is having a bad day. However, if you feel like it’s hard to work together with someone, talk to that person about it. People have the tendency to talk to other about this. “Don’t you find X hard to work with?” - “Wow, X is having a bad day right?!” - “I cannot work with X anymore!”
• While talking to a third person can be good to get some more insight and get someone to listen to you, the best thing to do is think about what your frustration is about and tell that person about it. The sooner, the better - to avoid “well that escalated quickly” 😀

Take a deep breath

Mindfulness might not be for everyone, but by taking a deep breath you tell your body to relax. Try to find a moment to take a deep breath from time to time. Even better: make a habit. Since habits last longer when you connect them, try to link taking a deep breath to some actions you do (almost) every day. Before every standup, after every meeting, every time when you sit down or every time you stand up. Breath in … and breath out.

Take refactoring (and tech dept) into account

Sometimes a feature take longer than the team anticipated. This can get frustrated for everyone. It’s get’s more frustrating when - due to an incorrect estimate - there is no more time to refactor the new code. The developers will, from then on, have a hard time implementing new features.

Celebrate success

• The end of a successful sprint
• The launch of a product
• Fixing a bug after searching for x days
• Don’t forget to celebrate success, even when working remote. Get people excited.