Transparency is not enough

Without transparency, there is no possibility of multidimensional inspection and adaptation. Everyone has access to the same information, no one feels left out, we do not hide anything. Thanks to transparency, we can quickly identify problems, errors and reorganize work. Sounds great? Reality verifies the greatness of transparency.

Agile company

Once upon a time, there was a company that really wanted to be agile. Development teams worked in scrum, there were trainings, roles, meetings. And there were workflow boards available to everyone. Everyone could see what a given team was working on at any time, come for a review, ask a question. Unfortunately, few people took advantage of the opportunity to participate in meetings other than their own team. There was simply no time. Few people looked at boards other than their own team - everything was described in slogans and it was difficult to find your way around. Product Owners met with each other. They passed on expectations to each other, exchanged problems, and when something got stuck, they blamed each other. Teams that did not work in scrum (e.g. sales) submitted their report every two weeks during company-wide meetings. And everyone could see what they were working on in JIRA. If someone asked if there was transparency in this company - everyone would answer that there was. Does it work? Not necessarily.

Transparency alone is not enough. Without the support of several elements, it simply becomes another, checked off point in the "acceleration" process. So what must accompany transparency for it to be valid? Three elements: courage, openness to conflict and time.

Courage

In one company, tensions between the product and sales departments were commonplace. The other side was always to blame. Incompetent, inept, they can't cope, they don't listen to us, they don't listen to customers. The product department kept coming up with new functionalities, delivering, but sales were not going well. A new head of the sales department appeared. Two months passed. At a joint meeting, he stood up and said: "Sales are not going well because we don't understand the point of these functionalities. We will not sell something that we cannot understand ourselves.”

Access to information will be useless if there is no space in the organization for bold feedback, questions, or even questioning the sense of a given project or task. Such courage is only possible when it is met with openness on the other side. Unfortunately, too often we deal with complaints such as: “He is nagging again”, “At this stage you should already know why it makes sense”, “Maybe we will do it differently someday, but not now”, “We are wasting time on such discussions”, “I can’t help it, the client wants it this way”. Even if courage exists, such messages effectively extinguish it and turn it into the belief “Why speak up if it will not help anyway.”

Openness to conflict

During work on a new application, a conflict arises between the developer and the Product Owner – one draws attention to performance problems, the other insists on quick implementation of the function. Seeing the strong emotions associated with it, the Product Owner decides that the team will spend the next refinement on analyzing various perspectives and options, opportunities and threats related to them. Thanks to this discussion, the team develops a more scalable architecture that solves the problem and creates new opportunities for product development.

Conflict is a big word that everyone in the company is afraid of. Conflict means that we cannot cope with problems, that something has overwhelmed us. Meanwhile, conflict is a very important element of the product, service, or any project development process. Openness to different opinions often starts conflicts. However, it does not mean that we should be afraid of them. Difficult situations are natural, and properly managed can bring a fresh perspective, innovative ideas, or a change of direction for a better and easier one. Unfortunately, no one teaches us how to resolve conflicts. Usually we avoid them or escalate them. And yet "a professional leader should be able to do this". But where? And transparency without openness to conflict can exist. Fictitiously. In JIRA.

Time

I once worked with a team that was struggling with the lack of automation in one of its processes. It slowed down work a lot. So they convinced the Product Owner that it was worth spending a sprint, maybe two, to build a tool that would speed up many tasks in the long run. They made a great tool. Two weeks later, it turned out that a few months earlier, another team had made the same tool. They would have just copied it. The constant rush and deadlines mean that there is “no time”. Each team is focused on their own goals, on their own problems. There is no time to familiarize themselves with the broader context. It is supposedly the Product Owner's task, but the Product Owner is not the only participant in transparent processes. Everything can be visible in JIRA, but until someone takes the time to see it, transparency will only exist in theory.

Finally...

Transparency is the foundation. However, without the right amount of time, courage and openness to conflict, it remains an empty phrase. Teams need space to analyze information in depth, ask questions, and share observations in order to draw conclusions and make better decisions together. Otherwise, even the most transparent processes will not really improve cooperation and development of the organization.