22

You don't make any mention of a Scrum Master in your Question, so I'm going to assume that either s/he doesn't exist or isn't helpful. If not, make sure you involve the Scrum Master! It's his/her job to address process issues. That being said, Scrum provides a tool to address things like this - the Retrospective. Here's what I would do, in your shoes. For ...


21

I am dealing with a similar situation; previous teams merged into one with subsequent respecifying of roles and grades. Some legacy political forces were in play. As the Scrum Master you are the master-servant of the team including coaching. Many agile commentators forget the master part but the business is paying you to impose your will upon the team to ...


14

That is a frustrating situation Chris. From your question, it doesn't sound like the team can't develop things in smaller pieces, but rather that they won't. I base this on the fact that it sounds like when the agile coach is there they do and just in my experience as a developer, the type of splitting you are talking about isn't usually difficult. In short, ...


9

This may seem pedantic, but you don't solve this. They can solve it, but you can't make them. There are two approaches that come to mind on working through this: actual conflict mediation team building Conflict Mediation There are books and certifications on this - far more than fits in a Stack Exchange answer, but a starting point is to talk to them ...


9

I'm a developer working with legacy code on scrum, and let me tell you, i think they're right in their ways, because i do the same. Let me explain my case, be aware though i'm what people consider a cowboy/hacker programmer: TL.DR: breaking everything on smaller items isn't good, you're missing on patterns & interactions: you're exchanging the chance ...


8

David is absolutely right, there are very few instances whereby refusal to work can be considered acceptable, generally the accepted norms would be if to continue would compromise yourself and/or the organisation legally or as David has already said if to continue would constitute recklessness and present a risk to life etc. The developer’s behavior is ...


7

It sounds to me like you have two possible root causes here: The developers could triage but are instead escalating The developers should be capable of triage but are not able to because they do not have the knowledge or skill, and so escalate In the first instance, if you want to change their behaviours you need to do several things; you need to inform ...


6

Both projects should have business cases tied to them. It should be relatively straight-forward for an appropriate authority to use these together with knowledge of your organization's priorities and decide. Example. Project A should deliver $100 benefit. Project B should deliver $50 benefit. Resource goes to Project A. Example. Project A should deliver $...


6

You may take these three ideas from Scrum that may be useful to you. Scrum of Scrums - a regular meeting of team representatives (usually one per team). In Scrum, the point is to communicate and resolve team level problems and blockers together. So the meeting is focussed (although not as strictly as the daily calls) to avoid wasting time. But you may adopt ...


6

EI and conflict management goes hand in hand. EI will be useful in all areas - Negotiations with client during inconvenient situations Motivation to resources who may not be happy with their role/responsibilities or senior management Conflict between team members Your team member may not be happy with you as well, you dont have to take it personally and ...


6

You're assuming that you know what is best for the team without being on the hook to deliver the software. I am a strong believer in agile methodologies and Scrum in particular. I fully support the iterative user story approach. With that said, there are tradeoffs to consider: If the team is either working on an existing product or is accustomed to ...


5

Marv's answer is a good one but I think there is one missing element and that is the REAL expectation of the organization. I highlight "real" because organizations often pitch an ideal expectation that sounds forward thinking, enlightened, etc., but behaves inconsistent to it. For example with this scenario, the organization is wanting the team to take ...


5

You cannot refuse to do work. You can offer up an objection, you can propose a few other alternatives and state your case, but you must always support the decision and the team and continue. As a PM, you cannot allow a team member to "refuse" to do work. The only time refusal is remotely acceptable is when something catastrophic is predicted: safety, life ...


5

This has nothing to do with Scrum or PM or projects really. This is a political issue. Confronting this PM will lead to your eventual demise. Going around him to the CEO will lead to your eventual demise. You have three alternatives: 1) get in the sandbox and learn how to play with him, get him to trust you, and work to make him look good to the CEO; 2) ...


5

I hope I'm not too late with this answer ... or hopefully things have improved. But reviewing the question ... I'm sure Scrum can help... He has a very bossy attitude with "inferiors", he is very shy, fearful and flattering with the CEO, and he's used to get his own way through hiding information, insults, arrogance, machinations, and harming reputations....


5

