How would you deal with a difficult or disruptive product stakeholder?
Welcome to part 57 of our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.
My mind immediately drifts back to the time when I asked a difficult stakeholder to leave the meeting because their behaviour was unacceptable, disruptive, and counterproductive to the outcomes we were trying to achieve in the meeting.
They certainly didn’t appreciate it, nor were they happy with my response to their behaviour, but sometimes you need to make that call as a scrum master and agile coach because it’s the most appropriate thing to do in the circumstance.
Identify what is actually happening.
As a scrum master, your first step is to identify what the disruption is about.
- Are they being difficult for the sake of being difficult, or do they have legitimate cause?
- What is the stakeholder upset about?
- Does the stakeholder understand the purpose of the event or meeting?
- Have they simply not been prepared for what to do, how to address concerns, etc?
And so forth.
Remember, especially in the early days of an agile or scrum adoption, senior managers and stakeholders are not used to the process, the behaviours, and the philosophy of scrum.
They are used to dictating terms and driving outcomes based on their own terms.
The idea that we value experts on the team and create psychological safety for them to speak the truth to power is a completely foreign concept to them. We need to take that into account and understand that we may need to invest time in training, coaching, and mentoring stakeholders.
In a traditional project management environment, stakeholders are generally invited to a review or meeting because the product is polished, perfected, and complete in every sense. So, their expectations are that this sprint review is going to deliver a polished, perfected product.
When they witness a work in progress, their expectations are shattered and they can go off the deep end fairly quickly. We need to educate them. We need to explain that scrum focuses on using customer and stakeholder feedback to build the right thing and refine the product or feature with each iteration.
We aren’t presenting them with a perfect product, we are cocreating the perfect product with them.
Taking time out to talk to product stakeholders BEFORE the sprint review can solve a lot of these issues. Talking them through the concept of empiricism, explaining to them why it’s such a critical element of product development in complex environments, and inviting them to contribute in a positive, respectful, and productive manner.
You can explain to them that they are used to being presented 12 to 18 months of work at a time, but now they will be reviewing something that has only been in development for 2 weeks. Explain to them that the team won’t be investing weeks in developing slide decks in organizing catering because it takes away from time invested in developing and perfecting the product.
Explore why the stakeholder is consistently getting upset.
So, if you’ve walked them through the process, explained the nuances, and set clear expectations for the stakeholder but they are still getting upset, you need to understand why that is happening.
This where you transition wholeheartedly into listening mode.
Arrange a meeting where you can sit down with them and talk the problem through.
Maybe, they have legitimate reasons why they are getting upset and that becomes content that you can explore with the team in the next sprint retrospective with the objective of tackling the problem, identifying a way to resolve the problem, and take the actions necessary to improve.
Ask the stakeholder:
- What are they expecting?
- Why are they expecting that?
- Why is that important to them?
- How do they imagine the team could be delivering better results or outcomes?
- What would they like to see from the team moving forward?
- What are the elements that would lead to increased satisfaction?
And so forth.
Get really clear about what is happening in the mind of the stakeholder, what is causing the issues, and what their expectations are moving forward. What they would like to see and why that is important.
Maybe it’s a learning moment for the team. Maybe it’s an opportunity to improve. Maybe they understand everything there is to know about agile, but it just doesn’t help them.
- They have deadlines that must be met.
- They have pressure coming down the pipeline that isn’t being addressed.
- They have financiers who couldn’t be bothered with agile product development processes.
And so forth.
Maybe it’s completely out of control, and there’s nothing you can do about it because it would ruin everything the team is trying to achieve, but at least you have a clear understanding of what the problem is and how you could potentially solve that problem.
So, those would be my two primary recommendations for dealing with a difficult stakeholder.
About John McFadyen
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster