The waiter, the doctor and the musical producer — managing stakeholders basics
Are you caught in a client/stakeholder nightmare? You’re not alone.
This applies to anybody who ever worked in a project. I’ll bet that most of the time, the project you’re on is based on someone else’s vision, someone else’s identification of opportunity, someone else’s problem to solve.
This means you’ll have to deal with them. Yes, them. The people who have the vision, who identify the opportunity, who suffer if the product is wrong, or who has a problem that needs solving. They are stakeholders.
Some of the most common problems in dealing with stakeholders are:
- I had a dream-product idea, and I don’t care if you want to test it with users. I know if you build it, it will be a success. So let’s stop talking and just build it already!
- Why do we need to iterate?
- So my customers have this problem and this will be the solution…
- This is the deadline and this is the scope.
- I sent you the requirements, there is no need for a meeting…
- Yes, I understand we’ll only test the user interaction, but can this button be navy blue instead of light blue?
I could go on…
Our biggest challenge here is when the stakeholder doesn’t blindly trust us — which in my experience is always — and we need them to understand what we are doing and why. Specially why.
At this moment, we are crossing the chasm in the Agile adoption. All the early adopters are already running Agile practices, and now the early majority is starting to tilt the helm. However, this early majority is trying to fit Agile practices into all their known waterfall boxes — and are getting very frustrated because things make no sense.
In theory, we know we should ask them to trust us, ask them to do an experiment, and provide data to support that the use of Agile practices is more productive.
As a business analyst in an IT context, that’s your job. Take the vision of your business stakeholders and help them make a success. You can’t be just an order taker — you’ll need to behave more like a doctor. And sometimes this means telling your stakeholders things they don’t want to hear. But if you’re sincere about helping them succeed, they’ll see it and value your help.¹
Like a music producer helping a band to achieve success, product owners should be able to work on something that will become successful, while appeasing the anxieties of each band member. Taking orders — like a waiter — to make the patron happy should be out of question.
I understand this worked beautifully with early adopters, who value innovation and are more open-minded about experimenting. But I am starting to see a very ugly movement, a rising wave of sorts, formed by all early majority members that believe command and control are the basis of any project’s success and outnumber agilists 10–1. If we don’t tackle this wall head-on and wait until the Agile culture seeps in naturally, we’ll most likely be crushed.
So what to do?
I’m still testing hypotheses, but so far the strategy that seems to have worked better — assuming an Agile approach is already accepted, but you’re having trouble enabling an Agile mindset — is:
1- To break the mindset of software delivery (in opposition to a product mindset), apply product discovery techniques. If your stakeholders are resistant, you can sell the idea as the fastest way to map the product’s scope and enable the team to comprehend business needs.
2- Training, training, training. Offer workshops, literature, lectures and support for your stakeholders to have contact with Lean and MVP processes. I usually see that happen with scrum, but training a stakeholder for scrum is not as effective as training for Lean and MVP strategies. A stakeholder that knows scrum will think it’s a good idea to listen in on the dailies, and bother the team at anytime. A stakeholder that knows MVP and Lean will understand the power of iteration and validation, as well as the build-measure-learn cycle.
3- Loads of data. One of the biggest problem with ex-waterfall stakeholders is a deep distrust, and believing that, left unattended, the teams will stay idle. Transparency is key to showing that lack of commitment to a scope and date has nothing to do with lack of control and visibility. Have metrics for the team and for the product well defined, frequently updated and thoroughly communicated.
4- For a short time, allow yourself to be a waiter. If you know they don’t trust you, start as a proxy, but treat your stakeholders’ requests as hypotheses, and ask them for help to identify the problems they want to solve, and to define metrics to validate their assumptions. Ask them what to do if their assumption is invalidated, and what you’d try to validate next. This will hopefully show them the process works.
5- Roadmap and product evolution. Keep a roadmap and a burn-up chart updated and visible so that at any time your stakeholders can check on the progress.
I have applied these methods in some occasions, with good results so far. I’ll keep you posted as new experiments progress.
Liked this article? Have different or additional ideas? Feel welcome to share!
¹ PATTON, Jeff — User story mapping.
If you like this post, don’t forget to recommend and share it. Check out more great articles at Code Like A Girl.