¿Cuáles son las mejores formas de manejar a una parte interesada que no negocia en Scrum?

What do you mean negotiate? What's there to negotiate about? The estimates people in the team make? It's their work, so their estimates are always good. The work that goes into a sprint? Again, the estimates are the team's, so there's nothing to negotiate here either. At best, consider dropping the concepts of sprints. Then there are no mini-projects anymore to stuff (like turkeys at holidays).

Pause and take a hard look at the potential "conflict" from a big picture perspective. Ask yourself - Am I missing something that the other person sees? Something that could hinder value creation for the business? Scrum is a wonderful method but it is only a means to achieve the larger goal of delivering value to customers. I would assess the conflict through this lens. When someone is adamant about putting their demands over and above the sanctity of the method, ask (and discuss with them) if this will create or destroy value? If you become equally adamant and a purist, will you lead to value creation or destruction?

I've seen stakeholders not want to embrace scrum or other agile methodologies and it is often the same general root cause which is simply that people don't like change. It's hard to see and mentally apply benefits for a system you don't understand. At the same time, it is second nature to apply all of the perceived drawbacks to a change and so start out with an imbalanced perspective. Knowing this will help you to better empathize and see the root cause behind their concerns to better address them.

I fully agree with the importance of understanding the stakeholder's perspective. As a Scrum Master, I've often found that seemingly unyielding stakeholders often have valid concerns or specific business pressures that drive their resistance to negotiation. Empathy and understanding go a long way in finding common ground. It's crucial not to view them as adversaries but as valued contributors to the project

In my experience, as long as the teams deliver business value ethically, legally, sustainably, and financially viable, stakeholders care little about our way of working.

They don't mind how you get results. They just want to see results. So, why bother them with Scrum? Fathom something they may like and show that. See what happens. How you organize that is just your internal process.

The aim of an organisation should not be to sell Scrum, but to sell working products that resolve the stakeholders' needs. Find out who the real decision maker is. Often it is not the person who got the Product Owner role.

Scrum is not a goal but a means. And if you listen to your stakeholders you might discover that there are different means to reach your goals. So, Agile means (also) exactly that: being agile in terms of being flexible, responsive, adaptive, and nimble regarding your ways of working.

No-one will really care what you are using to deliver if results are there. If you have to go down this line (of trying to convince the benefits), you probably already lost.

One thing I found very helpful in addition to of course listening to the stakeholder is to follow TIA .. transparency , inspection and adaptation . We are solving for the need of our stakeholders so it’s always going to be important to have all possible use cases broken down WHILE using TIA. CICD is great but continuous improvement is also part of any process scrum or not .

This approach is tried and tested! In my experience, the data driven stakeholder expectation management tends to lead the conversations more objectively. Figures help proof the learnings, approach, delivered value and most importantly encourages transparency. Feedback are critical to align the best interests, keep constant checks, increased predictability and thus, confidence.

From over 20 years of experience working on approaches to team productivity, I've found that it's very important to not let them feel manipulated or gerrymandered into an approach. They have to feel they have had a hand in developing the process, and I'm there just to lend ideas, maybe even recommend them. Then, become an experiment leader to help those who want to try an approach out at a very small scale, and see if they think it has merit enough for their working culture.

Data is the key to handling stakeholders. It is an objective means to show results. Ideally, it is possible to convince every stakeholder with data. It is a reliable way and creates consus. Some stakeholders, particularly higher management, may not be even interested in metrics and data, and consider only their own interest. In this case, the scrum master needs to create a deeper empathy with them and find agreement at different levels. Often having more regular discussions helps. It becomes part of the communication plan of the scrum master.

Negotiation backed by data and feedback does help always. Metric after multiple iterations can serve to be a pool of data which can help to plan the future iterations better.

Don't think in terms of "scope creep". We want to be working on the most important remaining items at any time. Any "scope" set up-front will be wrong; we learn better as we go. The Product Owner keeps a prioritized list of items (the Product Backlog) and somewhere down that list we will have done enough to provide a product that is safe and worthwhile to release. Then we decide whether to improve the product by continuing further through the backlog. The backlog is not static; things get added, removed and re-prioritised as we learn more, and things can become higher priority by being cut smaller (pare away more low-value stuff so what remains is the core value but cheaper to implement).

Product Owner (plus Team) maintain a universally ranked Backlog. At the end of Sprint “How” Planning, the Developers veto the lowest ranked items.

Not just setting expectations but also keeping them realistic is important. Additionally, this should approached as a team game that involves the stakeholder. They are as much a part of it as you are. That mindset can be a game-changer in any negotiations. In fact can turn those into collaboration.

Talk about the assumptions the team is operating under and their real constraints. Talk about the impact of context-switching and not finishing work on quality and speed of delivery. Rigid roles and boundaries may be useful in low trust environments, but building trust requires looking clearing at everybody’s goals and constraints. Be honest when you talk to stakeholders about what the team can commit and what the costs of various requests are.

Setting boundaries is really importance regardless of good stakeholder relations. Documentation and clear communication can be your key tools to do the same.

