21

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


19

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


13

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


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


8

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


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


7

The Project Managers know there are other options that will work better. The implication behind this sentence is that the PMs know with absolute certainty the other options will work better. If my inference is right, I find that implication odd as I am not sure I have ever experienced a time when a complex problem had a solution that was guaranteed to ...


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

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

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

Treat it as a change request. Assess the impact on scope, schedule, cost, quality, and conformance with mission needs. Find Key Performance indicators to discriminate between the options. Make sure that the stakeholders are aware. Then decide if the impact on the project is sufficient for you to walk away. Be careful; As @David Espina hints, their ...


4

TL;DR [I]t seems counter intuitive that the teams would NOT find inherent value from some or most of the PMO controls...[that] should help them manage their portion of the work[.] Your organization appears to be suffering from a lack of perceived value in the new process controls, as well as a lack of proper "tone at the top" in support of this process ...


4

It sounds like one or more of the following could be playing into the current situation. Lack of understanding by the projects of what the PMO is doing. Maybe the PMO is offering the projects exactly what they need, but it hasn't been communicated well. To get some insight into whether this is a factor, do a quick informal survey to see what the projects ...


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

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

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

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

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


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

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

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


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