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


18

Hat tip to Nvoigt, Nvogel & D. Espina - all good answers, with particular emphasis on D. Espina's "sometimes, knowing one of your team is overly optimistic, you simply add your own margins to their input." I'll just add one more frame to the question - this is a problem in risk management. The core, fundamental responsibility of the PM is to ...


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


15

In Scrum the team aims to complete the sprint goal by the end of the sprint. It shouldn't be necessary to estimate day-to-day deadlines since the delivery date is always the end of the sprint. I suggest you could stop trying to lead, stop estimating and allow the team to self-manage. A team of three people is quite small however, and one problem may be just ...


9

Group Discussions Don't Replace One-on-One Communications While there's a place for more leadership involvement, I certainly wouldn't replace one-on-ones with larger meetings. Especially in IT, this can be counter-productive for a number of reasons such as: IT often attracts introverts, who may not do well in larger meetings. Company leadership is often (...


8

Notwithstanding your approach and whether you are performing it properly, research the affects of planning fallacies. A planning fallacy is a specific form of Optimism Bias, where we have a tendency of under estimating adverse variables that could impact our performance and, therefore, we predict far favorable results than what is most likely. The bias ...


7

Stop Abusing Velocity I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated. So, you know the company is doing the wrong thing and following an anti-pattern, and yet you're expecting a different outcome. That isn't reasonable....


7

I'm sorry, but you are trying to solve the wrong problem. Your team isn't delivering much because your management has no expectations from them to do otherwise. There is a saying in my country that literally translated means "As you teach them so you have them". Management taught this team that nothing happens if they don't deliver much, taught ...


6

I have no academic backing on what I am going to write as my answer here but am drawing on my experience plus my own predicted reaction if I were a subordinate meeting with my boss and his/her boss. I can only imagine that the discussion would be a complete waste of time because the politics of such a dynamic would require all three of us to be on our most ...


6

Joel Spolsky once wrote: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right. ... A typical bad estimator has velocities all over the map.... Most estimators get the scale wrong but the relative estimates right. Everything takes ...


6

Looks like something custom, possibly borrowed from, or resembling Kanban. Kanban has two main principles: visualize work limit work in progress Anything else falls into how you want to organize things according to other Kanban principles. From what you mentioned: one big whiteboard could be a Kanban board (there is some common format for how a Kanban ...


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


5

Assuming that you are the Project Manager (otherwise, why would you post this to our site), you have no "right" to disclose this information to your team, since it was told to you in confidence. Your task as PjM is to ensure the project will be in a deliverable state by the "firing deadline" and that everything is well enough documented ...


5

I'd like add one more option on the table. In many cases estimation isn't really necessary. Situations when it can be useful: You need to sync with other teams which depend on you You need to predict the budget and decide if the project (or a feature) is worth starting In any case, if you estimate there has to be some decision made based on the estimates. ...


5

As you mentioned yourself, this is a difficult situation. There are a lot to say about it but I'll try to advise on some of the main points I see. Information You say you are new to the company. In two months you probably haven't gotten the full hang of things. And you now also have this situation you are asking about with conflict between team mates. Most ...


4

TL;DR A core skill for effective project management is being able to clearly communicate “we can’t get there from here” when it’s warranted. If you can’t or won’t do that, the problem is you. If you’re correctly doing that, the organization’s failures are no longer your responsibility, even though you may still get blamed for them. Analysis Your question ...


4

As I mentioned in the comment above, you and your manager/stand-in PO need to agree on the outcomes for this PoC. You need to define the goals of the implementation or you might risk working towards different targets. Also discuss what everyone's role will be in this. From the question it seems you want him to be a PO, while he wants you to be more involved ...


4

Sounds like Utopia Unfortunately, this process is unlikely to exist in the real world. Anyone can add tasks to the board Looks like all work is internally generated by the team. If this is a product, it will lack a unified vision. It will be worse than design by committee. It can't be Kanban because Kanban is typically for work originating from outside the ...


3

While not strictly a PjM question, and liable to be closed, the PjM aspect of the question is fascinating. A rule I was taught as PjM - that may just solve your problem - is: Solutions, not problems IOW: Nobody wants to hear about your problems, not even about the work you've put into solving them. People - managers in particular - want to hear about the ...


3

I am not aware of a process that explicitly discourages developers to pick their tasks. Instead, most agile frameworks encourage the use of self-organising teams. One aspect of being self-organising is that the team will decide how tasks are distributed amongst the team members. It would certainly be legitimate for a team to try a random or pseudo-random ...


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

Try to bring the work to you I would suggest to create a Kanban board for yourself and allow people the option to give you work. Have columns like: To do| In progress | ... | Done -----|-------------|-----|------ | | | You take work from the top of the "To do" column and you work on it. Once it's done or you have more ...


3

If you have teams that work on one project only, then you could keep them on Scrum iterations. If they can plan things out and do the work without depending too much on external resources (I'm thinking "you" here), then great, let them do so. From what I gather from your question, it seems that this is not the main issue, but the fact that you are ...


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

The answers here are good in that they emphasize transparency, setting expectations, testing deliverables, anticipating disengagement, problem anticipation, and tooling. However, I think integrating such strategies is also important. For instance, a transparent time tracking system can double as a means of communication while making sure they are working the ...


3

You ask: Is there a process that promotes the group to assign tasks to individual developers. The tasks should be assigned as part of a group decision and as part of what comes next. What you need to do is to explain to the team (those doing the picking) what you are aiming at. This may then encourage them to divide up the task as you expect. Once they ...


3

one team is waiting for another one Teams should be cross-functional! If you have one person working on the back-end and another person working on the front-end, make sure these people are on the same team! Make sure they're communicating daily and kept apace of each other's work. If you're currently dividing teams by discipline, re-organize them to be ...


3

Aim for cross-functional teams in the long term Welcome to pm.stackexchange! As @Sarov suggested, you should reorganize into feature teams. In the meantime, here are some suggestions for better coordination: Ask the two teams to publish their plans in a visible whiteboard: Just by making their plans transparent, they will be motivated to resolve diverging ...


2

If you want more visibility then you need to toot your horn louder. Specifically, send out a periodic status report that begins with all the fantastic work you've done since the last update. In your case, it would include a lot of unblocking. You can include a brief explanation of the severity of the blockage and the difficulty in removing it and 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 ...


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