Is there such a thing as “too much transparency within the organization”? Are there any boundaries to where a transparency created by a Scrum Master should not reach?
When looking at Scrum pillars, we clearly see: transparency, inspection and adaptation as core beliefs on which Scrum stands. But what if we take transparency into extremum…? Let’s see what will happen.
Case #1
A Scrum Master works with the Scrum Team for some time. During that time, he is able to establish some ground of trust and mutual respect. He is involved in everyday work life of his Scrum Team, attends all the Scrum events, enjoys virtual coffees while conducting 1on1s. While having a private conversation with one the developers, Scrum Master asks about Developers recent drop in performance – did something happen? Is there anything he can help with? He is aware the direct managers have also seen this happening across the last two sprints. The Developer quietly explains a certain situation he is facing at home at the moment, that needs his focus more than he anticipated. He has an idea to solve his situation, and will get back to his-self in a respectable amount of time. The timebox is set by him.
After this conversation, our Scrum Master is approached by the Manager of our Developer and asked about the situation. Now, this conversation can go a few ways – by explaining exactly what we have learned from Developer, we presumably enforce #transparency at the cost of #respect and #trust.
But is it really transparency addressed here? Transparency would be for instance, acknowledging the privacy of the conversation and ensuring our manager that some actions will be taken. As Scrum Master we might also want to create a safe space for our Developer and Manager to discuss how together they can tackle this situation. There are multiple ways to approach this situation, none of which need to be at the cost of established trust.
Let’s look at a different case, more globally.
Case #2
An organization is at the beginning of its journey towards Agility. Everything is new, exciting, but scary. Scrum Masters are very eager to explain the reasons behind having Sprint Reviews and showing the works of different teams widely, thus enabling transparency across organization. In one of the relatively new teams, in one of the first Sprint Reviews Scrum Master encourages the team to speak about its impediments, blockers and other challenges it had during the last Sprint. Team is reluctant to share those, so a Scrum Master, with the best possible intention to share transparency on what the team is facing, opposed to the rest of the Scrum Team’s decision, explains by himself all of those things that prevented the team from delivering more value. His idea is: I will share those impediments; the stakeholders will hear and act.
But was it really the hoped-for impact we had there?
As a result of his actions, the team loses trust in his Scrum Master – they were not ready to share those stories. But what’s more alarming – the stakeholders and the organization were not ready to hear all of those problems at once, during this exact event. They are afraid, feel like those problems were a direct attack on their way of working, thus themselves.
Direct result? The organization is reluctant to change, and fears “this scrum” will show me as a person, as an employee in a bad light. Instead of transparently showing the processes that need to change, because of the actions of Scrum Masters the managers are even more reluctant to adopt an agile approach.
The situation was not handled with care, and all the aspects mentioned above were not taken into consideration. For this level of transparency of work, we need to first show the value of small changes within the process, and have at least a small shift of mindset towards resolving impediments and not taking them personally as failures.
Case #3
A Scrum Master learns of a new shift in management in the organization, directly impacting Product Owner. On a way towards agility, and building accountabilities, there is an idea to remove the position of Technical Product Owner and leave only Business Product Owners. The shift itself is in line with the Scrum approach – one Product Owner per one product. However, the details, exact dates and responsibilities are still in the process of figuring out. Due to Scrum Masters’ long relationship in the company, he learns that via coffee chat. He is immediately alerted that #transparency is not presented in this approach, and both of the Product Owners should be involved in this. So, he takes matters into his own hands, and sets up a meeting between POs’, himself and the person he spoke with for the next day. Both of the Product Owners are stressed, not sure what this change would mean to them, and will one of them lose his job? The person who was speaking to the Scrum Master is also reasonably stressed – something meant to be a friendly coffee chat, now has impacted more people. During this meeting, no action can be taken, no person responsible is at that meeting, it’s more of a scared guessing game. Tensions rise.
Now, you would say, Scrum Master did what he was supposed to – made sure all the people directly affected by this change, should be aware of it.
But to make sure transparency can happen, Scrum Master should have gathered all the needed data before setting up the meeting. Find out who is responsible for decisions in that area, why are they taking places, who will be involved. By acting in a rush, he might have impacted a plan that was meant to be transparent for everyone in say, a 2 weeks’ time, when for instance a process of gathering feedback from PO’s would be in place. By not getting all the information, he created needless panic and rumors.
Those are only a few situations I have seen in my years as a Scrum Master, where transparency was understood: all or nothing!
As you can see, for a full transparency within the organization to appear we need certain behaviors, changes in people’s mindset, clear boundaries. Moreover, we should act on data, not opinions and hearsay.
Of course, there is a lot more that should be taken into consideration – those just a few of many things. But whatever you do, always remember that building transparency is a long process – not a one-time shot.
