How to get customers on board

Just the other day I was meeting the representatives of a potential new client. As we were discussing their expectations regarding Scrum they brought up a topic that has made me curious for some time now: „Our clients do not understand what we are doing. We need to explain them how to write good requirements according to Scrum and train them on the method.“ First of all, I do not want to talk about expectation management in agile product development and I also do not want to talk about a "you-change-and-I-don’t“-culture. What I would like to talk about is how to get an internal or external client, the management or even regional Key Users aboard this Scrum flight.I can offer an easy answer: „Do it!“ That is all! Involve your users in the process, deliver continuously, reflect and adapt and use the framework to let them find their role and contribution.Now here's the not-so-easy answer: „Do it!“ Of course, customers will not understand why they have to be with the team for a Review meeting every second week when everything is going well anyway. They will not understand why they should take part in a Backlog Refinement session every week, and if the team is really ambitious they also have to attend the Sprint Planning every second week. They will probably not understand why they have to prioritize requirements together with the Product Owner and why they have to let go of some ideas, because in the past they only had to point out the requirements they wanted. And most probably at the beginning, customers both internal and external will not see the benefit of telling the Development Team what they do in their departments every day, how they work and answering questions they do not have the feeling a developer should care about.

Make them an essential part of your daily routine

Here's the cure: Keep them in the loop. Let them become an essential part of your daily routine. Talk to them. Make them feel valuable for the development process. Listen to them. Understand them. Make them feel what it means to be part of Scrum. And again, that is all! All the concepts you write for communication channels, all the explanations you give on your work and all the trainings that you consider helpful to make them understand are only as good as your daily practices and communication routine with them.However, you need to explain your why. Why do you do the things you do and why do you mean to change current ways of working relations? If that is clear to you, you can make it clear to them. And then, after some nice talks, maybe two or three joint retrospectives and finally, after the first delivery that meets the expectations in solving their daily problems and in which they can see their ideas growing, they will value the close working relationship and the quick feedback that this framework offers. And soon, they will not leave the plane before take-off anymore.