Transparency is a good thing. It’s often referred to as one of the three pillars of agile, along with the abilities to inspect and adapt.
But can a team be harmed by too much transparency?
Yes, I think that’s possible. Let me explain.
Quantitative and Qualitative Transparency
To start, let’s define transparency as visibility into how a team works. At the simplest level this can be metrics about them such as:
- Velocity
- Hours worked
- Number of story points per person
- Burndown charts
- Number of defects fixed per iteration
- And many more
Some of these might be worth tracking; others might not be. A fully transparent team would make all of this data visible.
But transparency extends beyond metrics and can include conversations team members had, decisions they made, and so on.
Because this type of transparency includes non-numeric data about a team, we can think of transparency extending to qualitative as well as quantitative data.
Internal and External Transparency
In addition to what is being made transparent, it’s useful to think about to whom the team is making things visible.
Is it to other team members? Or is it to people outside the team?
Putting the Types of Transparency Together
Thinking about transparency this way—internal/external and quantitative/qualitative—allows us to create a typical 2x2 matrix such as can be seen below:
The question then becomes whether there are differences in how transparent a team should be in these different quadrants.
Quantitative Data
Let’s start with quantitative data shared inside the team, which is in the bottom left. I think teams should practice total transparency here. This is objective data—and generally, if it wasn’t shared, someone could figure it out anyway.
Sticking with quantitative data but moving to the bottom right, we have sharing outside the team. I’m just slightly more cautious here. Ideally all quantitative data can be shared with all outsiders.
But there could be things I think the team might want to keep to themselves. Usually, this will be because the numbers could be misinterpreted or misused by an outsider, typically a stakeholder.
For example, a team could be slightly justified about not being transparent in these areas:
- Data on how many bugs each programmer is responsible for, if that is skewed by one developer working alone in very complex code.
- The number of story points delivered per developer. I’m always opposed to this metric because I don’t even know how story points can be credited to one developer when a typical product backlog item is worked on by three or four people.
- The number of hours of work taken on by each team member. As a matter of fact, a question I was emailed about this metric is what prompted this blog post. One team member might be taking on fewer hours of work in an iteration in order to have time to help others learn something.
I’m not happy to write that a team may not be transparent with outsiders about this type of data. But I’m open to guarding information under the right (or, more correctly the wrong) circumstances. If a number is being presented to a boss or stakeholder who will misjudge or misuse the number, sometimes it is better to keep that data within a team.
Qualitative Data
Let’s move to the top row, starting in the top left with qualitative data shared inside the team. I’m again reluctant to say so, but there are times when some qualitative data may be best kept private.
For example, suppose a team’s most senior technical person and Scrum Master have a conversation about the performance of a team member. They decide that the coaching they’ve provided a team member hasn’t worked; they need to recommend to that team member’s boss that the team member be moved off the project or even let go.
This is not the type of conversation that merits full transparency when another team member asks, “So what were you two talking about just now with the door closed?”
Team members should be completely transparent about most qualitative data and observations, but there can be some rare yet valid reasons to withhold complete transparency even among team members.
In the top-right quadrant we have qualitative data shared outside the team. If there are some conversations or decisions that shouldn’t be shared with absolutely everyone on the team, then there are even more that shouldn’t be shared outside the team.
I still don’t think a lack of transparency should be common, even in the top right quadrant, but there will be some decisions and discussions that should be kept within the team. As with keeping quantitative data private, the key is who the stakeholders are and the possibility that the information could be misinterpreted or misused.
The following chart summarizes my views on how fully transparent team members should be.
I’m Not Saying to Hide Things
Before you send me hate mail or tell me I’m wrong, remember that what I’m saying is that there can be situations in which complete transparency is more harmful than helpful.
It can help put this in context if you ask yourself whether you are completely transparent with everyone in all ways. If your boss or team members wanted you to share your location with them on your phone, would you?
After all, before the boss Slacks you in the evening, the boss might want to check your phone location to make sure you’re home. Sharing your location would be useful in this case, but for most teams, I don’t think it’s an appropriate amount of transparency. (I’d have no problem with it, though, if all team members sincerely agreed to share that data.)
So I’m not saying teams should start hiding things. I’m simply saying that a team should be as transparent as possible without starting to share things that could worsen a relationship or work against the success of the team.
