24

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


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


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

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


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


1

You do not indicate any interventions already attempted and if those interventions failed. Sit employee down and set firm expectations on a firm timeline, known as a performance improvement plan. If employee fails to meet those expectations in that timeline, replace employee with another. Since this is a project, you do not need to invest a ton of time ...


1

This is a great question! Structure your team around Services or Value Streams. Analyze where the demand comes from (both external and internal) to make sure you fit for purpose and not for resource utilization. Then there are details like creating a pull system, instead of "assigning" work to people, limiting Work In Progress, etc. ultimately ...


1

I would recommend asking the team. They will have a good idea on what kinds of structure is suitable and by being included in the decision making process will be more likely to buy-in to the chosen approach. It would also be worth running the proposed structure as an experiment. Work out how you will measure success and review how things have gone after a ...


1

I was on a PMI agile course last week where the instructor recommended that teams should ideally 4 people in size and no more than 8. The reason for this is because the number of communication channels increase with an increase in team size and communication becomes more complex. You would be able to divide team sizes into 4 teams of 4 there you have a ...


1

The term Product Owner is usually associated with Scrum but it sounds like you are not actually taking a Scrum-like approach and the "ideal" role you are describing doesn't sound particularly like a Scrum PO. Small cross-functional and self-organising teams are usually the best way to deliver a software development project. Between five and ten ...


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