Your premise is toxic. Both teams are putting too much emphasis on who is to blame and too little emphasis on fixing the recurring problem. Currently, your two teams are in an antagonistic relationship with each other. For one to succeed, the other needs to fail. That is the root of your problem. Try to get your two teams to work more closely together. ...


4

Wow. Tough break! Firstly, do you have a PID that outlines the approach to project delivery, including the development model to be used to deliver the project. I'm assuming not, which is a shame since that could be waved as the agreed approach. However, my advice is this: Trying to find a new methodology or approach that would mollify the disruptive team ...


4

Enforce the Roles of Scrum In Scrum, the Product Owner owns the Product Backlog but is not the "boss" of the team. He is, in fact, intended to be a collaborative peer of of Scrum Master and the Development Team. The Product Owner cannot assign work to the team. The team selects Product Backlog Items to accept into the Sprint based on projected team ...


4

Honestly, this sounds like the Product Owner is a typical type-A personality that has learned to get better results from relentlessly pushing his teams to always do more and better. (Think Elon Musk.) There's nothing inherently wrong with this because it's his style. As the Project Manager, it's your job to bridge communications between the Product Owner and ...


4

This is a common issue where the PM needs a scarce resource, and there is insufficient capacity to allow all demands on that resource to be met. Ultimately, someone in the organisation has to make a judgement call. There are several options including the following - and there may be others: Allocate the resource to one or other project; Split the resource's ...


4

This answer is inspired in the work of Tom Graves understanding perspectives and resolving conflicts in enterprise architecture. Things work better when we work together, on a purpose. If you don't act upon this, things will tend to follow the same consistent pattern. You've done great so far by exposing the assumptions each side have. That's the initial ...


4

TL;DR You probably don't want to hear this, but the developer is probably right about your lack of experience, although based on what you've said they are addressing it in a very unconstructive way. From your own description, you clearly lack effective authority, influence, and delineation of roles on your project, making this more a question of fitness for ...


4

Normally, if you reprioritize or reschedule tasks to be started immediately, you need to interrupt and postpone current activities. This inevitably incurs overhead. Your client needs to understand that changing plans isn't free. In a fixed contract, you will have calculated some buffer for unforeseeable changes, but this buffer isn't there to be used up by &...


3

When this happens, this is either a non-issue or the tip of a broader issue. If both projects want Bob, but they don't need Bob and could use Jason instead but he's not quite as good, it's a non-issue. Maybe Bob goes to the harder project and Jason reaches out to Bob if he has questions. Now, this becomes much more complicated if there is no Jason. If you ...


3

You probably heard of Brooks law "nine women can't make a baby in one month". It sounds like your PO wants one woman to have a baby in 3 and not 9 months. I've had relatively similar case lately and my personal instinct was and is to resist inflicting more pressure on the team - squeezing more velocity out of them is acceptable if you have an important ...


3

What I usually do is when someone come to me with a silly question or silly issue, I sit beside him/her, and I ask to show what s/he has tried, then I suggest things that won't solve the problem, I make them research in front of me, reproduce the issue, explain me the issue, etc. So the conclusion, is that the next time, because when they ask me it require ...


3

As a team lead i experienced similar behaviors in my team , in my case the impact was worse as the tech lead was external and the dependency almost slowed us down to a crawl. How I handled it ? Got the team together (including the tech lead) and brought the problem out in the open . I needed to balance my message , so that it did not come across as not ...


3

As you have mentioned While they don't need this information to do their our tasks, the opacity is contributing to resentment and frustration If this communication is not important for their daily tasks, a suitable interval needs to be identified.If not teams will be overwhelmed & their productivity will be impacted Product Demo's / 'Tech' talk is ...


3

Within the bounds of project management, it is not generally good practices to bring out the stick with the carrot. Even when not using agile, project teams are expected to be professional adults who know how to get their job done. Listing punitive consequences, as part of an opening design discussion, speaks of unprofessionalism. It also tells me the ...


3

As with all marginally performing employees, you sit them down, you outline expectations and achievable objectives, you detail a timeline, and then you measure for improved performance. This is essentially a PIP, a performance improvement plan. If he fails to meet the objectives, you cut bait and replace. Since this is a "project," your runway is very ...


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