If you’ve ever worked in an Agile environment, you may have heard the classic complaints: “Developers are just too difficult to understand,” and, “non-Devs are too needy.”
The communication struggle between developers and non-developers is real. They speak different languages (literally), they specialize in different areas of the business, and they often have very different skill-sets. These are common blockers in any Agile environment, but it’s important to remember that—despite their differences—each side needs the other. And it’s in everyone’s best interest to do well.
Making great solutions requires us to give constructive feedback and communicate effectively. Developers need to accurately convey what’s possible. Non-Developers need to advocate for the needs of a client. Each side relies on the other to make great things happen.
Here’s some things you can do as a product owner, SCRUM master, or manager to bridge the communication gap between the two sides:
Don’t continue to let there be two sides.
Unify the team. Introduce a Dev to a customer (give them a script). Show a non-Dev how to clear their cache before testing a feature. Allow them to each see the challenges of each side of the business.
Start by knocking down walls. Let people simply be near each other and work in the same physical space. The goal here is for both sides to see what the other goes through: What does their job entail? What blockers are they dealing with? How do they communicate with each other? Do they drink coffee? Tea? Beer? This is a simple way to help the teams understand each other better.
Help your team(s) cut through ambiguity.
From non-Devs, you hear things like, “I don’t understand why this is taking so long to implement.” From Devs, “This worked when I tested it locally,” with neither side taking the time to fully express their needs or understand the issue. Each side should stop making assumptions about the other, and simply ask for clarification. Encourage your teams to provide visual feedback and use cases to help each other understand what needs to happen. You should also be inviting non-Devs to sprint retrospectives and asking for their feedback. This can help both clear up any ambiguity, and set goals as a team.
As a product owner, SCRUM master, or manager, you most likely know who-does-what and how-it-gets-done. Be the person who can make introductions and connect the dots. They need to know each other. Make them know each other. The sooner they know who-does-what, the sooner they know who to approach to resolve their own blockers. When you bring together a blend of skill-sets and experiences, you have a recipe for innovation.