One of the most significant barriers between the customer and the development team is the communication barrier. Good old mature development methods such as Rational Unified Process had the whole discipline and the designated role responsible for establishing clear and effective communication with stakeholders. Unfortunately, many Scrum teams that aren’t familiar with full-scale requirement management struggles to communicate stakeholder unless the stakeholder takes responsibility to establish the connection. That may be convenient for the team and look “scrummy” (oh, our client is agile as well!) but, in fact, demonstrates the lack of cross-functionality and dramatically limits the possible client base for the team.
When it comes to communication with stakeholders, I like to use Dale Carnegie’s quote about fishing: “Personally I am very fond of strawberries and cream, but I have found that for some strange reason, fish prefer worms. So when I went fishing, I didn’t think about what I wanted”. He is absolutely right. To establish effective and efficient communication, we must use the stakeholder’s language, and we must discuss things that are appealing to the stakeholder.
First of all, we must know the stakeholder.
Start from simple things:
1) What is the stakeholder’s name? It would help to address him or her properly. Successful communication starts with the appropriate greeting and respect demonstrated from the very first minute of conversation.
2) What is his or her schedule? It would help to initiate communication when it is convenient for the stakeholder. When it comes to an international contract, timezone and daylight saving time rules also become essential.
3) What is stakeholder responsibility in the business? It would help us to ask the questions that the stakeholder can and is allowed to answer. It would also help us to use the problems related to stakeholders to engage him or her into the conversation.
Doing these three simple things would help facilitate a friendly attitude of the stakeholder to the team.
Next, to facilitate communication, we need to learn a stakeholder’s language. I don’t mean English or French; it is too evident. The language that we use comes from many things – what we are doing, whom we communicate with, where we grew, and what education do we have.
Collect vocabulary and conversation patterns from professional forums, media, and books related to stakeholder’s responsibility.
Carefully review cultural patterns and anti-patterns to be used. The last thing that you want is to offend your client accidentally.
Watch education videos and on-line courses designed for people like your stakeholder.
For long-lasting relationships with the client, such research must go even deeper. Learn personal preferences, everything from hobbies to religious affiliation, and be ready to keep side conversations. It helps a lot to build personal trust.
I also have to mention a few mistakes that many scrum teams make regarding product ownership.
1) “Delivering value is enough to establish and keep relationships with the customer.” It might be right for the very limited number of cases, where the stakeholder is the sponsor of the project. At the corporate-level, stakeholders are often disconnected from the project sponsors. They have no personal engagement and no personal interest in the project. The product owner sometimes should demonstrate outstanding communication talents to engage and motivate such disconnected stakeholders for the sake of the project’s success. Knowing the stakeholders and speaking their language helps a lot.
2) “Scrum does not need business analysis” (or, even worse, “it was a mistake to include product owner role into Scrum”). The fact that the whole team must be involved in backlog management does not mean that the developers alone can run requirements management effectively and efficiently. The proper communication with the stakeholders and processing of raw information require completely different skills set and personal characteristics if we compare to what constitutes to be a good developer. Most people cannot do both jobs equally well. I would say the right opposite. If your team can work with rudimentary requirement management, without having a qualified analyst on the board – your projects aren’t challenging enough and aren’t complex enough to apply an empirical framework like Scrum (think of “simple” zone on Stacey matrix).