You hear all the time that Visuality is a full-stack software house. But what does that really mean?
In layman terms, it means that we are capable of giving you the full-service regarding your software. So it's not only the coding of the back-end and front-end but also UX/UI design, business analysis, fully-comprehensive workshops and complex project management. The latter is probably the most important thing in software development (after writing quality code of course and wrapping it up in a nice shell), as it makes the process smooth, organized and, most importantly for the client, cost-effective.
Regardless of the type of your business or the country of its origin, as a CEO, COO, product manager or else, you won't have all the time in the world to control the backlog and look after the development team. Developers, no matter how experienced, need to know what to deliver and do that on time. That's why we offer you services of trained professionals that have vast know-how about the development. It's all for you, so you could worry less and just observe the results.
We do our best, but even the best professionals encounter challenges throughout the process. Communication is one of them. I asked our PMs what common issues they have, how they fight them and what they advise our clients.
Q: Please identify major problems in communication with the client
Mateusz: Main issues I see, is low precision of the requirements regarding the features. Another thing is a small time window when the client can share the business vision of the application, especially when the backlog is packed. Also limited tech-knowledge of the client and his difficulty in understanding the complexity of the specific solutions.
Wiktor: For me it's low precision of the requirements regarding the features, very vague explanations of how things work. It's often embodied with sending over designs with no explanations how certain elements are expected to work. It's often in someone else's head or designer, but it's all up to us to ask those questions and indicate contradictory things in the design.
A common issue I have is also not using agreed formats of requirementswhich makes us wonder what did client mean by that. For example, user flow description is not consistent with the agreed format.
Krystian: In my view, agreement on a common glossary is essential. Having the common language, that ensures that both sides understand the things the same way, allows us to follow communication plan agreed during the workshop and help you (Product Owner) communicate with your dedicated engineering team effectively.
Q: Which one is the most painful for you?
Mateusz: For me, the most problematic is the situation when I don't have a detailed backlog ready per each sprint. Due to such issue, the team has no concrete tasks. I'm responsible for such state in the team. At the same time I have limited power to make the decisions on my own, therefore the whole situation creates a vicious circle. Such situation compromises the full delivery of the sprint.
Wiktor: What Mateusz wrote above is 100% true.
Krystian: No timely feedback from Product Owner or imprecise one.
Q: From your experience, how the lack of information and poor communication affects the team as a whole?
Mateusz: Engineers like to feel that they have control and that there's a clear goal. When that's not on the table, because of the poor communication or lack of details, it creates personal frustration that may affect the morale and reduce the mutual trust between developers and the client.
Wiktor: From my perspective, the goal is most important. The developers need to know what is expected from them and what kind of business goal we'd like to achieve, so whenever there is a technical obstacle, they can find a workaround.
Krystian: Project is a team play thus cooperation is the essence. With no information or lack of details, we are slow and less efficient.
Q: What is problematic and hard for the client from your perspective?
Mateusz: From my experience, the most difficult thing for the client is to dedicate time to work on the large volume of tasks. If the client is not consequent in his actions, it creates the overload of the things he needs to prepare and/or accept for the sprint. It often leads to frustration. Another thing is that the client usually cannot force himself to think like a developer. He cuts corners because he knows the system really well.
In the initial stages of the development when the developers don't know the system by heart it creates a situation when the tasks are not fully described and further refinement is needed which consumes time and effort on both sides.
Wiktor: Sometimes clients have difficulty with delivering consequently the "material". It's against agile and against principles of the project management itself as it creates periods of intense work or periods with a very limited scope of work.
Thinking in "sprints" is a challenge. Next 10 mendays is what matters.
Krystian: Client has difficulties with communicating the essence of the business that's behind the application. Product owner forgets that the developers and project manager not necessarily have vast knowledge about the business that they do. It is important for the client to omit jargon as sometimes it is not fully understandable by the team.
Q: Why should there be a single point of contact on both sides?
Mateusz: It's not about one person on each side, but it's about one common place where the communication happens and the records are kept. For that, we need clear rules and roles (responsibilities). Example: When a task/issue appears it is clear for both sides who takes care of it. In Visuality we like to have a first point of contact for random issues/operational tasks --- a dedicated person that we can address in communication, even if that person takes it further and comes back with an answer. Of course, all depends on the situation and team structure of our client. We are flexible, however as I said, we need to establish clear rules for both sides at the beginning. Priorities and requirements need to be communicated unanimously. Imagine a situation when there are 3 co-founders and each one tells us another thing. Suffice to say, it creates a lack of efficiency and frustration on both sides.
Wiktor:
There are three levels of communication: daily basis communication --- something that happens real time, quick questions and quick tickets. The second level is mid-level communication regarding the backlog. It shall happen in Jira or other software dedicated for that. Third level --- emails and calls which are dedicated for more important things. Mixing these levels or using only one creates chaos and will negatively affect the development. Using wrong channels forces the team to dedicate time to put everything in the right order. And as we all know --- time is money and nobody wants to waste any of them.
Krystian:
Single point of contact is good but not always needed. In bigger-size projects, when you need to handle the communication with multiple people, it's good to have a person who will facilitate/streamline the communication. That's one of Pm's duty.
Q: What happens when there is a lack of roadmap in a project?
Mateusz: When there is no roadmap it is hard to create goals, maintain motivation and health of the team. When you don't have a clear plan, you don't know what you need and want to achieve, you just work for works sake. Our developers engage themselves in the project, they feel personal satisfaction when they're part of something bigger.
Wiktor: When there is no roadmap client can't prioritize the tasks. No matter how effective our team is, client in such state will not observe that we are moving forward.
Krystian: It's pretty simple --- client will waste his money.
.jpg)
.jpg)
