27

It sounds like you have team members from high power distance cultures. People may not speak up when the boss is in the room because their values require them to listen and follow, not to advise or lead. You may even notice it happening between junior and senior team members or between yourself and team members. Read more about power distance here: https://...


15

Analysis There is a chilling effect when he is here. Am I overreacting? Should I just try to build up the confidence of the team? or should I ban my boss from the retrospective? In my experience, this is a classic case of missing the forest for the trees, and mistaking process problems for interpersonal ones. Let's enumerate some of the issues that ...


6

There are actually two questions here: What went wrong? From the short description, it seems that there has been no training but the person was just given the job title (maybe with a copy of the scrum guide). SM is a demanding role which has to be learned and which requires exquisite interpersonal skills, it's not just about holding ceremonies and pushing ...


5

The answer to this question depends a lot on the people in the team and on the boss. Normally, a Scrum team should not contain people with special roles, especially a boss. The balance of power gets messed up and you can kiss self-organization goodbye because a boss will have a tendency to decide on matters, and want to have the last word in various ...


4

Your problem isn't instant messaging. Instant messaging in a remote team is a substitute for talking in a local team. Trying to say that all verbal communication should adhere to maximum efficiency and never saying anything unnecessary is... rather silly. But. It's equally silly for people to be constantly pinging each other (verbally or otherwise) about the ...


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 ...


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 ...


3

If the presence of any team member is reducing the performance and productivity of any activity, remove the problem. To expand on my answer a bit: a chilling effect brought on by a "superior" in the room is not uncommon. A lot of factors play a part in that, including the degree of "rank" gap between the boss and the team, cultural ...


3

I might suggest that talking about this at the retro might be in order. Retrospectives and the action items that come out of them are often focused on process and how to improve it. However, it can be easy to forget that retros are a part of the process as well, and it is worthwhile to tweak them if they're not working the way they should. Now, it may a ...


3

It's interesting that you are questioning the role of the SM but not the PM. There is no Project Manager role in Scrum and the PM shouldn't need to assign roles and tell an experienced team how to work. I would start by having a word with the PM and seeing if they are happy that the team should self-organize. If not then the PM is the real problem, not the ...


2

As a Scrum Master, the only time when I would look to ban somebody from a retrospective is if the team asked me to do it. My recommendation would be to first coach the team and the boss on the importance of making the retrospective a safe space. The team (or the boss) may then act of their own accord. If that doesn't help I would make the team's behaviour ...


2

This is a tough place to be in. You have an inexperienced Project Manager and an inexperienced Scrum Master. The team is also new to Scrum. Chances are that the team will follow the Scrum Guide mechanistically, because that's usually what happens when inexperienced people need to put something in practice which requires experience (and that's valid for a ...


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 ...


2

Self-checkup First of all, I would suggest you do a self-checkup. You seem to be handling a lot of things all of a sudden. If you juggle with to much stuff, you will inevitably drop some on the floor. So first thing you need to do is to sit down with yourself and see how much you can realistically do, which are the things you need to handle, and which are ...


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 ...


2

This question isn't really about "too much instant message communication", but rather effective communication channels. A few things stand out. I'm not concerned by the fact that the team doesn't always monitor their email. Email shouldn't be used for time-sensitive communications. I think it's reasonable for most developers to check their email ...


1

This seems ideally suited to an experiment: Determine what value you are trying to get out of communicating as a team Find a way to quantify and measure it Run an experiment for a number of sprints Review if the new approach had the desired impact


1

Effectiveness of communication and volume of communication are not the same thing. It is possible to be swamped by too much communication, especially if it is of the wrong type. It is also possible to be distracted by too much communication, leading to breaks in concentration and consequent time wasted by re-doing work or correcting the errors that may creep ...


1

Instant message communication is a 'must' for a remote team Here is a chart showing the 'Richness of Communication Channel' prepared by Dr. Alistair Cockburn: The curve at the top shows communications that are interactive. Face-to-face communication at the whiteboard is the most effective. The curve below shows one-way communications. This chart is old. We ...


1

Try to use an email tracker, as it can clarify if the client has free time to respond. If this client continuously opens emails but doesn't respond it's a red flag that he/she isn't interested in a project. Try to send emails with questions. If a project scope has been specified I prefer to do it. In emails, I inform a client what is done, what will be done ...


1

Before you seek to change, first seek to understand. As you state (emphasis mine): But on the other hand I think the project manager is just doing his job. Maybe he is trained to do it that way. You're just guessing at this point. Why not meet with him and simply ask him outright why he sends out the report - what result he expects to receive from it. ...


1

Practice. It really doesn't matter what the topic is or if you're smarter than someone else or not. It's about practicing, explaining complex issues using simple, straight-forward language, using simple and everyday analogies, exhibiting patience, asking if they understand, and pivoting to another explanation strategy if you sense you're not getting ...


1

The correct answer to your question is "I don't know", but that's not very helpful. In the effort to be helpful, I'll provide an incomplete and potentially nonresponsive answer. Within the context of project management (I think a great deal of the reason why I don't know the answer is that your questions seems to scope far beyond project ...


1

I would propose - in addition to other methods - that you send around a weekly status report. It should have as paragraph headings the Team Name and then a few bullet points of what they recently achieved and what they plan on doing. The introductory section can highlight issues that will affect more than one team. Your example of shutting down functions ...


Only top voted, non community-wiki answers of a minimum length are eligible