I created a community of practice for scrum masters which helped in collaborating on common organizational challenges related to agile adoption, culture, & Scrum. When a Scrum Master encountered challenges or roadblocks, the community of practice provided a platform to seek input and solutions from peers.

Looks like AI is at it again. Does not look like a realistic issue for a stakeholder to be part of an Agile (scrum) framework, yet be closed to negotiation. Due to constantly evolving priorities, customer needs, organizational needs, it is imperative for all stakeholders to exercise a flexible mindset to get the priority deliverables released. The reasons for disagreement are usually over the process, timeline, validation of requirements, resource crunch, etc. and every use case has a solution, or at least an immediate solution even if temporary so the team can work on permanent solutions. The key ingredient to achieve this is to use objective & reasonable arguments to bring everyone to a common platform.

This should not be a power struggle; if it is, you are working in a toxic organization. It is not *our* vision and goals that take precedence, but whatever we get by sensibly combining the vision and goals of ALL relevant stakeholders. Playing politics will deliver a poor product that fails to meet some important needs while meeting some low-value ones because a high-power stakeholder has forced them on the product. Let "value" be the guiding light, not "power".

Sometimes, a messenger is as important as the message itself. If I do not have the social capital to influence or negotiate with a stakeholder, I engage one who has.

Seek Management Support: If negotiations are at a standstill, involve higher-level management or project sponsors who may have the authority to help mediate and find a resolution.

May be time for a coffee break! Engagement, and not escalation is the key. Else, it will have a domino effect on other stakeholders. Frequent engagement with stakeholders lets us bridge the gap between what they are expecting and what we can deliver. The more the gap in this, the more that stakeholder will be obsessed with their idea. And when we say 'No', it causes dissonance and friction.

Ask. Do. Repeat. Is this actually a problem? Whose problem is it? If yours, communicate it in an assertive way. If not yours, build rapport and only then hold a mirror, make the situation transparent. Repeat/iterate 😉

- Make sure stakeholders understand the value and the benefits. - Keep them involved and informed - Make sure they are heard - Don't let them tell your team how to develop the product - They only care about getting the job done but it's the Scrum team's job to do the job effectively and efficiently As long as the product is aligned with stakeholder's expectations, they should be happy. If they are not, communicate and collaborate more.

Agile organization or old-style organization, escalation is always seen as a traitor/childish action, like a child in the school playground "reporting"/"escalating" to an adult. But escalation can also be seen positively: I think A and I have arguments for it. My counterpart thinks B and have arguments. So the next step is to go for a conciliation (Vermittlung in German) to a more neutral body: for example a person representing for both the authority. Point.

Escalation really has no place in an agile organization. It may, however, be necessary in an organization that is aspiring to be agile, or one where only parts of the organization are agile or aspiring to it. Use with care; you are setting back your path to agility if you need to resort to non-agile approaches.

To understand the Stakeholder Perspective: Take the time to empathize with the stakeholder's viewpoint. What are their constraints or concerns? Understanding their motivations can help in finding common ground. Collaborative Problem-Solving: Approach the situation as a problem to be solved collaboratively. Encourage brainstorming and innovative solutions that can address the stakeholder's needs without compromising Scrum principles. Provide Options: Offer the stakeholder alternative solutions or choices. This can make them feel more in control and willing to participate in decision-making.

Compromises come in the famous three flavors: Scope, Schedule, Resources. And, famously, you can’t fix all three at the same time. If the stakeholder insists on doing that, it seems to me you have two choices. 1: ignore them 2: walk away. In any negotiation you must be prepared to walk away. And although the stakeholder isn’t saying it, they are already walking away by refusing to compromise. So don’t feel like you are letting someone down. I prefer option 1. Ignore them and deliver anyway. Nothing succeeds like success.

“However, sometimes you may encounter a stakeholder who won't negotiate or compromise on their requirements, expectations, or feedback.” This doesn’t make sense. Stakeholders develop part of the requirements through the Product Owner, so I don’t see how they should compromise. And why would executing Scrum Agile elicit such compromises?

Handling a hesitant stakeholder in Scrum needs finesse: 1.Smart Prep: Gather key facts; clarity is crucial. 2. Human Talk: Share thoughts with real examples and relatable numbers. 3.Consequences Check: Illustrate potential hiccups if changes aren't made. 4.Feel Their Vibes: Step into their shoes, tweak your pitch to ease worries. 5.Respect Zone: Acknowledge their viewpoint for a friendly, respectful chat. Example: If a stakeholder resists story rearrangement, show how it speeds up things and keeps customers happy. For budget concerns, explore wallet-friendly options, emphasizing support. Balancing Scrum goals with collective satisfaction is the key.

Setting up a Common Goal is the key! One thing I’ve found helpful is visualising our org/team as a jigsaw puzzle. With a shared goal, those seemingly mismatched pieces suddenly fit perfectly, revealing a stunning picture. I remember the buzz and energy in the office as we were gearing up for a big project. The excitement was noticeable, but so were the differing opinions. The Product & Development teams were eager to roll out new features, Marketing was brainstorming promotional strategies, and so on. It felt like we were all in different boats rowing in different directions and was leading to chaos. That's when we decided to set a common goal: "Enhancing Customer Experience", it was like a lighthouse guiding us all to the same shore.