"Negative stakeholders" are usually symptomatic of a process that lacks visibility, or lacks an objective methodology for evaluating project goals from a systems-thinking perspective. Not to worry; CodeGnome catch-phrase #432 is: There's an agile process for that!™
Who Owns Stakeholder Management?
In Scrum, stakeholder management is the responsibility of the Product Owner. The Wikipedia entry on core Scrum roles has this to say (emphasis mine):
The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business.
Loosely translated, this means it is the Product Owner's job to actively manage stakeholder expectations, prioritize their requirements in accordance with organizational needs, and (by implication) to create sufficient buy-in for the project to succeed.
The Scrum Master and the Team certainly have a part to play in all this through articulating process, providing user-visible functionality to stakeholders at every Sprint Review, and by providing stakeholders the management levers they require (through the Scrum process itself and through the services of the Product Owner) to effectively manage the project in a change-embracing way.
However, the responsibility for managing stakeholders does not belong to the team or the Scrum Master. That responsibility is clearly defined as the job of the Product Owner, and by extension the project sponsors or steering committees that have imbued the Product Owner with sufficient authority to run the project.
Some Product Owner Tools
Buy-in is more of an art than a science, but some agile or traditional tools for creating stakeholder buy-in based on organizational value include:
- Theme Screening
- Theme Scoring
- Relative Weighting of Epics
- Project Success Sliders (e.g. constraints-based decision-making)
- Traditional ROI calculations.
- Theory of Constraints discussions as they apply to the organization.
- Time-to-market analysis.
- Budget, budget, budget.
For those who like tools, the folks at Mountain Goat Software have some excellent online tools that you can use for free, or can use as a conceptual starting point for other quantitative ranking approaches to stakeholder requirements.
Informed Consent vs. Enthusiastic Backing
In my personal experience, making sure everyone's vertical interests are at least assessed by the project by a formal, documented methodology (when the methodology is generally agreed to be politically impartial) is the key to success. Even if individual stakeholders aren't happy with the specific results of how their individual interests are prioritized by the organization as a whole, they are generally satisfied when they can see that the process takes their concerns into account and that they will see direct or indirect benefits from the project's overall value stream.
The fact that the prioritization is both visible and transparent to the stakeholders is the key. For example, as much as it may be important to my team that a therblig embiggening function is added, I will be more likely to buy into the immediate value of a proposed lead-into-gold transmutation feature. The fact that the embiggening feature I've championed is still added to the backlog, albeit further down the list, ensures that my concerns aren't being ignored--they're just being put into context based on the needs of the organization as a whole.