Join the Mastering Agility Discord community!
Let’s face it, your stakeholders couldn’t care less about Scrum or whatever framework you’re using. And I understand that. They just want to get their needs met. Scrum is not one of their needs. If you go off to buy bread, you don’t care how they made it. You just want to feed your family and yourself. Or maybe a more complicated example: buying a new car. You don’t care what mold they used to create the doors.
But here’s the thing. In such cases, you know exactly what you want. In domains where Scrum thrives, people don’t know what they want. They think they do, but they really don’t. Only when having a new piece of working product in their hands, they’ll know whether it meets their expectations or not. And that is why they should care about Scrum.
Photo by UX Indonesia on Unsplash
You’re shooting in the dark without the voice of the user
Unless you have a crystal ball, OR telekinetic abilities (if so, you’d be a great guest for my podcast. You could solve many issues for other Scrum Teams), you can’t exactly predict what your customers want. You’ll gradually find out. That’s the beauty of empiricism: knowledge comes from experience and conducting experiments.
You need the voice of the customer to make actual progress. They need to be involved in the process as often as needed. Here’s a comparison to waterfall development (that still has its place, but not when the situation/environment is complex IMO).
Visibility: Think of visibility as dolphins vs a submarine without any instruments, both heading toward an idyllic island. Why an island? Dolphins would obviously go to an idyllic island to play with people. Why else? Anyway, moving on. Dolphins emerge above surface level every couple of minutes (8–10, now you know). Think of this emerging as an inspection toward to goal (the island) and if they’re deviating. If not, they can adapt their path. The submarine would only check if they would have arrived only at the end of their projected plan. They dive under, execute their plan, and only then know whether they achieved the goal or not.
Ability to Change: This frequent inspection keeps a whole realm of possibilities open to change the path (or product). If development teams never validate their assumptions or collaborate with stakeholders, they’re shooting in the dark. Then in the end, when the deadline expires, the only option to change is by consuming more time (in other words, money).
Business Value: Frequent delivery of valuable Increments (and gathering feedback) provides more and more business value from the start of the development. Waterfall types of development only generate value at the absolute end, and even then there as so many unverified assumptions that the value may be a lot lower than hoped for. Having the voice of the customer incorporated frequently makes it more likely that business value is delivered.
Risk: Working with complexity inherently means there are high levels of risk. Risk of creating the wrong thing, competitors chasing you to create a better product or snatching away your clients, etc. But also the risk that your client changes his mind. That risk can be limited by, again, frequently collaborating with your stakeholders and by having an appropriate lengthy Sprint. Of course, no longer than a month.
Too often I come across disconnection between Scrum Teams and their users. Note that I’m not saying, stakeholders. Often stakeholders are advised, yet they are not actual users of the product. In other words, Scrum Teams don’t understand what the users are using the product for, and users have no clue about important things like a balance between investment and ROI of a specific feature.
Photo by Adeolu Eletu on Unsplash
What I mean by that is that users request a feature that on a scale from 1 to 10 would deliver a 5 as business value, yet would require an 8 on levels of investment. But due to missing collaboration and a lack of mutual understanding, no one realizes the mismatch between value (5) and investment (8). Key-Value Indicators may provide a great way to make this mismatch transparent.
Keep your managers close, keep your users closer
Keeping a short feedback loop with users and customers involved elevates the potential levels of success. That starts with ensuring that you have a group of willing users to provide feedback and be actively engaged. That can be tricky at times to gather such a group. That’s also where the Scrum Master plays an important role. To facilitate customer collaboration where needed.
If there is anything that you might want to take away from this article is to have a good inspection with your customers and users on how well they understand how important their input is to the success of the development effort and the success of the product. Without their feedback, you’ll basically be making up what you feel is valuable to the customer. How short is your feedback loop? How long does it take to learn/validate assumptions? Quantifying that could bring valuable learning points.
How are you involving the voice of your customer in the development?