The cost of communication shortage
About missing roadmap and missing priorities
Every once in a while I am part of a team where there is a quite weird culture and there are too many steps in the leather, so I can’t attend several planning meetings regardless I am the person who tries to design the infrastructure.
It’s also a pain when you don’t know what happens and what you can’t see further than the end of the sprint. Just imagine how you would make big architectural decisions in this case. This can also happen if you have no roadmap at all, or you have one, but it’s very badly communicated. Or also the engineering team is not involved in the preparation of the roadmap.
Consequences of lack of information
Just imagine a situation. You are working for a company, you constantly get the stories/tasks. However, you don’t know what will happen after these 2 weeks. If you work as a developer, you know, you should not just code, you should even plan, make technological decisions and use design patterns, and many design patterns look the same and can be used for solving the same problems, but in the long run, they have different effects to the same system. Or shortly: a problem has many solutions. This problem persists in the case of infrastructure too, not just for code architecture. This is what I call blindfolded designing.
The second big problem is losing priorities. In my experience, if you can’t see further and you don’t know the plan for the next longer-term than 2 weeks you don’t even know that’s the most important thing. Also, you are not informed if you want to put into maintenance some part of the architecture and you shouldn’t waste too much time on that part. That also happens when your information is not correct or alternating. There is a lack of decision.
When you haven’t got enough time to do some maintenance, you are making a big pile of technological debts which are not getting smaller and causing bigger and bigger problems, because of sinking to the bottom of the backlog, it can be even an unmaintainable system or a very problematic system.
This all above has an even bigger effect and it is the lack of trust in the product owner, which can lead to guerilla works because average people hate to be in a situation that is not favorable. Furthermore, they can lose their hope for a brighter future and a more production-grade system. This can lead to a massive resignation. This can conclude losing of know-how since people can’t be replaced this fast and this can be fatal for the product.
What can be done?
Lack of communication can be handled with communication. However, communication has 2 sides, someone who tells the problems and a listener. And it’s mandatory to listen to the other side and be tolerant. Also, ask about opinion, because sometimes people just don’t feel comfortable about telling their concerns by themselves.
There are special forums for this like the retrospective meeting, where you can talk about problems, talking about the past sprint, or even sprints. Also, people can have their improvement ideas to support effective work or make work more effective.
The second most important meeting in the scrum world is the refinement, where you can even talk about the implementation of a task. In this case, you should know every tiny little bit of the task and you should understand how to solve and what’s the goal of the task. The goal of a story is its acceptance criteria and ticketing systems mostly have this field by default.
If you are a bit separated from your product owner, you can have architectural discussions every once in a while to talk about problems and let them know what’s the situation and how these kinds of things impact your work. Keep in mind that product owners can only understand the situations from impacts and value, so tell them these too.
All in all,
Sometimes lack of communication can have catastrophic outcomes. Losing trust and hope is the most dangerous part. Don’t forget that you work with people, not robots and information is more valuable than you think. There are many general solutions and you don’t have to reinvent the wheel. Read, learn, have meetings, communicate and sometimes confront, because confrontation is part of communication, but don’t forget that you work in the same team and you want the same: to have the best working product that you can imagine.
